Jak zvládnout velký počet návštěv po spuštění rubrika: Folklór
8
rmaslo
Představte si, že máte naprogramovat systém, který má zaregistrovat asi tak 5 miliónů registrací + nějaký jednoduchý výběr termínu v průběhu půl roku. To podle mne není vůbec nic úžasného (3 registrace za vteřinu) a lze to v pohodě zvládnout klidně i na něčem tak jednoduchém jako je PHP + MySQL. Generovat 100 jednoduchých stránek za vteřinu podle mne v PHP+MySQL není problém.
Nicméně. lze očekávat, že lidé budou natěšení a dejme tomu, že počítáme s tím, že první procento (tj. 50000 lidí) se zkusí zaregistrovat hned během první minuty. A tu už podle mne zas taková sranda není.
Omezující podmínky: Jsou to nějaké citlivé data, takže registrace nechceme ukládat na žádný externí cloud od gooogle atd..., chceme šetřit, takže si kvůli první minutě nechceme pořídit desítky serverů a hlavně každou registraci potvrzujeme SMSkou a máme kapacitu třeba 100 SMS za vteřinu. Takže řešení podle mne není urychlení (asi nechceme aby jim potvrzovací SMS přišla druhý den po registraci), ale spíše chceme příchozí nějak jednoduše "strojově nafrontovat". Nafrotnování neobsahuje žádná citlivá data, takže nemusí běžet na našem HW.
Jak byste takové "nafrontování" principiálně řešili? Nebo navrhujete jiný princip řešení?
PS: Podobnost s dnešním "pádem registračního systému na vakcinaci" samozřejmě není vůbec náhodná, nicméně politickou diskuzi bych pokud možno vynechal. Podobná situace (přetížení v prvních minutách) může nastat i pokud byste měli udělat i třeba nějaký systém na prodej vstupenek na žádaný nějaký koncert, fotbalový zápas atd...
9
pavel.stehule
Asi základem u těchto aplikací je použít pro začátek (první týden), kdy je velká pravděpodobnost návalu dostatečně nadimenzovanou mašinu. Relační databáze zvládne bez problémů na dnešním železe 1000 write transakcí za sec na core - limitem jsou typicky IOPS persistentních médií. Data, která jsou transakční mohou jít přímo do databáze, netransakční (statistiky apod) do REDISu. Na vygenerování jednoduchého formuláře by mělo stačit PHP vlastně cokoliv - opět nesmí být poddimenzovaná mašina. A na fronty třeba kafku, kde přeci jen riziko havárie je trochu ošetřené.
Znám pár zákazníků, kteří mají velké špičky, a i když mají relativně komplexní aplikaci, tak je zvládají i na aplikacích psaných běžným způsobem a běžných technologiích (Python, Postgres). Ale mají adekvátní železo a mají lidi, kteří mají dlouhodobé zkušenosti, jak programovat tento typ aplikací, tj. co řešit synchronně, co asynchronně.
Dovedu si představit, že lidé, kteří píší bankovní aplikace a platební portály tohle mají zažité a vychytané, a ostatní to napíšou nějak, a pak jim to s trochou štěstí funguje. Pokud máte kapacitu 100 registračních SMSek za sec, tak je jasné, že databáze ani server nemůže být bottlenck, ale je potřeba všechno programovat asynchronně, čekat ve smyčce se 1 sec sleepem i pro 1000 prvních příchozích může být dost neefektivní. V GD čekání na výsledek řešil klient, a dynamicky zvyšoval dobu aktualizace stavu z 1 sec na 10 sec při delší době čekání.
Pro zobrazení všech 4 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem: