Ruby on Rails är enkelt och snabbt att utveckla i. Att driftsätta det är en annan historia, det finns många olika sätt att göra det på. Till vardags kör vi ofta Nginx och Unicorn, men idag fick vi uppdraget att snurra upp lite mer prestanda i en befintlig installation med Ruby on Rails, Apache och Passenger.

Det finns några flaggor i Passenger- och Apache-konfigurationen som är bra att ha koll på. Vi kan börja med några som typiska Rails-projekt kan sätta på en gång.

PassengerHighPerformance on
Det här är en inställning som slår av lite ”onödiga” moduler, såsom mod_rewrite, directory-index och annat som vanligtvis inte används av Rails-appar. Testa att slå på den och se om din app lirar på som förut, fast nu lite snabbare.

PassengerStatThrottleRate 60
Passenger kollar flera filer på disk vid varje request. Det handlar om exempelvis .htaccess, tmp/restart.txt, config/environment.rb, config.ru m.fl finns och vad de innehåller. Helt onödigt att kolla vid varje request i produktionsläge, och vi brukar vara nöjda om en omstart sker inom en minut när vi kör en touch tmp/restart.txt vid exempelvis deploy.

Antal processer

Ett vanligt mått att utgå ifrån är antalet transaktioner per sekund (TPS) som applikationen kan hantera. I det här fallet hade vi ett målmått på omkring 1000 TPS. Maskinen vi hade att jobba med hade 16 GB tillgängligt minne och gott om hårddiskutrymme.

Det vi började med att kolla är hur mycket minne varje Rails-process tog med hjälp av kommandot passenger-memory-status. Snittet verkade ligga omkring 65 MB per process. För att räkna ut hur många instanser av Passenger vi har råd att dra igång brukar vi höfta med omkring 75 % av det tillgängliga minnet – i det här fallet 16 GB * 0,75 / 64 MB = 192 processer.

**PassengerMaxPoolSize **175

Den här inställningen åker in i PassengerMaxPoolSize som talar om hur många processer vi max drar igång. Jag brukar avrunda ytterligare lite nedåt i början om vi misstänker att applikationen kan växa lite i minnesutnyttjande längre fram.

PassengerMinInstances 175
Den här flaggan sätter vi vanligtvis ganska lågt, kanske 2 eller 10 procent av maxvärdet, men i det här fallet skulle vi vara beredda på väldigt höga laster på kort tid och ändå ha låga svarstider. Det innebär att vi väljer samma värde på Min och Max, så det kommer alltid snurra 175 Passenger-instanser som är redo att jobba. I annat fall har du en uppstart på 5-15 sekunder på en ny instans, vilket vid ovanligt höga trafikspikar kan märkas (fast oftast inte, har du inte en mycket bestämd kund så sätt den lågt och spara på processorcyklerna).

*config/database.yml
**För att du inte ska få slut på databaskopplingar kan det vara smart att sätta 
pool: 175* i config/database.yml. Det är alltså samma värde som antalet PassengerInstanser.

Apache

Slå av så många moduler du bara kan. Varje modul du laddar in drar ytterligare ett antal MB i minnet. Vi gick igenom apache-konfigen och slog av drygt 75 % av modulerna som fanns listade där. Vilka du använder har du antagligen koll på själv, annars är det bara att testa att slå av de du tror, starta om servern och se om den klagar på något (vilket vanligtvis sker direkt vid första sidladdningen eller vid uppstart av servern). Vi fick ner minnesanvändningen med omkring 40% med hjälp av detta.

Databas

Vid högtrafik sätter vi alltid databasen på en egen server om det är möjligt. I annat fall få du ta hänsyn till det minne databasen använder.

Hur mycket klarar vi av?

Genom att analysera loggfilerna eller köra ett Apache Benchmark-test på någon eller några sidor kan du läsa av hur lång tid ett anrop tar i snitt. Vanligtvis ligger det här någonstans mellan 50 ms och 800 ms. Allt under 200 ms är bra, under 500 ms är oftast okej vid hög last.

Säg att vi får i snitt 250 ms per request. Då innebär det att vår ovanstående setup ska klara av 4 request per sekund * 175 Passenger-instanser, totalt 700 requests per sekund. Vi behöver upp i 250 workers totalt för att hantera vårt totalmål på 1000 requests per sekund, och det hanterar vi antingen med mer kräm i nuvarande burk, eller en kopia på den här servern och lägger allt bakom en lastbalanserare. Det senare är att föredra då det även ger redundans.

 

 

Du är väl med på VIP-listan?

Om du vill ha koll på nyheter inom webbdesign och vara bland de första som hör om våra nya projekt ska du såklart göra som hundratals andra designers och företagare - gå med i vår VIP-lista.