Ho trovato oggi questo articolo:
parla di come usare Passenger su Heroku, l’ho trovato molto
interessante.
Qualcuno lo usa?
Passenger e’ comodo su sistemi dove hai gia’ Apache, poiche’ e’ di
facile
configurazione.
In passato, era anche un’ottima soluzione sotto Nginx poiche’ non
esistevano alternative apprezzabili.
Al momento preferisco decisamente Puma o Unicorn.
Configurare Puma sotto Heroku e’ incredibilmente semplice.
– Simone
On Fri, Dec 20, 2013 at 9:36 AM, Fabrizio R.
[email protected]wrote:
–
Simone C.
Passionate programmer and dive instructor
Twitter: @weppos https://twitter.com/weppos
Io consiglio uwsgi. Non ho ancora avuto l’occasione di provarlo su
heroku
con ruby, ma so che ce lo fanno girare con python (
).
In ogni caso uWSGI vi cambia la vita, quindi provatelo se potete 
Abbiamo
anche scritto un articolo a riguardo (
http://dev.mikamai.com/post/69680190127/start-a-rails-4-full-featured-application-with-uwsgi)
che stato anche pubblicato da ruby weekly proprio oggi.
2013/12/20 Simone C. [email protected]
2013/12/20 David W. [email protected]
In passato, Passenger aveva anche il vantaggio che ‘scala’
dinamicamente: piutraffico arriva, piuworker fa partire, e poi li
killa quando non servono piu`. Sembra che anche Puma faccia questo -
anche Unicorn?
Si’, Puma consente di specificare un numero di worker minimo e massimo.
Che
io sappia, lo stesso non e’ possibile con Unicorn.
–
Simone C.
Passionate programmer and dive instructor
Twitter: @weppos https://twitter.com/weppos
Passenger e’ comodo su sistemi dove hai gia’ Apache, poiche’ e’ di facile
configurazione.
In passato, era anche un’ottima soluzione sotto Nginx poiche’ non
esistevano alternative apprezzabili.
Al momento preferisco decisamente Puma o Unicorn.
In passato, Passenger aveva anche il vantaggio che ‘scala’
dinamicamente: piu traffico arriva, piu worker fa partire, e poi li
killa quando non servono piu`. Sembra che anche Puma faccia questo -
anche Unicorn?
–
David N. Welton
Io consiglio uwsgi. Non ho ancora avuto l’occasione di provarlo su heroku
con ruby, ma so che ce lo fanno girare con python (
uwsgi-docs/tutorials/heroku_python.rst at master · unbit/uwsgi-docs · GitHub
).In ogni caso uWSGI vi cambia la vita, quindi provatelo se potete
Abbiamo
anche scritto un articolo a riguardo (
http://dev.mikamai.com/post/69680190127/start-a-rails-4-full-featured-application-with-uwsgi)
che stato anche pubblicato da ruby weekly proprio oggi.
Il tutorial per ruby e’ qui:
http://uwsgi-docs.readthedocs.org/en/latest/tutorials/heroku_ruby.html
notare che nella sezione “adaptive process spawning” si sconsiglia
l’approccio perche’ non ha il minimo senso su una piattaforma come
heroku,
anzi peggiora la situazione.
L’articolo linkato (quello su passenger) tra l’altro e’ parecchio
discutibile visto che parla di multithread quando passenger e’
multiprocesso e inoltre trovo veramente difficoltoso credere che
heroku proxy → nginx → passenger (eh si anche passenger e’ un proxy
sebbene molti lo ignorino)
sia piu’ efficiente di
heroku proxy → unicorn|puma|uWSGI|thin
l’hardware di heroku non brilla certo per performance quindi ogni
singolo
context switch (o ipc in generale) ha un costo pesante
Il mio consiglio e’ che se vi finisce la memoria sui dyno di heroku,
passate ad un approccio proattivo (ovvero l’application server riavvia i
worker che stanno esagerando o chiama la GC volontariamente).
L’adaptive process spawning come forma di “economia delle risorse” e’
davvero anni 90 ed apache-centrica, ha senso in altri mille contesti ma
non in un container da 500 MB