Re: [Rails] Should I use passenger in production
> On Jan 13, 2019, at 12:38 PM, fugee ohu wrote: > > What do I need it for besides being able to restart apps Passenger is necessary to translate the incoming http request into a connection to your Rails app. Even I f you are just developing locally, you will run `rails s` in a console, and that will start a server, usually Puma these days, but you could also run Unicorn or even Webrick if you’re feeling nostalgic. By itself, Rails is not going to respond to http. Passenger and Unicorn are both production grade http adapters, they can deal with things like slow clients or excessive traffic. Webrick (to give a ridiculous counter-example) is single-threaded and will just die under anything more than development click testing load. Any of these application servers will want to be fronted by Apache or NGINX to handle static assets and general proxy server duties if you anticipate any sort of real load. My usual production deployment is Apache with the mod_passenger plugin. For really large sites, I will put multiple instances of that stack behind a load balancer, with all instances pointing to the same database server. Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/47CDA22D-139C-4B5F-A78B-6E49922D1232%40wdstudio.com. For more options, visit https://groups.google.com/d/optout.
Re: [Rails] Should I use passenger in production
On Sunday, January 13, 2019 at 4:46:52 PM UTC-5, Walter Lee Davis wrote: > > > > On Jan 13, 2019, at 12:38 PM, fugee ohu > > wrote: > > What do I need it for besides being able to restart apps > > Passenger is necessary to translate the incoming http request into a > connection to your Rails app. > > Even I f you are just developing locally, you will run `rails s` in a > console, and that will start a server, usually Puma these days, but you > could also run Unicorn or even Webrick if you’re feeling nostalgic. > > By itself, Rails is not going to respond to http. > > Passenger and Unicorn are both production grade http adapters, they can > deal with things like slow clients or excessive traffic. Webrick (to give a > ridiculous counter-example) is single-threaded and will just die under > anything more than development click testing load. > > Any of these application servers will want to be fronted by Apache or > NGINX to handle static assets and general proxy server duties if you > anticipate any sort of real load. My usual production deployment is Apache > with the mod_passenger plugin. For really large sites, I will put multiple > instances of that stack behind a load balancer, with all instances pointing > to the same database server. > > Walter > Rails works with nginx without passenger no? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e2b3a2ae-5c8a-4adf-827f-c0a002541731%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Rails] Should I use passenger in production
> On Jan 14, 2019, at 5:35 AM, fugee ohu wrote: > > > > On Sunday, January 13, 2019 at 4:46:52 PM UTC-5, Walter Lee Davis wrote: > > > On Jan 13, 2019, at 12:38 PM, fugee ohu > wrote: > >> What do I need it for besides being able to restart apps >> > Passenger is necessary to translate the incoming http request into a > connection to your Rails app. > > Even I f you are just developing locally, you will run `rails s` in a > console, and that will start a server, usually Puma these days, but you could > also run Unicorn or even Webrick if you’re feeling nostalgic. > > By itself, Rails is not going to respond to http. > > Passenger and Unicorn are both production grade http adapters, they can deal > with things like slow clients or excessive traffic. Webrick (to give a > ridiculous counter-example) is single-threaded and will just die under > anything more than development click testing load. > > Any of these application servers will want to be fronted by Apache or NGINX > to handle static assets and general proxy server duties if you anticipate any > sort of real load. My usual production deployment is Apache with the > mod_passenger plugin. For really large sites, I will put multiple instances > of that stack behind a load balancer, with all instances pointing to the same > database server. > > Walter > > Rails works with nginx without passenger no? Nginx or Apache handle the web connections. Rails is the app. You need some 'glue' between the two. What something like Passenger does is manages the Rails processes and keeps connections with Nginx/Apache efficient and uptime at its most. Phil -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/02825154-1066-4DB7-97D1-CA6C5CC1060B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Rails] Should I use passenger in production
On Monday, January 14, 2019 at 10:32:23 AM UTC-5, Phil wrote: > > > > On Jan 14, 2019, at 5:35 AM, fugee ohu > > wrote: > > > > On Sunday, January 13, 2019 at 4:46:52 PM UTC-5, Walter Lee Davis wrote: >> >> >> >> On Jan 13, 2019, at 12:38 PM, fugee ohu wrote: >> >> What do I need it for besides being able to restart apps >> >> Passenger is necessary to translate the incoming http request into a >> connection to your Rails app. >> >> Even I f you are just developing locally, you will run `rails s` in a >> console, and that will start a server, usually Puma these days, but you >> could also run Unicorn or even Webrick if you’re feeling nostalgic. >> >> By itself, Rails is not going to respond to http. >> >> Passenger and Unicorn are both production grade http adapters, they can >> deal with things like slow clients or excessive traffic. Webrick (to give a >> ridiculous counter-example) is single-threaded and will just die under >> anything more than development click testing load. >> >> Any of these application servers will want to be fronted by Apache or >> NGINX to handle static assets and general proxy server duties if you >> anticipate any sort of real load. My usual production deployment is Apache >> with the mod_passenger plugin. For really large sites, I will put multiple >> instances of that stack behind a load balancer, with all instances pointing >> to the same database server. >> >> Walter >> > > Rails works with nginx without passenger no? > > > Nginx or Apache handle the web connections. Rails is the app. You need > some 'glue' between the two. What something like Passenger does is manages > the Rails processes and keeps connections with Nginx/Apache efficient and > uptime at its most. > > > Phil > > I thought rails and nginx will work together without Passenger -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/49e9ccc5-3e10-4813-8b70-b5d08d5b3ce9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Rails] Should I use passenger in production
> On Jan 14, 2019, at 1:42 PM, fugee ohu wrote: > > > >> On Monday, January 14, 2019 at 10:32:23 AM UTC-5, Phil wrote: >> >> >>> On Jan 14, 2019, at 5:35 AM, fugee ohu wrote: >>> >>> >>> On Sunday, January 13, 2019 at 4:46:52 PM UTC-5, Walter Lee Davis wrote: > On Jan 13, 2019, at 12:38 PM, fugee ohu wrote: > > What do I need it for besides being able to restart apps > Passenger is necessary to translate the incoming http request into a connection to your Rails app. Even I f you are just developing locally, you will run `rails s` in a console, and that will start a server, usually Puma these days, but you could also run Unicorn or even Webrick if you’re feeling nostalgic. By itself, Rails is not going to respond to http. Passenger and Unicorn are both production grade http adapters, they can deal with things like slow clients or excessive traffic. Webrick (to give a ridiculous counter-example) is single-threaded and will just die under anything more than development click testing load. Any of these application servers will want to be fronted by Apache or NGINX to handle static assets and general proxy server duties if you anticipate any sort of real load. My usual production deployment is Apache with the mod_passenger plugin. For really large sites, I will put multiple instances of that stack behind a load balancer, with all instances pointing to the same database server. Walter >>> >>> Rails works with nginx without passenger no? >> >> Nginx or Apache handle the web connections. Rails is the app. You need >> some 'glue' between the two. What something like Passenger does is manages >> the Rails processes and keeps connections with Nginx/Apache efficient and >> uptime at its most. >> >> >> Phil >> > > I thought rails and nginx will work together without Passenger > > Why would you think that? Can you point to some documentation of that? You could certainly shell into your server, start Rails from the console with `rails s -d -p 2020 production` and then set up a proxy in NGINX that directs ports 443 and 80 to 2020. That would probably work, for certain definitions of “work”. It would be slow, wouldn’t scale to traffic, wouldn’t deal with slow clients, etc. Nobody smart does this, before you ask for more details. Just use an application server like Passenger. Really. It doesn’t have to be Passenger, there are others, but you have to use one of them. Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/FD91FA21-835E-4932-8DC9-C9CD5EE5C5E0%40wdstudio.com. For more options, visit https://groups.google.com/d/optout.
Re: [Rails] Should I use passenger in production
> On Jan 14, 2019, at 12:42 PM, fugee ohu wrote: > > > > On Monday, January 14, 2019 at 10:32:23 AM UTC-5, Phil wrote: > > >> On Jan 14, 2019, at 5:35 AM, fugee ohu > wrote: >> >> >> >> On Sunday, January 13, 2019 at 4:46:52 PM UTC-5, Walter Lee Davis wrote: >> >> >> On Jan 13, 2019, at 12:38 PM, fugee ohu > wrote: >> >>> What do I need it for besides being able to restart apps >>> >> Passenger is necessary to translate the incoming http request into a >> connection to your Rails app. >> >> Even I f you are just developing locally, you will run `rails s` in a >> console, and that will start a server, usually Puma these days, but you >> could also run Unicorn or even Webrick if you’re feeling nostalgic. >> >> By itself, Rails is not going to respond to http. >> >> Passenger and Unicorn are both production grade http adapters, they can deal >> with things like slow clients or excessive traffic. Webrick (to give a >> ridiculous counter-example) is single-threaded and will just die under >> anything more than development click testing load. >> >> Any of these application servers will want to be fronted by Apache or NGINX >> to handle static assets and general proxy server duties if you anticipate >> any sort of real load. My usual production deployment is Apache with the >> mod_passenger plugin. For really large sites, I will put multiple instances >> of that stack behind a load balancer, with all instances pointing to the >> same database server. >> >> Walter >> >> Rails works with nginx without passenger no? > > Nginx or Apache handle the web connections. Rails is the app. You need some > 'glue' between the two. What something like Passenger does is manages the > Rails processes and keeps connections with Nginx/Apache efficient and uptime > at its most. > > > Phil > > > I thought rails and nginx will work together without Passenger > You need something to glue Rails and the web service together. (I'd advise against FastCGI, like we did in the Olde Days™ ;') If you are going to use puma (or something) and proxy through nginx or apache, I don't know what the point is(?). Every deployment can be a bit (or a lot) different in needs, though. Passenger is just a plug-in for nginx/apache to manage your rails app pool. I don't understand your attachment to nginx and your aversion to passenger? (I'm not a passenger shrill, just confused what your constraints are.) I think Walter did a good job explaining things, btw. Good luck! Phil -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/DEC86A5E-CB8D-4E8D-B562-EA0078F430B6%40gmail.com. For more options, visit https://groups.google.com/d/optout.
