Ladění výkonu kolejnic pro výrobu?

Strávil jsem nějaký čas laděním své aplikace na heroku a nějaký čas jsem strávil prací na ladění výkonu aplikací Rails v různých nastaveních.

Když spustím ab -n 300 -c 75 ...myapp.com.... #, což je záloha mého hlavního webu a je na bezplatném cedrovém plánu s jednorožcem

Requests per second:    132.11 [#/sec] (mean)
Time per request:       567.707 [ms] (mean)
Time per request:       7.569 [ms] (mean, across all concurrent requests)

(toto je proti domovské stránce, která nedělá nic intenzivního, takže to poskytuji pouze jako příklad „jak rychle by mohlo být heroku na bezplatném plánu s velmi jednoduchou stránkou?“, nikoli jako „vaše aplikace by měly být takhle rychle")

Zde je můj kontrolní seznam Rails Performance Tuning 101:

1. Nejprve změřte dobu načítání prohlížeče/stránky (prohlížeč odešle mnoho požadavků, ab vám řekne pouze o jednom z nich a obvykle problém není váš požadavek na hlavní stránku), získejte základní čísla načítání stránky z nástrojů jako www.webpagetest.org nebo www.gtmetrix.com pro veřejné stránky nebo nástroje prohlížeče Yslow, rychlost stránky Google nebo dynatrace pro soukromé stránky. Pokud se podíváte na diagram vodopádu načítání stránky (panel 'Net' v prohlížeči chrome/firefox), obvykle ukazuje, že se váš html načítá rychle (za sekundu), ale načtení všeho ostatního trvá 1–3 sekundy. Postupujte podle doporučení Yslow/rychlosti stránky o tom, jak se zlepšit (ujistěte se, že používáte kanál aktiv Rails 3.1 v plném rozsahu)

2. Pročtěte si soubory protokolu/novou relikvii, abyste našli sladké místo „nejpomalejšího/nejčastěji zasaženého“ požadavku, a vytvořte profil, co se stane s tímto požadavkem (je to pomalý rubín/mnoho využití paměti, nebo spousta dotazů?) Potřebujete mít spolehlivý způsob, jak zjišťovat a monitorovat problémy s výkonem, a ne jen náhodně měnit věci. Jakmile identifikujete některé cílové oblasti, vytvořte testovací skripty, které vám pomohou s testováním před/po testování a prokážou, že vaše změna pomáhá, a zjistěte, zda se vloudila regrese.

3. Nedostatek indexů ve sloupcích db je jedním z nejčastějších problémů a je nejjednodušší jej vyřešit. Spusťte vysvětlení na cílové dotazy nebo si prohlédněte protokol pomalých dotazů a zjistěte, co dělá plánovač dotazů. Podle potřeby přidejte indexy pro cizí klíče, vyhledávací sloupce nebo primární data (krycí index). Znovu otestujte se skutečnými výrobními daty, abyste prokázali, že je to rozdíl. (vysvětlit můžete spustit v heroku a také spouštět dotazy na chybějící nebo nepoužívané indexy)

4. Většina aplikací Rails se špatným výkonem trpí N+1 dotazy, protože je tak snadné napsat order.owner.address.city a nemyslet na to, co se stane, když je to ve smyčce. Dotazy N+1 nejsou nutně pomalé dotazy, takže se nezobrazují v protokolu pomalých dotazů, jen je jich spousta a je efektivnější to udělat všechny najednou. Použijte :include nebo .includes() pro dychtivé načítání těchto dat, nebo se podívejte na provedení dotazu jiným způsobem.

5. Analyzujte tok vaší aplikace a hledejte možnosti ukládání do mezipaměti. Pokud uživatel poskakuje tam a zpět mezi stránkou indexu a stránkou s podrobnostmi a zase zpět, možná by mu iaxové zobrazení podrobností, aniž by opustil stránku indexu, poskytlo data, která potřebují, rychleji. Napsal jsem několik dalších myšlenek o tom na svém blogu

O těchto technikách a dalších nápadech jsem přednesl prezentaci v Chicagu na letošní konferenci WindyCityRails. můžete vidět video zde na mém www.RailsPerformance blog .com Na heroku miluji to, že musíte být od začátku škálovatelní. Když se podíváte na diskuze na mailing listu, uvidíte, že většina lidí si je vědoma osvědčených postupů pro výkon a jak ze serveru vytěžit maximum. Také se mi líbí, jak když chcete zůstat levní, naučíte se triky s laděním výkonu, které vás dostanou nejvíc.

Hodně štěstí!