Question

I am developing an application with the bottlepy framework. I am using the standard library WSGIRefServer() to run a development server. It is a single threaded server.

Now when going into production, I will want to move to a multi-threaded production server, and there are many choices. Let’s say I choose CherryPy.

Now, in my code, I am initializing a single wsgi application. Other than that, I am also initializing other things…

• Memcached connection
• Mako templates
• MongoDB connection

Since standard library wsgiref is a single threaded server, and I am creating only a single wsgi app (wsgi callable), everything works just fine.

What I want to know is that when I move to the multi-threaded server, how will my wsgi app, initialization code, connections to different server, etc. behave.

• Will a multi-threaded server create a separate instance of wsgi app for every thread. And will a new thread be spawned for each new request (which then means a new wsgi app for each request)?

• Will my connections to memcached, mongoDB, etc, be shared across threads or not. What else will be shared between threads

• Please explain the request-response cycle for a threaded server

Answer 1

In general your application is using wsgi compliant framework and you shouldn’t be afraid of multi-threaded / single-threaded server side. It’s meant to work transparent and has to react same way despite of what kind of server is it, as long as it is wsgi compliant.

Every code block before bottle.run() will be run only once. As so, every connection (database, memcached) will be instantiated only once and shared.

When you call bottle.run() bottlepy starts wsgi server for you. Every request to that server fires some wsgi callable inside bottlepy framework. You are not really interested if it is single or multi -threaded environment, as long as you don’t do something strange.

For strange i mean for instance synchronizing something through global variables. (Exception here is global request object for which bottlepy ensures that it contains proper request in proper context).

And in response to first question on the list: request may be computed in newly spawned thread or thread from the pool of threads (CherryPy is thread-pooled)