Jeg har brugt noget tid på at tune min app på heroku og har brugt noget tid på at arbejde på ydeevnejustering af Rails-apps i en række forskellige indstillinger.
Når jeg kører ab -n 300 -c 75 ...myapp.com.... # som er en backup til mit hovedwebsted og er på den gratis ceder-plan med enhjørning
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)
(dette er imod en startside, der ikke gør noget intenst, så jeg giver det kun som et "hvor hurtigt kunne heroku være på den gratis plan med en meget simpel side?" eksempel, ikke et "dine apps skal være så hurtigt")
Her er min Rails Performance Tuning 101-tjekliste:
-
Mål browser-/sideindlæsningstiden først (browseren laver mange anmodninger, ab fortæller dig kun om én af dem, og normalt er din hovedsideanmodning ikke problemet), få sideindlæsningsbasislinjetal fra værktøjer som www.webpagetest.org eller www.gtmetrix.com for de offentligt vendte sider, eller browserværktøjer Yslow, google page speed eller dynatrace for de private sider. Hvis du ser på sideindlæsnings-vandfaldsdiagrammet ('Net'-panelet i chrome/firefox), viser det normalt, at din html indlæses hurtigt (under et sekund), men så tager alt andet 1-3 sek. at indlæse. Følg Yslow/sidehastighedsanbefalingerne om, hvordan du forbedrer (sørg for, at du bruger Rails 3.1-aktivernes pipeline-ting i dets fulde omfang)
-
Læs dine logfiler/nye levn igennem for at finde det søde sted for anmodningen 'langsomst/hyppigst ramt', og profilér, hvad der sker for den anmodning (er det langsom rubin/meget hukommelsesbrug eller masser af forespørgsler?) Du har brug for at have en pålidelig måde at opdage og overvåge ydeevneproblemer på, og ikke bare gå og ændre ting tilfældigt. Når du har identificeret nogle målområder, skal du oprette testscripts for at hjælpe med før/efter test og bevise, at din ændring hjælper, og opdage, om en regression kommer snigende.
-
Mangel på indekser på db-kolonner er et af de mest almindelige problemer, og det er nemmest at løse. Kør forklaring på målforespørgslerne, eller se din langsomme forespørgselslog igennem for at se, hvad forespørgselsplanlæggeren laver. Tilføj indekser for fremmednøgler, søgekolonner eller primære data (dækkende indeks) efter behov. Gentest med faktiske produktionsdata for at bevise, at det gør en forskel. (du kan køre forklaring i heroku, samt køre forespørgsler for manglende eller ubrugte indekser)
-
De fleste dårligt ydende Rails-apps lider af N+1-forespørgsler, fordi det er så nemt at skrive order.owner.address.city og ikke tænke på, hvad der sker, når det er i en løkke. N+1-forespørgsler er ikke nødvendigvis langsomme forespørgsler, så de vises ikke i den langsomme forespørgselslog, det er bare, at der er mange af dem, og det er mere effektivt at gøre det hele på én gang. Brug :include eller .includes() til ivrig indlæsning af disse data, eller se på at udføre din forespørgsel på en anden måde.
-
Analyser strømmen af din app og se efter muligheder for caching. Hvis brugeren hopper frem og tilbage mellem indekssiden og en detaljeringsside, og tilbage igen, vil en ajax-visning af detaljerne, uden at forlade indekssiden, måske give dem de data, de har brug for på en hurtigere måde. Jeg skrev nogle flere tanker om det på min blog
Jeg holdt en præsentation om disse teknikker og andre ideer i Chicago på dette års WindyCityRails-konference. Du kan se videoen her på min www.RailsPerformance .com-blog Det, jeg elsker ved heroku, er, at du skal være skalerbar fra starten. Når du ser på diskussionerne på mailinglisten, kan du se, at de fleste er opmærksomme på de bedste praksisser for ydeevne, og hvordan man får mest muligt ud af serveren. Jeg kan også godt lide, hvordan du, hvis du vil forblive billigt, lærer, hvordan de præstationsjusteringstricks, der vil give dig mest knald.
Held og lykke!