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 <ntr...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
