Jag har ägnat lite tid åt att ställa in min app på heroku och har ägnat en del tid åt att arbeta med prestandajustering av Rails-appar i en mängd olika inställningar.
När jag kör ab -n 300 -c 75 ...myapp.com.... # som är en säkerhetskopia till min huvudsajt och är på den kostnadsfria cedarplanen med unicorn
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)
(det här är mot en startsida som inte gör något intensivt, så jag tillhandahåller det bara som ett "hur snabbt kan Heroku vara på gratisplanen med en mycket enkel sida?", inte ett "dina appar ska vara så här snabbt")
Här är min checklista för Rails Performance Tuning 101:
-
Mät laddningstiden för webbläsaren/sidan först (webbläsaren gör många förfrågningar, ab berättar bara om en av dem, och vanligtvis är det inte din huvudsidesbegäran som är problemet), hämta baslinjesiffror för sidladdning från verktyg som www.webpagetest.org eller www.gtmetrix.com för de offentliga sidorna, eller webbläsarverktygen Yslow, google page speed eller dynatrace för de privata sidorna. Om du tittar på sidladdningsvattenfallsdiagrammet ('Net'-panelen i chrome/firefox) visar det vanligtvis att din html laddas snabbt (under en sekund), men sedan tar allt annat 1-3 sekunder att ladda. Följ rekommendationerna för Yslow/sidahastighet om hur du kan förbättra (se till att du använder Rails 3.1-tillgångarnas pipeline-prylar till fullo)
-
Läs igenom dina loggfiler/nya reliker för att hitta den "långsammaste/mest träffade"-förfrågan, och profilera vad som händer för den förfrågan (är det långsam rubin/mycket minnesanvändning eller många frågor?) Du behöver att ha ett tillförlitligt sätt att upptäcka och övervaka prestandaproblem, och inte bara ändra saker på måfå. När du har identifierat några målområden, skapa testskript för att hjälpa till med före/efter testning och bevisa att din förändring hjälper, och upptäck om en regression smyger sig in.
-
Brist på index på db-kolumner är ett av de vanligaste problemen, och det är lättast att åtgärda. Kör förklara på målfrågorna, eller titta igenom din långsamma frågelogg för att se vad frågeplaneraren gör. Lägg till index för främmande nycklar, sökkolumner eller primära data (täckande index) efter behov. Testa igen med faktiska produktionsdata för att bevisa att det gör skillnad. (du kan köra explain i heroku, samt köra frågor för saknade eller oanvända index)
-
De flesta Rails-appar med dålig prestanda lider av N+1-frågor eftersom det är så lätt att skriva order.owner.address.city och inte tänka på vad som händer när det är i en loop. N+1-frågor är inte nödvändigtvis långsamma frågor, så de visas inte i den långsamma frågeloggen, det är bara att det finns många av dem, och det är mer effektivt att göra allt på en gång. Använd :include eller .includes() för ivrig inläsning av den datan, eller titta på att göra din fråga på ett annat sätt.
-
Analysera flödet av din app och leta efter cachningsmöjligheter. Om användaren studsar fram och tillbaka mellan indexsidan och en detaljsida, och tillbaka igen, kanske en ajax-vy av detaljerna, utan att lämna indexsidan, skulle ge dem den information de behöver på ett snabbare sätt. Jag skrev några fler tankar om det på min blogg
Jag höll en presentation om dessa tekniker och andra idéer i Chicago på årets WindyCityRails-konferens. Du kan se videon här på min www.RailsPerformance .com-bloggen Det jag älskar med heroku är att du måste vara skalbar från början. När du tittar på diskussionerna på e-postlistan ser du att de flesta är medvetna om de bästa praxis för prestanda och hur man får ut det mesta av servern. Jag gillar också hur du, om du vill bo billigt, lär dig hur prestandajusteringar knep som kommer att få dig mest bang.
Lycka till!