Pokus o zamyšlení: webová aplikace pro 60.000 lidí?

16.7.2006 01:00 | Linux - IT | poslední úprava: 16.7.2006 22:21

Zdravím všechny dobré duše,

mám takovou teoretickou a zvědavou otázku. Takovou proto, že mne to jen zajímá a řešit to nebudu.

Hraju nějakou dobu (od dubna?) fotbal na Hattricku a mam dojem, že letos jim cca 3x slušně slítla databáze. Občas to hází errory jako "MS SQL ...". Říkají, že stále posilují železo. Mne by zajímalo, zda by toto bylo řešitelné v linuxu a jak moc snadné?

Bývá připojeno dle denní doby 30.000 - 60.000 lidí. Předpokládám, že musí být nějaká "tlustá lajna", webserver a databáze. Šlo by to na jednom počítači? Když se zaloguju, rozhazuje to na další servery (www61.hattrick.org třeba). Máte někdo s něčím podobným zkušenost, pochlubíte se?

Potřebné detaily a tak si časem najdu a když tak je sem dopíšu.

       

Komentáře

[Max]

60 000 lidí je dost. Taky to závisí na vyřizování požadavků apod. Nemám ani představu, co je to za server :-/. Registrovat se nechci, ale vypadá to na nějakou webovou klikačku. Takže by se dalo říci, že by to mohlo být náročné jako webový server s vyřizováním cca 30 000 požadavků za 1s + nějaká databáze?V takovým to rozsahu nemám moc dobrou představivost, ale jeden PC by to mohl dát určitě, otázkou je, jak by byl nabušený
Zdar Max

[Messa]

30 000 požadavků za 1s + nějaká databáze? (…) jeden PC by to mohl dát určitě

Jestli to mají být dynamické stránky, tak by byl myslím problém i napsat aplikaci HelloWorld, aby stíhala těch 30k/1s. To už asi opravdu bude chtít cluster, nehledě na ono www61 v URL.

Ale byl by to zajímavý úkol :) A asi bych to nepsal v PHP

[D-Evil]

Jeden silnej vyhrazenej stroj je dražší, než 4 slabší sdílený (hardware, u konektivity je to naopak, ale rozdíl to nevyrovná) a u kritickejch služeb bejvá dobrym zvykem ho zálohovat další mašinou (další stejně silnej server a další stejně tlustá lajna) - to v případě 4 serverů, který si rozkládaj zátěž, odpadá, stačí nechat trochu rezervu ve výkonu a konektivitě každýho z nich.

Takže abych to shrnul - "jeden" stroj by to dost možná uživil, ale zřejmě by na tom provozovatel prodělal i poslední kalhoty.

[Kyosuke]

Na to by měla stačit jedna slušná mašina a pořádně napsaný software... (Lidi, varuju vás, nečtěte si nikdy nic o Forthu, zanechá to na vás trvalý následky! )

[VícNežNic]

Jenom by mě zajímalo, na co by pak stačila jedna i malá chyba

[Kyosuke]

Pravidlo 9, odstavec 2: „Write code so simple and clear that bugs simply can't happen.“

[Penguin_007]

Co to vidí oko mé, blankytné? Další, kterého postihl Forth? Je to sice 20 let, co jsem v něm začínal, ale dodnes jsem nepotkal logičtější jazyk.

[Kyosuke]

Mně přijde těch pár kilobajtů na operační systém smixovaný s IDE docela příjemných. Narazil jsem na Thinking Forth a shledal jsem tuhle knihu jako obecně velice využitelné dílko. Takové věci se už dneska bohužel moc nepíšou...

[Penguin_007]

Tu knizku znam, kvalitni dilko. Ja jsem Forth studoval ze serialu, ktery vychazel v roce 1985 v amaterskem radiu a pochazel z klavesnice/pera Pana Programatora Rudolfa Pecinovskeho. Bohuzel dnes uz pro Forth nenalezam mnoho uplatneni, tak zapominam , jen me zaujal a nekdy, jen co bude cas, vyzkousim Forth-Shell...

[Penguin_007]

Jop a zapomel jsem Forth-Script pro psani webu, ale s tim se na zadnem hostingu asi nesetkam

[Kyosuke]

Mě zajímají ohledně Forthu spíš embedded věci. Na assembler jsem kromě kritických rutin moc líný a Cčko mimo Unix moc nemusím, kromě toho se jeho kompilátor do mikrořadiče asi ani nevejde. Docela mě totiž přitahují malé věci s malou spostřebou připojitelné k Ethernetu, a mám na mysli věci fakt mrňavé. (Jo, mívám šílený nápady...)

[D-Evil]

Jinak na Linuxu by to skoro určitě řešitelný bylo, nedovedu si v tuhle chvíli představit překážku, snad jedině v administraci samotnýho obsahu (tj. jak se do tý hry cpou data). Nicméně pochybuju, že by to dlouhodobě něco řešilo. Když dojde paměť, tak jádro SQL server stejně sestřelí a naskriptovat detekci a nápravu takový situace samozřejmě jde i ve Windows. Jedinej přínos (z technologickýho hlediska) může bejt v lepší propustnosti, ale těžko nám bez detailních informací někdo řekne, jestli by to v dlouhodobym horizontu k něčemu bylo.

[Michal Kubeček]

Počet "připojených" lidí je číslo, které sice vypadá impozantně, ale má mizivou vypovídací hodnotu. Zajímavější by byl počet dotazů za sekundu a hlavně počet těch zajímavých dotazů, které se musejí vyhodnocovat (tj. ne statické obrázky apod.).

[vencour]

No, reklamu jsem dělat nechtěl

K náročnosti: má být možnost použít různé jazykové mutace ve výstupu. Každý manažer má k dispozici kroky pro podporu svého týmu, týkající se úprav stadiónu, realizačního týmu, počtu hráčů, nastavení úrovně tréninku. Vše je to jen v textu, tedy on si svá přání co do možností navolí a jednou za čas se to náhodně změní.

Celý fotbalový svět je tu rozdělen do zemí, 6-8 úrovní lig (podle počtu týmů v dané zemi), je možno 1x týdně spáchat přátelák (pokud se nehraje pohár), 1x týdně se hraje liga, to vše se dá sledovat průběžně, 15 minut před výkopem se nedá měnit sestava a pak pokud se něco stane ve hře, tak se to vypíše.

K tomu funguje diskusní fórum, je docela obsáhlé. Zdá se, že každá soutěž (úroveň) má svou vlastní konferenci.

Toto uvádím pro nástin náročnosti a nároků na použitou technologii.

[Jiří Veselský]

Nemám představu o náročnosti té vámi popisované věci, nicméně příklad z jiného soudku:

Mám server, na který se připojují "agenti" a přes http na něj posílají data. Server je parsuje a ukládá na DB server. Jde o cca 8 http spojení za sekundu, síťově do toho serveru přitéká cca 1.5 Mbps. Webový frontend i databázový backend běží každý na svém dual xeonu 2.8GHz a oba ty dva stroje ZÍÍÍÍVAJÍÍÍÍ nudou...

[Miloslav Ponkrác]

Tohle může být cokoli, od super náročného řešení až po řešení nenáročné. Dokud se neví, co tam jede a co tam Ti uživatelé dělají, nelze nic říci.

60 000 lidí je nic neříkající číslo. Nic to neříká o tom, jak moc to zatěžujě stroj, a už vůbec nic o tom, jak to zatěžuje databázi.

Jinak já bych na Vašem místě byl skromnější, napsat že někomu 3x slítla databáze a dělat machra, že to dokážu líp bez znalosti pozadí.

[vencour]

3x slítla databáze znamená 3x několikahodinou a delší nedostupnost a omluvný text.

Co tam ti uživatelé dělají? Hrabou si na svém písečku, mění to, na co mají právo, svůj tým. Jak tam teď koukam, pořád se tam něco děje, hraje se liga v Keni, Kazachstánu a Kyrgyzstánu. Tedy počítá se výsledek na základě současných dat hráčů atd. a je nabízena možnost tyto zápasy sledovat v xml.

[Michal Kubeček]

Nepochopil jste, o čem mluvíme. 60000 uživatelů, z nichž každý každých deset sekund vygeneruje požadavek na aplikaci, znamená úctyhodných 6000 požadavků za sekundu (a to v průměru, takže špičky budou výš). 60000 uživatelů, kteří jsou celý den "přihlášeni", ale každý za ten den vygeneruje 20 dotazů, znamená v průměru 14 dotazů za sekundu. A to je dost podstatný rozdíl. Takže počet "současně přihlášených" uživatelů je údaj, který o zatížení systému sám o sobě nevypovídá prakticky nic.

[vencour]

Pochopil, ale o tom nevim nic. Jasně, že je tam každej a dělá si co chce. Navíc jeden přihlášenej (jako já) při sledování zápasů může pěkně zlobit - minimálně 4 zápasy jde sledovat najednou. Tedy vygenerovat stránku, spočítat něco náhodného a tak. Jak jsem pochytil, možná se průběh zápasu vygeneruje dopředu a pak jen posílá aktualizace ven, tedy pak už je to skoro jedno, kolik toho kdo sleduje, jde jen o čtení z databáze a tvoření výstupu. Tedy popisuju to pouze zvenku a vím o tom.

[Michal Kubeček]

Tady jde hlavně o to, že se ptáte, zda by to určité řešení utáhlo, ale přitom jste neposkytl prakticky žádné informace, ze kterých by bylo možné si udělat aspoň řádovou představu, jaká je náročnost té aplikace.

[vencour]

Jo, neposkytl, ale někdo může odpovědět: mam s tim zkušenost, trouf bych si na to ... při X přístupech za minutu na Apači to dělá X operací při přístupu na disk. Databáze to zvládá, úzké místo je v Y. Tedy doufám, že podle Přední stěny domu se udělá obraz o vnitřku, aspoň z mých náznaků. Tak jako z počtu lidí a obsažených dat se dá odhadnout, jak často se s nimi bude hýbat, jaká je třeba propustnost. Tj. každý tým má 1x denně aktualizaci stavu (přírůstkovou obecnou, minimálně fanoušků) a k tomu 1x týdně různou aktualizaci nějaké vlastnosti, tedy každý den něco 2x (fanoušci + něco dalšího, tým, stadión, zdraví). Něco běží neustále a něco na vyžádání.

Mam i pocit, že tuto možná spadá do vnitřního tajemství každého, jaké má kde rezervy?

Případně je toto tak neobvyklé řešení či případ, že se tim nikdo nezaobírá či nezaobíral?

[Michal Kubeček]

Jo, neposkytl, ale někdo může odpovědět: mam s tim zkušenost, trouf bych si na to

Člověku, který vám něco takového odpoví, aniž by měl aspoň mlhavou představu, co po něm vlastně chcete, se většinou říká manažer. Na tento server ovšem většinou chodí spíše lidé, kteří pak ty jeho nereálné sliby musejí nějak realizovat nebo aspoň emulovat. Takže od nich takovou odpověď nečekejte.

Tedy doufám, že podle Přední stěny domu se udělá obraz o vnitřku, aspoň z mých náznaků.

Tak si to schválně zkuste: tohle je zepředu. Máte představu? Fajn. Tak teď pohled zezadu, zevnitř a ještě jednou zevnitř. Bylo to dostatečně názorné? :-)

Tj. každý tým má 1x denně aktualizaci stavu (přírůstkovou obecnou, minimálně fanoušků) a k tomu 1x týdně různou aktualizaci nějaké vlastnosti, tedy každý den něco 2x (fanoušci + něco dalšího, tým, stadión, zdraví). Něco běží neustále a něco na vyžádání.

Jenže to píšete až teď a i to jsou jen útržky. Pochopte, že prakticky nikdo z nás tu aplikaci nikdy neviděl a nemáme tušení, co má vlastně dělat. Natož mít představu o typickém chování jejích uživatelů.

[vencour]

Jooo

Útržky to budou asi pořád. Dělat to má tolik věcí, aby to co nejvíc přitáhlo, udrželo a bylo nejlepší , snažilo se přiblížit realitě.

Já to chápal takhle: mam tam x lidí, každej se v tom svym vrtá, jaký jsou asi meze? A proč ještě tam nedali linux? Nevim, co je s živěCz, že jim tam taky drhne (drhla?) databáze (tj. nevyplivla odpovídající stránku), mam pocit, že ty chybový hlášky si jsou podobný.

Tušim, co hledám a ještě budu hledat, až to najdu, výsledky, které mi napoví, zde uvedu.

[Michal Kubeček]

Já to chápal takhle: mam tam x lidí, každej se v tom svym vrtá, jaký jsou asi meze?

Celou dobu se vám snažíme vysvětlit, že počet uživatelů je pro náročnost té aplikace na systémové zdroje naprosto nezajímavý údaj. Spíš se pokuste odhadnout, kolik dotazů za sekundu se dá ve špičkách očekávat.

A proč ještě tam nedali linux?

Pravděpodobně proto, že používají Windows už delší dobu, mají pro ně vývojové nástroje, mají vývojáře, kteří jsou na to prostředí zvyklí a mají s tím zkušenosti. To je jako kdybyste se ptal, proč ABCLinuxu stojí na Javě a MySQL, zatímco já dám přednost PHP/C++ a Firebirdu. Obvykle se nedá říct, že by některé řešení bylo a priori lepší za každých okolností.

[vencour]

Jeee

A počet lidí nedá info o horní mezi? Udělam 2-3 "scénáře", tj. 2-3 různé "průměrné uživatele" a s těmi pracuji?

[Michal Kubeček]

Tak proč to neuděláte? Vy tu aplikaci znáte aspoň jako uživatel. My ani to.

[vencour]

Protože mam dost malou zkušenost s něčim, co je nad síťovou vrstvou.

[Miloslav Ponkrác]

Teda nic proti Linuxu, ale právě takováto tvrzení jsou příčinou špatné reputace Linuxu. Někdo příjde a aniž zná podstatu prostě řekne proč tam nedal Linux, pak si to řešení s Linuxem nabije hubu a o reputaci Linuxu je postaráno.

Pokud to budou útržky a nehodláte to konkretizovat, pak Vám nikdo neřekne co potřebujete.

[vencour]

Dík za upozornění.

No, otevřel jsem hodně velkou, hlubokou a tak truhlu, mam co zkoumat.

[vencour]

Směr, kterým pátrám: Srovnání databází na RootuCz. Tady jsem našel tvorbu a správu databází. Nějaké reklamní upoutávky o MySQL.

[Miloslav Ponkrác]

je to jednoduché co chcete dělat? na čem to chcete dělat? kolik to bude mít? jak se data budou využívat? jaký je poměr čtení oproti zápisu? bude vhodné využít procedury/triggery atd..? jaká bude zátěž serveru / aplikace / databáze? a další

[Zdeněk Burda]

Moc zbytečných otázek. Spíš se to chce zeptat kolik za to a o kolik se může přetáhnout termín

[vencour]

Tuto celé je jen sonda, jak by se to dělalo. A ve světě už je Hattrick, HokeyAréna a v Čechách FotballArena. To bych se už možná přidal k nim.

Více si najdu někde na netu, abych takovýmto cizím slovům rozumněl. Databáze šly zatím komplet mimo mne.

Zatim nemám chuť něco takového tvořit. Ale kdyby něco, byla by to zřejmě nějaká strategie. Každý rád po sobě něco nechá, něco co nejvíce dokonalé.

[Michal Kubeček]

Vzhledem k vašemu výběru zdrojů informací si dovolím několik důležitých upozornění:

• existují i jiné databáze než MySQL
• existují i jiné open source databáze než MySQL
• tyto databáze nejsou horší jen proto, že se o nich tolik nemluví a nepíše
• mnozí si dokonce myslí, že vám toho tyto databáze mohou nabídnout víc

To jen pro jistotu, spoustě začátečníků to unikne… :-)

[vencour]

Jj, v té diskusi na rootu jsem zahlíd slušnou výměnu názorů. Děkuji

[happy barney]

rozhodne by som vam skor navrhoval zacat patrat smerom fastcgi (popr. so session affinity patchom) alebo nieco s podobnou architekturou

Co sa tyka databazy, tam bude zaujimava rychlost select-u z velkych tabuliek (kde samotny index ma velkost radovo nasobky ram). Velmi pomoze, ak databaza podporuje ciastocne indexy. Dobre by bolo, podporovala zamykanie riadkov (a nie ako mysql/myisam, zamykanie celej tabulky). Dalsie vlastnosti, ako sekvencie, triggre/storage procedures (a moznost pisat ich v jazyku aplikacie), byvaju casto prijemnym bonusom.

[Michal Kubeček]

Dobre by bolo, podporovala zamykanie riadkov (a nie ako mysql/myisam, zamykanie celej tabulky).

A nebo samozřejmě implementaci transakcí, která nepoužívá klasické zámky.

[Michal Kubeček]

3x slítla databáze znamená 3x několikahodinou a delší nedostupnost a omluvný text.

Jenže to může mít spousty různých příčin, do kterých zvenku nevidíte. Mně třeba nedávno dvakrát po sobě na dva dny vypadla aplikace, která do té doby při minimálních provozních nákladech měla downtime ročně v řádu jednotek hodin. Proč? Protože fyzicky odešel disk takovým způsobem, že sestřeloval systém, takže ani SW RAID nepomohl, a navíc se to stalo o víkendu a k serveru se nelze fyzicky dostat jindy, než v pracovní dny v pracovní dobu… Soudit podle vnějších projevů na to, že určité řešení je špatné, je hodně krátkozraké.

[Ondrej]

Ja bych to nevidel nijak kriticky. Takovejch 5, 6 serveriku, nemusi to ani bejt zadnej mega hi-end, propojeny do mosixovyho clusteru, na kterym by bezel webovej server. Jako databaze urcite postgreSQL kdyby to melo bejt 100% free nebo oracle. Chtelo by to docela dost RAMky na jednotlivejch strojich a docela slusne propustnej switch v tom clusteru. Osobne bych se pouziti PHP nebal, zas tak spatnej jazyk to neni. Co se tyce apache, tak na 100% dvojku skompilovanou s podporou threadu, at muze mosix delat svoji praci. Databazi bych dal na samostatnej cluster a spojil to poradnou linkou, idealne nekolika.

[Messa]

Myslíš, že mosixovej cluster by byl v něčem lepší, než kdyby na každém serveru bežel Apache zvlášť?

[Ondrej]

no, pak by se to muselo resit pres round-robin v DNSku. clusterovy reseni mi prijde jednodussi.

[Zdeněk Burda]

Existují i jiná řešení než round robin v DNS a existuje i jiný sw než apache

[VícNežNic]

Můžete třeba koupit několik tisíc dálnopisů (i když bych řekl, že by to dneska vyšlo podstatně dráž než ,obyčejné počítače`)a nechat tam odpovídající počet lidí ťukat odpovědi na HTTP požadavky ručně To by byla aplikace. I když se tím řeší jenom část problému.

[Zdeněk Burda]

Myslím, že v ČR by to mohlo mít úspěch třeba na v okolí Ostravy. Určitě by se tím dala hodně snížit nezaměstnanost.

[vencour]

Po rozmluvě s nejbližším okolím doplňuji screenshoty. Vše, co není černým písmem, je odkaz, většinou se jedná o popis o vlastnosti, kvality daného.

Úvodní strana
moje liga
záběr na seznam hráčů
možnosti tréninku
pohled na poslední zápasy
manipulace s klubem
místo pro obchod
místo pro řešení trablů - konfera
nakonec ještě možnosti jednoho hráče

[vencour]

(Jak tak čtu diskusi na rootuCz ohledně testu, napadá mne, že by mi jeden kámoš řek "je vidět, Venco, že tomu málo rozumíš" )