MySQL: Utilizare si recomandari

In ultima perioada din ce in ce mai multi dintre voi isi instaleaza panouri de control pentru serverele de SA:MP, acesta este bineinteles un lucru foarte bun pentru popularitatea si dezvoltarea serverului de joc insa trebuie sa avem in vedere ca securitatea nu trebuie sa lipseasca din acel script web intrucat putem foarte usor sa ne blocam complet baza de date.


Cateva definitii:


1. Orice nume de utilizator al unei baze de date are setata valoarea "max_user_connections" ce limiteaza numarul de conexiuni simultane TCP/IP pe care le va accepta serverul de la aceiasi nume de utilizator, in mod normal aceasta valoare este setata implicit la: 10 (50 slot), 20 (100 slot), 50 (> 100 slot). Nu exista notiunea de "fara limita" in tehnologie, aceasta fiind introdusa inca de la debut pentru a preintampina o situatie neplacuta de suprasolicitare in mod abuziv ori accidental, limita NU SE SCOATE sub nici o forma, insa se poate mari in conditii cat se poate de bine explicate si rationale.  In cazul depasirii valorii "max_users_connections" atribuite nici macar phpmyadmin-ul nu va mai putea fi accesat iar daca raman conexiuni captive acestea expira conform punctului 2. 

2. Intreg serverul de baza de date (fara exceptie) are setata valoarea de "timeout", asadar orice utilizator conectat pe o perioada mai mare sau egala cu 1800 secunde fara nici un fel de actiune (query) in acest interval va fi deconectat.

3. Unei adrese de IP externe retelei nu i se va permite deschiderea a mai mult de 25 conexiuni TCP/IP simultane la serverul de baza de date.



1. Prin constructia GM-ului se va avea in vedere:


a) Deschiderea de conexiuni la MySQL intr-un "pool" (array cu handlere), sunt suficiente 2-3 conexiuni chiar si pentru servere cu 1000 de jucatori online, insa recomandam un "pool" de doua conexiuni pentru orice numar de sloturi in vederea asigurarii unei redundante - daca un handler este ocupat cu un query, se va ocupa cel de rezerva! Baza de date serveste exclusiv la interogarea ori actualizarea datelor dinamice, nu ai nevoie de mai multe conexiuni indiferent de numarul de sloturi pe care-l ai ori numarul de jucatori online. Totul ar trebui sa fie controlat de o singura functie in gamemode.

b) Conexiunile TCP catre serverul MySQL NU se vor inchide/deschide dupa fiecare query! Mare mare atentie ! Daca GM-ul face chestiunea asta inseamna ca serverul tau va avea o performanta scazuta, lag, pierderi in momentul actualizarilor dar si posibilitatea neplacuta de a-i fi refuzata conexiunea la MySQL pe motiv de abuz ori depasirea valorii "max_user_connections" datorita sesiunilor neincheiate ori existenta unui val de conexiuni de la un panou de control. 

c) GM-ul va controla (show processlist) daca au ramas sesiuni neincheiate si le va inchide (KILL PROCESS) eventual intr-un task la 600 secunde. Conexiuni neincheiate apar doar in caz de crash al serverului de SA:MP ori problema de configurare in GM.

d) In lipsa de activitate (query-uri la MySQL -> server gol ?) va transmite un "heartbeat" (orice query, fie ca selectezi un jucator ori show processlist) pentru a nu fi deconectat fortat conform definitiei explicate la punctul 2. 

e) In caz de deconectare, se va scrie intr-un log local pentru debugging (solicitare asistenta eventual) si va reincerca conectarea la baza de date pentru actualizarea handler-urilor definite la subpunctul a.

f) Nu vrei ca serverul tau de joc in productie (cu jucatori online) sa inregistreze fiecare query la MySQL intr-un log pe HDD-ul unitatii de procesare, iti ia din resursele necesare procesarii frame-urilor si in anumite situatii poate genera chiar picajul serverului de joc, foloseste functia debug doar atunci cand intr-adevar vrei sa observi functionarea serverului si nu in alte situatii!



2. Panoul de control (UCP / UserPanel):


a) Trebuie sa NU efectueze cate o conectare la MySQL pentru fiecare vizitator ce acceseaza pagina, ia aminte ca folosesti baza de date a serverului de SA:MP si nu iti doresti sa o blochezi (max_user_connections) in cazul in care primesti flood in panoul web! Toate valorile afisate vizitatorilor vor fi indexate intr-un cache in mod obligatoriu! Valorile ce fac parte din zona membrilor vor fi indexate de asemeni intr-un cache daca structura lor permit acest lucru.

b) Dupa executia scriptului PHP in se va actiona functia php de inchidere a conexiunii mysql obligatoriu ! Nu ne dorim sa avem conexiuni blocate in serverul de baza de date.



Alte elemente de luat in calcul:

Toate interogarile, indiferent de natura lor vor fi executate cat mai definit posibil pentru a diminua atat timpul de raspuns cat si incarcarea pe partea serverului MySQL, nu insist pe acest subiect din pricina faptului ca noi nu am avea resursele necesare asa cum foarte multi dintre voi ati tras concluzia, nici vorba! Insa orice query executa LOCK pe tabela asupra careia actioneaza, nu iti doresti sa executi un query ce dureaza foarte mult pentru ca daca serverul de joc are nevoie sa execute ceva fix pe aceiasi tabela vei experimenta lag ori chiar crashul serverului!

De exemplu, daca ai nevoie sa faci UPDATE pe id-ul unui jucator si doresti sa actualizezi trei campuri ... un singur query trebuie sa le actualizeze pe toate! Am intalnit cazuri in care GM-urile executau cate un query pentru fiecare camp actualizat al aceluiasi jucator, nu este deloc in regula! phpmyadminul te poate ajuta cu sintaxa sub forma unui exemplu in urma unei interogari (exemplu: UPDATE `zp_hid1`.`authme` SET `y` = '2'`z` = '1' WHERE `authme`.`id` = 1;)






Ţi-a folosit?

Citiţi şi

Powered by WHMCompleteSolution