My understanding was Django is a WSGI application, and as such its role is to process requests handed to it. It isn't the server as such.
It's the role of a WSGI publisher to accept requests and pass them on to an appropriate handler. So, uWSGI, gunicorn, flup and mod_wsgi as the Publishers we most often hear of, and it's generally their place to implement the fork/thread/greenlet model used. On 22 July 2013 02:39, Juan Luis Boya <[email protected]> wrote: > > Juan, technically Django isn't a server at all... >> > > Django is a web application framework whose operation consists on waiting > for HTTP requests from the network (encapsulated with WSGI) and replying > each one of them with a HTTP response. Call it what you want. > > >> whether it's sync, async, multi-threaded, multi-process, or a mix of any >> of them is up to the wsgi publisher used. >> > > This is what I understand with 'asynchronous' and 'synchronous' servers: > > * A synchronous server attends only one client connection at a time for > each worker thread. Concurrency is achieved with operating system > mechanisms like threads and processes. > * An asynchronous server may be attending many client connections at a > time for each worker thread. Concurrency is achieved within the thread > using an application specific dispatcher. In an asynchronous server, there > is only one blocking call accepted, which selects events from all > connections. Typically this call is select(), epoll() or kqueue() depending > on the system. **Other blocking calls must not be used because they would > block the entire server until they return, preventing all available > processing for other connections and thus killing server performance**. > Therefore, asynchronous programming impose additional restrictions to the > programmer, like: > * Do not read or write files yourself, cause read() and write() are > blocking by default. You must pass those operations through the dispatcher. > * All database operations must pass through the dispatcher too. You > can't block the thread until a SQL statement ends its execution. > * All additional HTTP requests (like those to external APIs) must pass > through the dispatcher too in order to not block the server until they are > replied. > and so on... > > There are also mixed approaches, i.e. an asynchronous load balancer which > delivers new connections to synchronous worker threads or processes using > IPC mechanisms. > > Since most (if not all) Django applications rely on blocking operations > like those stated before, trying to make Django an asynchronous web > platform expecting a huge performance improvement is a wrong idea. Putting > that apart, the asynchronous load balancer (which can create and delete > threads/processes depending on the server load) is not a bad idea. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
