Langsamer anfänglicher Serverstart bei Verwendung von Phusion Passenger and Rails

Um auf den Zug von Phusion Passenger zu springen, haben wir einen Staging-Server für eine kleine Rails-App eingerichtet, um die Dinge zu testen.

Bisher war es sehr schön zu bedienen, es macht das Installieren / Konfigurieren und Bereitstellen von Apps zum Kinderspiel. Das Problem ist, dass die von uns verwendete Site nicht sehr oft getroffen wird und die Server im Hintergrund herunterzufahren scheint. Das heißt, wenn jemand die Site besucht, muss er sehr lange warten, bis ein neuer Server gestartet wird, um die Anforderung zu bearbeiten. Wir haben die Dokumentation gelesen, einige verschiedene Einstellungen ausprobiert (Smart / Smart-Lv2-Modi, Passagierzeit usw.) und immer noch keine echte Lösung gefunden.

Nach dem Durchsuchen der Google-Ergebnisse können wir keine wirklich nützlichen Informationen finden. Derzeit haben wir einen Cron-Job, der von Zeit zu Zeit eine Anfrage stellt, um die Server am Laufen zu halten.

Tritt bei jemand anderem dieses Problem auf und haben Sie Ratschläge für eine Lösung?

Was passiert ist, dass Ihre Anwendung und / oder ApplicationSpawners aufgrund einer Zeitüberschreitung heruntergefahren werden. Um Ihre neue Anfrage zu bearbeiten, muss Passenger eine neue Kopie Ihrer Anwendung starten, was selbst auf einem schnellen Computer einige Sekunden dauern kann. Um das Problem zu beheben, gibt es einige Apache-Konfigurationsoptionen, mit denen Sie Ihre Anwendung am Leben erhalten können.

Hier ist speziell, was ich auf meinen Servern getan habe. Die PassengerSpawnMethod und PassengerMaxPreloaderIdleTime sind die Konfigurationsoptionen, die in Ihrer Situation am wichtigsten sind.

# Speeds up spawn time tremendously -- if your app is compatible. 
# RMagick seems to be incompatible with smart spawning
# Older versions of Passenger called this RailsSpawnMethod
PassengerSpawnMethod smart

# Keep the application instances alive longer. Default is 300 (seconds)
PassengerPoolIdleTime 1000

# Keep the spawners alive, which speeds up spawning a new Application
# listener after a period of inactivity at the expense of memory.
# Older versions of Passenger called this RailsAppSpawnerIdleTime
PassengerMaxPreloaderIdleTime 0

# Just in case you're leaking memory, restart a listener 
# after processing 5000 requests
PassengerMaxRequests 5000

Wenn Sie den "intelligenten" Laichmodus verwenden und PassengerMaxPreloaderIdleTime deaktivieren, speichert Passenger immer 1 Kopie Ihrer Anwendung im Speicher (nach der ersten Anforderung nach dem Starten von Apache). Einzelne ApplicationHörer werden forkaus dieser Kopie herausgeschnitten, was eine supergünstige Operation ist. Es passiert so schnell, dass Sie nicht sagen können, ob Ihre Anwendung einen Listener erzeugen musste oder nicht.

Wenn Ihre App nicht mit Smart Spawning kompatibel ist, würde ich empfehlen, eine große PassengerPoolIdleTime beizubehalten und Ihre Website regelmäßig mit Curl und einem Cronjob oder Monit oder etwas anderem aufzurufen, um sicherzustellen, dass der Hörer am Leben bleibt.

Das Passagier-Benutzerhandbuch ist eine hervorragende Referenz für diese und weitere Konfigurationsoptionen.

Bearbeiten : Wenn Ihre App nicht mit Smart Spawning kompatibel ist, gibt es einige neue Optionen , die sehr hilfreich sind

# Automatically hit your site when apache starts, so that you don't have to wait
# for the first request for passenger to "spin up" your application. This even
# helps when you have smart spawning enabled. 
PassengerPreStart http://myexample.com/
PassengerPreStart http://myexample2.com:3500/

# the minimum number of application instances that must be kept around whenever 
# the application is first accessed or after passenger cleans up idle instances
# With this option, 3 application instances will ALWAYS be available after the
# first request, even after passenger cleans up idle ones
PassengerMinInstances 3

Wenn Sie also PassengerPreStart und PassengerMinInstances kombinieren, wird Passenger unmittelbar nach dem Laden von Apache 3 Instanzen hochfahren und immer mindestens 3 Instanzen hochhalten, sodass Ihre Benutzer selten (wenn überhaupt) eine Verzögerung feststellen.

Wenn Sie bereits Smart Spawning (empfohlen) verwenden PassengerMaxPreloaderIdleTime 0, können Sie hinzufügen PassengerPreStart, um den zusätzlichen Vorteil eines sofortigen Starts zu erhalten.

Vielen Dank an die Helden von phusion.nl !

Nur für den Fall, dass Benutzer von Nginx-Servern auf diese Frage stoßen, werden die Anweisungen 'PassengerMaxRequests' und 'PassengerStatThrottleRate' nicht in Nginx übersetzt. Die anderen tun jedoch:

rails_spawn_method smart;
rails_app_spawner_idle_time 0;
rails_framework_spawner_idle_time 0;
passenger_pool_idle_time 1000;

HTH!

EDIT rails_spawn_methodwird in Passagier 3 nicht mehr verwendet

passenger_spawn_method smart; 

Alles andere ist bis heute gut.

Sie können auch PassengerMinInstances verwenden:

http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerMinInstances

Dies kann mit PassengerPreStart kombiniert werden

RE:

# Additionally keep a copy of the Rails framework in memory. If you're 
# using multiple apps on the same version of Rails, this will speed up
# the creation of new RailsAppSpawners. This isn't necessary if you're
# only running one or 2 applications, or if your applications use
# different versions of Rails.
RailsFrameworkSpawnerIdleTime 0

Nur etwas hinzuzufügen und könnte nützlich sein.

Die Standard-Spawn-Methode in der aktuellen Version ist "smart-lv2", wodurch das Framework-Spawner übersprungen wird. Das Festlegen des Framework-Spawner-Timeouts hat daher ohnehin keine Auswirkungen, es sei denn, Sie setzen die Spawn-Methode explizit auf "smart".

Quelle: http://groups.google.com/group/phusion-passenger/browse_thread/thread/c21b8d17cdb073fd?pli=1

Wenn Ihr Host ein gemeinsam genutzter Server ist, wie meiner, können Sie die Einstellungen nicht ändern und bleiben bei einem Cron-Job hängen.

Ich hatte auch dieses Problem, konnte aber die Passagiereinstellungen nicht ändern, da ich keine Schreibberechtigung für diese Datei hatte. Ich habe ein Werkzeug gefunden ( http://www.wekkars.com ), mit dem meine App schnell reagiert. Vielleicht kann dies auch eine Lösung für Sie sein.

Überprüfen Sie die Version des Passagiers. es war RailsSpawnMethod<string> für alte Versionen.

Wenn ja (wenn ich mich richtig erinnere), ersetzen Sie den Passagier in allen Konfigurationsanweisungen durch Schienen oder suchen Sie nach alten Passagierdokumenten, um weitere Informationen zu erhalten