Ne cerem scuze pentru apariția erorilor 502 din această seară și ieri seară, aveți și motivul mai jos.

După cum probabil că ați constant, am șters iar poll-ul. Unii probabil ați reușit să trageți de aici concluzia relativ logică -- mai ales avand in vedere faptul că și aseară după ce am șters poll-ul și-a revenit -- că problemele sunt cauzate de poll (cel puțin asta am ajuns să credem, în afară de o coincidență extrem de mare, e singura variantă). Mai exact, în ciuda faptului că în momentul de față avem un server monstru, pur și simplu avem mult prea mulți useri.

De exemplu, aseară când a început să pice erau înregistrate ~8720 de voturi. În momentul în care un user care a votat accesa pagina index.php era executat query-ul de fetch al raspunsurilor, de aici rezultând un SELECT de ~8720 de rânduri.

Aseară erau ~19 request-uri/secundă pe index.php => ~165,680 rânduri citite/secundă

Dimensiunea tabelei era de ~1.7MB => că se citeau ~32.3MB/s numai din tabela pollanswers, dacă ați știi și datele citite din celelalte tabele, în special files_users (snatchlist), v-ați da seama de ce asta poate să devină o problemă.
Evident, datele nu sunt transmise userului în format raw, așa ca nu e necesar un trafic de 32.3MB/s doar pentru răspunsurile de la poll.

În seara asta am încercat să activăm modulul de cache care e folosit și pe browse, și anume cachelite, doar că asta cauzează o altă problemă, din cauza frecvenței cu care se fac voturile cache-ul este rescris mult prea des.
În primul rând, acest lucru nu e sănatos deorece ucide ciclurile de scriere ale SSD-ului. În al doilea rând, induce cloudflare-ul în eroare din cauza faptului că acum e content-ul, peste 1ms nu mai e.

În momentul de față se lucrează la optimizarea procedurii.




We apologize for the errors 502 tonight and last night you why below.

As you probably constantly wiped and poll. Some have probably managed to pull this relatively logical conclusion - especially considering the fact that last night after I wiped poll has recovered - the problems are caused by poll (at least I have come to believe besides a very big coincidence, it is the only option). Specifically, despite the fact that now we have a monster server simply have too many users.

For example, last night when it began to drop ~ 8720 votes were registered. When a user who has voted access index.php page of your query was executed fetch the responses, resulting in a SELECT-8720 lines.

Last night was ~ 19 s request / second index.php => ~ 165,680 rows read / second

The size of ~ 1.7MB table was => read it ~ 32.3MB / s only pollanswers table, if you know and read data from other tables, especially files_users (snatchlist), you realize that this may become a problem.
Obviously not transmitted user data in raw format, so it's not necessary traffic 32.3MB / s only for replies from the poll.

Tonight we tried to activate the cache module that is used to browse, namely cachelite, only that it causes another problem, because of the frequency with which votes are cache is overwritten too often.
First, this is not healthy Since there kill write cycles of SSD. Secondly, the CloudFlare induce in error because now it's content, there's more than 1ms.

At the moment we are working on optimizing the procedure.