Passenger su heroku

Ho trovato oggi questo articolo:

http://www.stormconsultancy.co.uk/blog/development/how-to-get-more-bang-for-your-heroku-buck-while-making-your-rails-site-super-snappy-redux/

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:

http://lists.ruby-it.org/mailman/listinfo/ml


Simone C.
Passionate programmer and dive instructor

http://simonecarletti.com/
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 (
https://github.com/unbit/uwsgi-docs/blob/master/tutorials/heroku_python.rst
).

In ogni caso uWSGI vi cambia la vita, quindi provatelo se potete :slight_smile:
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, piu worker 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

http://simonecarletti.com/
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: piutraffico arriva, piu worker fa partire, e poi li
killa quando non servono piu`. Sembra che anche Puma faccia questo -
anche Unicorn?


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Io consiglio uwsgi. Non ho ancora avuto l’occasione di provarlo su heroku
con ruby, ma so che ce lo fanno girare con python (
https://github.com/unbit/uwsgi-docs/blob/master/tutorials/heroku_python.rst
).

In ogni caso uWSGI vi cambia la vita, quindi provatelo se potete :slight_smile:
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 :slight_smile:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs