Forum: Italian Ruby user group Passenger su heroku

Cb8e3a1650513848561ca38f84399fa1?d=identicon&s=25 Fabrizio Regini (freegenie)
on 2013-12-20 09:36
(Received via mailing list)
Ho trovato oggi questo articolo:

http://www.stormconsultancy.co.uk/blog/development...

parla di come usare Passenger su Heroku, l'ho trovato molto
interessante.
Qualcuno lo usa?
99e0b39c091e10d9c7d4452a34ca52dc?d=identicon&s=25 Simone Carletti (weppos)
on 2013-12-20 12:04
(Received via mailing list)
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 Regini
<freegenie@gmail.com>wrote:

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



--
Simone Carletti
Passionate programmer and dive instructor

http://simonecarletti.com/
Twitter: @weppos <https://twitter.com/weppos>
Ae9847c1947c007e5d22b2cfd4ce4eed?d=identicon&s=25 Nicola Racco (gawaine)
on 2013-12-20 12:12
(Received via mailing list)
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/tu...
).

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-ra...)
che  stato anche pubblicato da ruby weekly proprio oggi.


2013/12/20 Simone Carletti <weppos@weppos.net>
9daa9b4739a6e95078cbcfb624d7bb8e?d=identicon&s=25 David Welton (Guest)
on 2013-12-20 12:12
(Received via mailing list)
> 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

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

http://www.dedasys.com/
99e0b39c091e10d9c7d4452a34ca52dc?d=identicon&s=25 Simone Carletti (weppos)
on 2013-12-20 12:19
(Received via mailing list)
2013/12/20 David Welton <davidnwelton@gmail.com>

> 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?
>

Si', Puma consente di specificare un numero di worker minimo e massimo.
Che
io sappia, lo stesso non e' possibile con Unicorn.


--
Simone Carletti
Passionate programmer and dive instructor

http://simonecarletti.com/
Twitter: @weppos <https://twitter.com/weppos>
C3d3b41d28306e6d3db4aabcdf3642c1?d=identicon&s=25 Roberto De Ioris (Guest)
on 2013-12-20 13:13
(Received via mailing list)
> 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/tu...
> ).
>
> 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-ra...)
> che  stato anche pubblicato da ruby weekly proprio oggi.



Il tutorial per ruby e' qui:

http://uwsgi-docs.readthedocs.org/en/latest/tutori...

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 :)
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.