40/sec na 500/sec
IntroductionSurprised tým, že titul? dobre, to je výlet, ako sme popraskané škálovateľnosť uhranúť z manipulácie chudé 40 záznamov za sekundu na 500 záznamov za sekundu. Dajte si pozor, väčšina problémov, ktorým čelia sme boli vpred, môže to skúsení ľudia nájsť to zbytočné. Obsah * 1.0 Kde sme to skončili? 1.1 Memory hity oblohe 1,2 Nízka rýchlosť spracovania 1,3 strate dát :-( 1,4 Mysql nás ťahá nadol 1,5 Slow Web Client * 2.0 Road Nirvana2.1 na pamäti Controlling! 2.2 Zefektívnenie spracovanie sadzba 2,3 Aké straty dát uh-uh? 2.4 Ladenie SQL dotazov 2,5 ladenie schémy databázy MySQL 2.5 pomáha nám vyraziť vpred! 2.6 Faster ... rýchlejšie Web Client * 3.0 Bottom lineWhere sme? Pôvodne sme mali systém, ktorý by mohol iba v rozsahu až 40 záznamov / sec. Mohol by som ešte spomenúť diskusiu na tému "čo by malo byť ideálne miera záznamov?". Nakoniec sme sa rozhodli, že sa 40/sec ideálnu rýchlosť pre jeden firewall. Takže keď máme ísť von, aspoň sme potrebovali podporu 3 firewally. Z tohto dôvodu sme sa rozhodli, že 120/sec by bolo ideálne miery. Na základe údajov z nášho konkurenta (y) sme dorazili do záveru, že by mohli podporiť okolo 240/sec. Mysleli sme, že je to ok! ako to bolo naše prvé vydanie. Pretože všetky konkurentmi hovoril o počte firewall on podporoval, ale nie na rate.Memory hity skyOur pamäť bola vždy biť nebi aj na 512 mb! (OutOfMemory výnimky) sme vinu cewolf (y) inmemory cache vzniknutého images.But sme nemohli uniknúť na dlho! Nezáleží na tom, či sme pripojený klient alebo nie sme použili k hitu oblohe za pár dní, max 3-4 dni byt! Je zaujímavé, že to bolo reprodukovateľné, keď sme odoslaných dát na veľmi vysokej úrovni (potom), približne 50/sec. Uhádli ste pravdu, neobmedzený vyrovnávaciu pamäť, ktorá rastie, kým nenarazí roof.Low spracovanie rateWe bolo spracovanie záznamov vo výške 40/sec. Boli sme za použitie hromadného aktualizácia dataobject (y). Ale to sa nedá očakávať, rýchlosť! Pretože toto sme začali hromadiť dáta v pamäti za následok hromadenie pamäti! :-( strata dát pri veľmi vysokých rýchlostiach sme si ujsť veľa paketu (y). My sa zdalo, že má málo straty dát, ale vyústil v pamäti brav. On some tweaking obmedziť buffer Veľkosť sme začali mať trvalé strate dát približne 20% na veľmi vysokej rates.Mysql posadí nás downWe mali pred sebou ťažké časy, keď sme doviezli log súbor asi 140 megabajt Mysql začal ošípaná, stroj začal plaziť a niekedy to dokonca zastaviť responding.Above všetci, začali sme dostať deadlock (y) a transakcie timeout (y). Ktorý nakoniec znižuje reakcie system.Slow webe ClientHere sme opäť obvinil počet grafy sme ukázali na stránke, ako úzky profil, ignoruje skutočnosť, že existuje množstvo ďalších faktorov, ktoré boli potiahnutím systému nadol. Stránok, aby sa 30 sekúnd, aby záťaž na stránku s 6-8 grafov a tabuliek po 4 dňoch na internete Center.Road dát do pamäti NirvanaControlling! Snažili sme sa dať limit veľkosti vyrovnávacej pamäte na 10.000, ale to netrvalo dlho. Hlavné chybu v návrhu bolo, že sme sa predpokladalo, že buffer okolo 10.000 bude stačiť, tj by sme procese záznamy pred nárazníkovú 10,1000 dosiahne. Inline sa zásadou "Niečo sa môže pokaziť to sa pokazí!" nevyšlo to. Začali sme straty dát. Subsesquently sme sa rozhodli ísť s plochým súbor založený v medzipamäte, v ktorom boli dáta vyhodené do bytu a súbor by boli vložené do databázy pomocou "načítať dáta INfilm". To bolo mnohokrát rýchlejšie ako hromadnú vložiť pomocou ovládača databázy. Môžete tiež k pokladni niektoré možnosti optimalizácie sa načítať dáta INfilm. Táto fixná náš problém zvýšiť veľkosť vyrovnávacej pamäte zo surového records.The druhý problém, ktorým sme čelili bola zvýšenie cewolf (y) v cache mechanizmu. V predvolenom nastavení sa používa "TransientSessionStorage", ktorý ukladá do pamäte cache obraz objektov v pamäti, zdalo sa, že nejaký problém pri čistení objektov, dokonca aj po rerferences bolo stratené! Tak sme napísali malý "FileStorage" prevedení, ktoré uchovávajú obraz objektov v miestnej súbor. A bolo by slúžil ako a kedy príde žiadosť palcov Okrem toho sme tiež implmentated vyčistenie mechanizmus na čistenie nehybné obrazy (fotografie starší ako 10mins). Ďalším zaujímavým aspektom sme zistili, že tu bol zberateľ Garbage mal najnižšiu prioritu, takže objekty vytvorené pre jednotlivé záznamy, boli sotva upratal. Tu je malý matematický vysvetliť závažnosť problému. Kedykoľvek sme dostali záznam záznam sme vytvorili ~ 20 objektov (HashMap, tokenized reťazca atď), takže v pomere 500/sec za 1 sekundu, počet objektov bol 10000 (20 * 500 * 1). Vzhľadom k ťažkým spracovanie zberateľ odpadkové nikdy nemali možnosť vyčistenia objektov. Takže všetko, čo sme museli urobiť, bolo menšie štípnout, len účelovo "null" na objekt odkazy. Voila! odpadky zberateľ nikdy nebol mučený Myslím, že ;-) zefektívnenie spracovania rateThe spracovanie kurzu bola v chudé 40/sec to znamená, že by sme mohli len ťažko odolať aj malý výbuch log záznamov! Pamäte, dal nám útechu, ale skutočný problém bol s použitím záznamu filtre za záznamov. Mali sme asi 20 vlastnosti sú u všetkých záznamov, sme použili na vyhľadanie všetkých vlastností. Zmenili sme na realizáciu Zápas pre tie vlastnosti sme kritériá pre! Okrem toho sme tiež mali únik pamäte v zázname filter spracovania. Sme udržiava frontu, ktorá rástla navždy. Takže sme museli udržiavať byt súbor objekt dumping, aby sa zabránilo re-analýzy záznamov, ktoré sa tvoria predmety! Navyše sme robievala akt hľadanie zápas pre každú vlastnosť, aj keď sme nemali žiadne varovanie kritériá configured.What strate dát, uh-uh? Akonáhle sme pevnou pamäťou problémy v prijímaní dát, tj neriadené plochého súboru, nikdy sme stratené dáta! Okrem toho, že sme museli odstrániť pár nechcených indexy v surové tabuľke, aby sa zabránilo režijné, zatiaľ čo dumping dát. Sme Hadd indexy stĺpcov, ktoré by mohli mať maximálne 3 možných hodnôt. Ktoré skutočne vykonané vložiť pomalší a nebol useful.Tuning SQL QueriesYour vaše otázky sú kľúčom k výkonnosti. Akonáhle začnete nastreľovacie problémy, budete vidieť, že ste mohol dokonca mať až k de-normalizovať tabuľky. Dokázali sme to! Tu sú niektoré z najdôležitejšie poznatky: * Použite "Analyzovať tabuľku", aby zistil, ako funguje mysql dotazu. To vám dá predstavu o tom, prečo dotaz je pomalý, tj či ich používate správne indexy, či je použitie tabuľky úrovne skenovanie apod * Nikdy neodstraňujte riadky, keď jednáte s obrovským dát v poriadku 50.000 záznamov v jednej tabuľke. Sa vždy snažia robiť "drop table" čo najviac. Ak to nie je možné, redesign schémy, je to vaša jediná cesta von! * Vyhnúť sa nežiaduce vstup (y), nebojte sa, aby de-Normalize (tj duplicitná stĺpec hodnôt) Vyhnite sa pripojiť (y) čo možno najviac , majú tendenciu tahat svoju otázku nadol. Jeden skrytý výhodou je skutočnosť, že v jednoduchosti uložiť vaše otázky .* Ak máte čo do činenia s hromadnou dát, vždy používajte "načítať dáta INfilm" existujú dve možnosti, tu, miestne a vzdialené. Použitie miestnej ak mysql a aplikácie sú v rovnakom stroji inak používať diaľkový .* Snažte sa rozdeliť svoje zložité otázky na dva alebo tri jednoduchšie otázky. Výhody tohto prístupu je, že mysql zdroj nie je upína sa na celý proces. Inklinujú k použitie dočasné tabuľky. Namiesto použitia jediného dotazu, ktorá sa rozpína po celej tabuľky 5.6 .* Keď sa zaoberá veľké množstvo dát, teda proces, ktorý chcete povedať, 50000 záznamy a viac v jednom dotaze skúste použiť limit pre dávkové spracovanie záznamov. To vám pomôže mierka systému do nových výšok * Vždy používajte menšie transakcie (y) namiesto veľkých tj kostra v "n" tabuľky. Tento uzamkne mysql zdroje, ktoré by mohli spôsobiť pomalosť systému aj na jednoduché otázky * Použitie join (y) na stĺpoch s indexmi alebo cudzie kľúče * Uistite sa, že otázky z užívateľského rozhrania, majú kritériá alebo obmedziť .* tiež zabezpečiť, že kritériá stĺpec indexovaný * Nemáte číselnej hodnoty v SQL kritérií do úvodzoviek, pretože to mysql typu obsadení * použitie dočasné tabuľky čo najviac, a pokles to ...* Doplnenie vybrať / zmazať je dvojaký tabuľky zámok ... byť si vedomý ...* Postarajte sa, že nemáte bolesti mysql databázy frekvenciu aktualizácií do databázy. Mali sme typický prípad sme na skládku do Databáza po každých 300 záznamov. Takže keď sme začali testovanie 500/sec začali sme videli, že mysql doslova ťahal nás. To je, keď sme si uvedomili, že typically vo výške 500/sec je "načítať dáta INfilm" žiadosť každú sekundu na MySQL databázu. Takže sme museli zmeniť na výpis záznamov po 3 minútach ako 300 records.Tuning databázy schemaWhen jednáte s obrovskými objemami dát, vždy zabezpečiť že rozdelovat dát. To je vaša cesta k škálovateľnosť. Jednoduchú tabuľku s povedzme 10 lakhs nikdy meradle. Keď máte v úmysle vykonávať otázky na správy. Vždy mať dve úrovne stoly, stolíky surového jeden pre aktuálne informácie a ďalšie nastavenia pre správy tabuliek (tabuľky, ktoré užívateľské rozhranie, na dotaz!) vždy zabezpečí, že údaje o vašej správe tabuľky nikdy porastie nad limit. Zapouzdřit plánujete používať Oracle, môžete vyskúšať rozdelenie na základe kritérií. Mysql, ale bohužiaľ nepodporuje to. Takže sa budeme musieť urobiť. Zachovať meta tabuľku, v ktorej máte informácie v hlavičke, tj tabuľky, ktoré sa hľadať, pre daný súbor kritérií, zvyčajne čas .* Museli sme prejsť si naše schému databázy a sme pridali pridať niektoré indexy, odstráňte niektoré aj duplicitné stĺpca (y), nákladné vstup (y) .* Do budúcnosti sme si uvedomili, že mať surové tabuľky InnoDB, ako bol v skutočnosti nad hlavou do systému, takže sme to zmenil na MyISAM * Tiež sme šli do tej miery znížiť počet riadkov v statických tabuľkách zúčastňuje sa pripojí * NULL v databáze tabuľky sa zdá spôsobiť zníženie výkonu, a tak sa im vyhnúť * Nemáte indexy na stĺpcoch, ktorá umožnila hodnoty 2.3 * Cross skontrolovať, že je potrebné pre každý index v tabuľke, sú nákladné. Ak sú tabuľky InnoDB potom dvakrát skontrolujte ich potreby. Vzhľadom k tomu, InnoDB tabuľky Zdá sa, že približne 10-15 krát väčšie ako MyISAM tabuliek MyISAM .* Používajte vždy, keď je väčšina, a to buď jeden (alebo vyberte vložiť) dotazov. Je-li vložiť a vyberte možnosť sa bude viac, potom je lepšie mať to ako InnoDBMysql nám pomáha postupovať vpred! Nalaďte si MySQL server až po jemné vyladenie vašich dotazov / schémy a kód. Až potom môžete vidieť zreteľné zlepšenie výkonnosti. Tu sú niektoré z parametrov, ktoré príde vhod: * Použite vyrovnávacej pamäte veľkosti bazéna, ktorý umožní vaše otázky k výkonu rýchlejšie - innodb_buffer_pool_size = 64M pre InnoDB a použitie - Kľúč-bufer-size = 32M pre MyISAM * Dokonca aj jednoduché otázky začala brať viac času, ako sa očakávalo. Boli sme naozaj zmätený! Uvedomili sme si, že mysql Zdá sa, že zaťaženie indexu každého stola začína na vkladanie. Tak čo typicky sa stalo, bola každý jednoduchý dotaz na tabuľku s 5-10 riadky sa okolo 1-2 sekúnd. Na ďalšej analýze sme zistili, že tesne predtým, ako jednoduchý dotaz: "načítať dáta INfilm" sa stalo. Tento zmizlo, keď sme zmenili surový tabuľky typu MyISAM, pretože veľkosť vyrovnávacej pamäte pre MyISAM a InnoDB sú dva rôzne configurations.for viac konfigurovateľné parametre pozri here.Tip: spustenie mysql začať s nasledujúce voľby - Log-error to umožnia, aby dlh loggingFaster ... ClientThe rýchlejší webové používateľské rozhranie je kľúčové, aby všetky výrobky, najmä vnímanej rýchlosti stránky je dôležitejšie! Tu je zoznam riešenia a poznatky , Ktoré by mohli prísť vhod: * Ak sú dáta sa nebude meniť za 3-5 minúty povedať, že je lepšie cache stránok strane klienta * inklinujú k použitie Iframe (y) pre vnútorné grafy atď dávajú vnímané stálosťou na Vaše stránky. Ešte lepšie je použiť na javascript obsahu nakladacie mechanizmus. To je niečo, čo budete chcieť robiť, keď máte povedať, 3 + grafy v tej istej stránke .* Internet Explorer zobrazí celú stránku len vtedy, keď všetky obsah prijaté zo servera. Tak to je vhodné použiť iframe a javascriptu obsahu nakladanie .* Nikdy nepoužívajte viac / duplicitné záznamy v súbore CSS v html stránke. Internet explorer inklinuje k zaťaženia jednotlivých CSS súbor ako samostatná položka a vzťahuje sa na kompletný stránky! Bottomline Vaše otázky a schémy, aby systém pomalšie! Opraviť a potom vinu databáze! Pozri tiež * High Performance MySQL Performance * Otázka *
Článok Zdroj: Messaggiamo.Com
Related:
» Seo Elite: New Seo Software!» AntiSpywareBOT
» Reverse Mobile
» Error Nuker
Webmaster si html kód
Pridajte tento článok do svojich webových stránok sa!
Webmaster Pošlite svoj článok
Nie nutná registrácia! Vyplňte formulár a Váš článok je v Messaggiamo.Com Adresár!
