# Passenger su heroku **URL:** \ **Category:** IT\ **Created:** [December 20, 2013, 9:36am UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169 "2013-12-20T09:36:52Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [December 20, 2013, 9:36am UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/1 "2013-12-20T09:36:52Z")
Ho trovato oggi questo articolo: > **[How to get More Bang for your Heroku Buck While Making Your Rails Site Super...](https://stormconsultancy.co.uk/blog/techtips/how-to-get-more-bang-for-your-heroku-buck-while-making-your-rails-site-super-snappy-redux/)** > > I first wrote about how to get the most bang for your Heroku buck a year ago. Since then a few things have changed and we’ve learnt even more about how to deliver great performance from our Heroku hosted sites. Some of the advice remains the same,... parla di come usare Passenger su Heroku, l’ho trovato molto interessante. Qualcuno lo usa? ---
**Author:** ![fregini](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a88e4f/32.png) [@fregini](https://www.ruby-forum.com/u/fregini)\ **Post date:** [December 20, 2013, 12:04pm UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/2 "2013-12-20T12:04:06Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > [http://lists.ruby-it.org/mailman/listinfo/ml](http://lists.ruby-it.org/mailman/listinfo/ml) – Simone C. Passionate programmer and dive instructor > **[Simone Carletti — Underwater programmer](https://simonecarletti.com/)** > > Simone Carletti is a programmer with an insane passion for code quality. Twitter: @weppos [https://twitter.com/weppos](https://twitter.com/weppos) ---
**Author:** ![fregini](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a88e4f/32.png) [@fregini](https://www.ruby-forum.com/u/fregini)\ **Post date:** [December 20, 2013, 12:12pm UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/3 "2013-12-20T12:12:52Z")
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](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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![fregini](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a88e4f/32.png) [@fregini](https://www.ruby-forum.com/u/fregini)\ **Post date:** [December 20, 2013, 12:19pm UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/4 "2013-12-20T12:19:18Z")
2013/12/20 David W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > 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 C. Passionate programmer and dive instructor > **[Simone Carletti — Underwater programmer](https://simonecarletti.com/)** > > Simone Carletti is a programmer with an insane passion for code quality. Twitter: @weppos [https://twitter.com/weppos](https://twitter.com/weppos) ---
**Author:** ![fregini](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a88e4f/32.png) [@fregini](https://www.ruby-forum.com/u/fregini)\ **Post date:** [December 20, 2013, 12:12pm UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/5 "2013-12-20T12:12:52Z")
> 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.welton.it/davidw/) [http://www.dedasys.com/](http://www.dedasys.com/) ---
**Author:** ![fregini](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/a88e4f/32.png) [@fregini](https://www.ruby-forum.com/u/fregini)\ **Post date:** [December 20, 2013, 1:13pm UTC](https://www.ruby-forum.com/t/passenger-su-heroku/238169/6 "2013-12-20T13:13:39Z")
> 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](https://github.com/unbit/uwsgi-docs/blob/master/tutorials/heroku_python.rst) > ). > > 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](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](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 🙂