Mám tu pro vás nejdříve jedno důležité oznámení pro všechny hráče a potom menší technické okénko pro ty, které zajímá, co a proč teď řešíme.
Ve středu 2.12.2020 bude probíhat testování nového databázového připojení. Mějte proto na paměti, že na serveru se mohou vyskytnout chyby nebo výpadky.
V nejhorším případě může také nastat situace, kdy se neuloží váš progress (vydělané peníze a podobně), může nastat rollback, nebo může server úplně vypadnout, či můžete zažívat network trouble. Pokud takové potíže nastanou, pokusím se ještě dopoledne problém vyřešit, aby odpoledne, kdy na serveru bude více lidí, již vše běželo jak má.
Naopak v nejlepším případě se nestane vůbec nic a testování vůbec nepocítíte, ba naopak server poběží plynuleji, nebudou se už opakovat lagy ze strany serveru ve formě network trouble a podobně.
Co mám na mysli databázovou optimalizací?
Už je to 7 let, tedy celou dobu již od počátku serveru, co používáme MySQL databázi (a stále stejný skript) pro ukládání všech dat serveru MTA:SA Skimo RolePlay. Do této databáze se ukládá naprosto vše, data o postavách, předmětech, vozidlech, interiérech. Vše se musí ukládat do databáze, abyste po restartu serveru zase měli všechna auta, peníze, předměty. Celkově jen pro Skimo používáme 151 databázových tabulek, ve kterých je uloženo přes 440 tisíc záznamů a každý den proteče databází 2,7 GB dat. Navíc stejný databázový server používají i všechny naše další servery a služby.
Teď uděláme malou odbočku a povíme si, kdy nastává network trouble.
Network trouble obvykle způsobí jedna z těchto tří situací:
a) ztráta spojení ze strany klienta (vypadne vám internet, nebo máte vysoký ping)
b) ztráta spojení ze strany serveru (výpadek internetového připojení u hostingu)
c) server nestíhá zpracovávat data ("zamrzne" na nějaké činnosti a nestíhá tak odbavovat datové packety klientů)
Problém c) nastává na jiných serverech obvykle z důvodu špatné optimalizace skriptů, v našem případě však může nastat kvůli vysokému počtu požadavků na databázi. Na našem serveru hraje nejvíce hráčů na CZ/SK scéně a každý hráč neustále provádí akce, která mají za následek nějaké požadavky na databázi.
Každý přesun předmětu, použití předmětu, použití různých příkazů, transakce peněz, to všechno a mnohem více akcí způsobuje požadavky na databázi, které musí server i databáze zpracovat.
V případě, kdy databáze nestíhá ukládat a číst všechna tato data, pak nastává network trouble. Server totiž při každém databázovém požadavku "zamrzne." Obvykle to je v řádech tak malých časových úseků, že to nelze zaznamenat a je to naprosto běžná věc, která se děje již od počátku serveru. Výchozí databázové připojení tak prostě funguje, pošle dotaz na databázi a čeká na odpověď, pak zpracuje výsledek a pracuje na další akci.
Problém je to až teď, protože hráčů a tím pádem i akcí je velké množství. Když se totiž nahromadí v jeden okamžik velké množství požadavků na databázi, server "zamrzne" na delší dobu (ve vážných případech až na několik vteřin) a tím pádem server v tu chvíli nemůže zpracovávat nic jiného, jen čeká na odpověď databáze a hráčům tak způsobí network trouble.
Dobře, víme kde je problém, teď ho pojďme vyřešit!
Databázi jako takovou jsem dva dny zpátky už aktualizoval, to značně pomohlo v tom, aby databáze stíhala zpracovávat veškeré požadavky. Byli jsme 5 major verzí pozadu a používali jsme verzi databázového serveru z roku 2013 (na stejné verzi momentálně běží i databáze hostingu, u kterého je valná většina konkurenčních serverů, tyto servery však ani nemají možnost aktualizaci provést, jelikož nemají plnou kontrolu nad databázovým serverem).
Je tu však ještě jeden kostlivec ve skříni, kterého již nějakou dobu přehlížíme a to je samotné připojení k databázi a skript, který zpracovává veškeré požadavky, které pak databázi předává.
Proto je na čase s tím něco dělat, abychom se hlavně i do budoucna vyvarovali problémům, jelikož mimo jiné vše stojí na MTA MySQL modulu, který byl naposledy aktualizován 7.12.2010 a už několik let ho samotní MTA vývojáři nedoporučují používat. Každý RolePlay server jej však stále používá a nejspíš je jen otázkou času, kdy přijde nějaká aktualizace MTA, která způsobí, že MTA MySQL modul už nebude fungovat.
Poslední týden jsem mimo jiné pracoval právě na nové aktualizaci, která tohle celé řeší, ale zatím si ji držím na lokálním vývojovém serveru, jelikož nebylo a vlastně stále není zcela bezpečné ji nahrát na server s jistotou, že nenastane žádná chyba. Tohle bohužel zaručit nejde a nezbývá nic jiného, než to důkladněji otestovat přímo v produkci.
Na vývojovém serveru už jsem vychytal všechny chyby, které jsme objevili, ale jelikož se jedná o aktualizaci, která ovlivňuje úplně každý skript na serveru, nevyzkoušeli jsme pochopitelně úplně vše. Taktéž není možné v počtu třeba pěti testerů vytvořit takovou zátěž na databázi, kterou denně produkuje velké množství hráčů na serveru.
Ještě větší zátěž jsem se však pokusil napodobit skriptem a měřil jsem při tom výkon databázového připojení. Konkrétně tento skript generuje 250 000 akcí (dotazů na databázi) za minutu a vypisuje čas, který se na databázi muselo čekat (jak dlouho server nemohl zpracovávat nic jiného).
A výsledek?
Jak můžete vidět na screenu, nové připojení SkimoDB je zhruba o 20% rychlejší ve zpracovávání požadavků. To je skvělá zpráva, ale není to to nejdůležitější.
Nejlepší na novém připojení je totiž to, že může fungovat i asynchronně. To znamená, že v budoucnu mohu u konkrétních skriptů nastavit, aby server na odpověď nečekal a "nezamrzl," ale zpracoval odpověď až ji od databáze dostane a mezitím mohl dělat jiné úlohy. To nelze implementovat všude, protože některé požadavky je nutné zpracovat hned (například změny financí, jinak by mohlo dojít k vytvoření bezpečnostní díry), lze to však aplikovat především u načítání vyššího množství dat (např. načítání frakcí).
Ve středu tak provedeme ostré testování, kterým zjistíme, zda vše funguje jak má a jestli můžeme nové připojení ponechat v provozu.
Bohužel nic není jisté a je možné, že v ostrém provozu celá tato implementace selže a nepřinese takové ovoce, v jaké doufáme. Držte nám proto palce a ve středu s námi mějte strpení, pokud se nějaké chyby objeví.
Pokud vše dopadne dobře, postupně pak můžeme značně zvýšit výkon serveru, počínaje těmi 20% hned ve středu.
Mám tu pro vás nejdříve jedno důležité oznámení pro všechny hráče a potom menší technické okénko pro ty, které zajímá, co a proč teď řešíme.
Ve středu 2.12.2020 bude probíhat testování nového databázového připojení. Mějte proto na paměti, že na serveru se mohou vyskytnout chyby nebo výpadky.
V nejhorším případě může také nastat situace, kdy se neuloží váš progress (vydělané peníze a podobně), může nastat rollback, nebo může server úplně vypadnout, či můžete zažívat network trouble. Pokud takové potíže nastanou, pokusím se ještě dopoledne problém vyřešit, aby odpoledne, kdy na serveru bude více lidí, již vše běželo jak má.
Naopak v nejlepším případě se nestane vůbec nic a testování vůbec nepocítíte, ba naopak server poběží plynuleji, nebudou se už opakovat lagy ze strany serveru ve formě network trouble a podobně.
Co mám na mysli databázovou optimalizací?
Už je to 7 let, tedy celou dobu již od počátku serveru, co používáme MySQL databázi (a stále stejný skript) pro ukládání všech dat serveru MTA:SA Skimo RolePlay. Do této databáze se ukládá naprosto vše, data o postavách, předmětech, vozidlech, interiérech. Vše se musí ukládat do databáze, abyste po restartu serveru zase měli všechna auta, peníze, předměty. Celkově jen pro Skimo používáme 151 databázových tabulek, ve kterých je uloženo přes 440 tisíc záznamů a každý den proteče databází 2,7 GB dat. Navíc stejný databázový server používají i všechny naše další servery a služby.
Teď uděláme malou odbočku a povíme si, kdy nastává network trouble.
Network trouble obvykle způsobí jedna z těchto tří situací:
a) ztráta spojení ze strany klienta (vypadne vám internet, nebo máte vysoký ping)
b) ztráta spojení ze strany serveru (výpadek internetového připojení u hostingu)
c) server nestíhá zpracovávat data ("zamrzne" na nějaké činnosti a nestíhá tak odbavovat datové packety klientů)
Problém c) nastává na jiných serverech obvykle z důvodu špatné optimalizace skriptů, v našem případě však může nastat kvůli vysokému počtu požadavků na databázi. Na našem serveru hraje nejvíce hráčů na CZ/SK scéně a každý hráč neustále provádí akce, která mají za následek nějaké požadavky na databázi.
Každý přesun předmětu, použití předmětu, použití různých příkazů, transakce peněz, to všechno a mnohem více akcí způsobuje požadavky na databázi, které musí server i databáze zpracovat.
V případě, kdy databáze nestíhá ukládat a číst všechna tato data, pak nastává network trouble. Server totiž při každém databázovém požadavku "zamrzne." Obvykle to je v řádech tak malých časových úseků, že to nelze zaznamenat a je to naprosto běžná věc, která se děje již od počátku serveru. Výchozí databázové připojení tak prostě funguje, pošle dotaz na databázi a čeká na odpověď, pak zpracuje výsledek a pracuje na další akci.
Problém je to až teď, protože hráčů a tím pádem i akcí je velké množství. Když se totiž nahromadí v jeden okamžik velké množství požadavků na databázi, server "zamrzne" na delší dobu (ve vážných případech až na několik vteřin) a tím pádem server v tu chvíli nemůže zpracovávat nic jiného, jen čeká na odpověď databáze a hráčům tak způsobí network trouble.
Dobře, víme kde je problém, teď ho pojďme vyřešit!
Databázi jako takovou jsem dva dny zpátky už aktualizoval, to značně pomohlo v tom, aby databáze stíhala zpracovávat veškeré požadavky. Byli jsme 5 major verzí pozadu a používali jsme verzi databázového serveru z roku 2013 (na stejné verzi momentálně běží i databáze hostingu, u kterého je valná většina konkurenčních serverů, tyto servery však ani nemají možnost aktualizaci provést, jelikož nemají plnou kontrolu nad databázovým serverem).
Je tu však ještě jeden kostlivec ve skříni, kterého již nějakou dobu přehlížíme a to je samotné připojení k databázi a skript, který zpracovává veškeré požadavky, které pak databázi předává.
Proto je na čase s tím něco dělat, abychom se hlavně i do budoucna vyvarovali problémům, jelikož mimo jiné vše stojí na MTA MySQL modulu, který byl naposledy aktualizován 7.12.2010 a už několik let ho samotní MTA vývojáři nedoporučují používat. Každý RolePlay server jej však stále používá a nejspíš je jen otázkou času, kdy přijde nějaká aktualizace MTA, která způsobí, že MTA MySQL modul už nebude fungovat.
Poslední týden jsem mimo jiné pracoval právě na nové aktualizaci, která tohle celé řeší, ale zatím si ji držím na lokálním vývojovém serveru, jelikož nebylo a vlastně stále není zcela bezpečné ji nahrát na server s jistotou, že nenastane žádná chyba. Tohle bohužel zaručit nejde a nezbývá nic jiného, než to důkladněji otestovat přímo v produkci.
Na vývojovém serveru už jsem vychytal všechny chyby, které jsme objevili, ale jelikož se jedná o aktualizaci, která ovlivňuje úplně každý skript na serveru, nevyzkoušeli jsme pochopitelně úplně vše. Taktéž není možné v počtu třeba pěti testerů vytvořit takovou zátěž na databázi, kterou denně produkuje velké množství hráčů na serveru.
Ještě větší zátěž jsem se však pokusil napodobit skriptem a měřil jsem při tom výkon databázového připojení. Konkrétně tento skript generuje 250 000 akcí (dotazů na databázi) za minutu a vypisuje čas, který se na databázi muselo čekat (jak dlouho server nemohl zpracovávat nic jiného).
A výsledek?
Jak můžete vidět na screenu, nové připojení SkimoDB je zhruba o 20% rychlejší ve zpracovávání požadavků. To je skvělá zpráva, ale není to to nejdůležitější.
Nejlepší na novém připojení je totiž to, že může fungovat i asynchronně. To znamená, že v budoucnu mohu u konkrétních skriptů nastavit, aby server na odpověď nečekal a "nezamrzl," ale zpracoval odpověď až ji od databáze dostane a mezitím mohl dělat jiné úlohy. To nelze implementovat všude, protože některé požadavky je nutné zpracovat hned (například změny financí, jinak by mohlo dojít k vytvoření bezpečnostní díry), lze to však aplikovat především u načítání vyššího množství dat (např. načítání frakcí).
Ve středu tak provedeme ostré testování, kterým zjistíme, zda vše funguje jak má a jestli můžeme nové připojení ponechat v provozu.
Bohužel nic není jisté a je možné, že v ostrém provozu celá tato implementace selže a nepřinese takové ovoce, v jaké doufáme. Držte nám proto palce a ve středu s námi mějte strpení, pokud se nějaké chyby objeví.
Pokud vše dopadne dobře, postupně pak můžeme značně zvýšit výkon serveru, počínaje těmi 20% hned ve středu.
Salsiii 
kormoo