I’m getting ready to push a web app that’s partially implemented with the Camping framework, but mostly hacked together, into production.
I’ll probably put it behind nginx, but the only web development I’ve done that’s gone to production in the past has been Apache with PHP and node.js – I don’t really understand exactly what is happening in memory and with processes when you push a Ruby web app to production.
Camping provides a development server that runs on port 3301 by default. It’s occurred to me that with Nginx, I could just reverse proxy to the process running on that port for any requests to the camping app. Is this an awful idea?
If I do it some other way – with WSGI, or reverse proxy to Unicorn / Thin – what exactly happens with concurrency? Will I be spawning a new Ruby process for every request, where all the setup for my webapp and all the class definition and generation and everything else has to be done from scratch? Is there some wizardry at some level of the stack where my application state is cached?
Sorry for the chaos of my question – I really have no idea of how this works when it’s somewhere in between the absolutes of the way Apache does PHP and the way a node.js HTTP server has a single process (usually) that just listens on a port.
Running your app under unicorn or thin is completely normal so I wouldn’t be worried about that. I am not sure what you mean about concurrency?
Unicorn/thin will load up your configuration/classes etc only once. Unicorn will fork a process for each request but that does not reload your app.