what happens if mod_wsgi cannot accept additional requests?

[JE]

Hi!

I'm pretty new to mod_wsgi. I have read through the most of mod_wsgi
documentation. I found answers to many of my questions, however there
is one topic I cannot find any information on. :/
Let's assume I have a apache server with mod_wsgi in daemon mode. All
mod_wsgi processes and their threads process already a request. I
assume, that mod_wsgi cannot accept another request in this situation.
But what happens if another requests comes from apache now? Does
apache wait for mod_wsgi? If so where can I define the timeout ?

Thanks in advance !

Best regards,
Jan-Eric

[Graham Dumpleton]

They queue up, albeit will eventually fail.

New connections are accepted on a socket which has had listen() call done on it:

http://www.opengroup.org/onlinepubs/009695399/functions/listen.html

The queue back log is set by mod_wsgi to be:

if (listen(sockfd, WSGI_LISTEN_BACKLOG) < 0) {
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(errno), wsgi_server,
"mod_wsgi (pid=%d): Couldn't listen on unix domain "
"socket.", getpid());
return -1;
}

Where:

#ifndef WSGI_LISTEN_BACKLOG
#define WSGI_LISTEN_BACKLOG 100
#endif

Thus up to 100 internal connection requests can queue up.

If that limit is exceeded, then it will at that point fail and a retry
mechanism within mod_wsgi will kick in:

if (connect(daemon->fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
if (errno == ECONNREFUSED && retries < WSGI_CONNECT_ATTEMPTS) {
ap_log_rerror(APLOG_MARK, WSGI_LOG_ERR(errno), r,
"mod_wsgi (pid=%d): Connection attempt #%d to "
"WSGI daemon process '%s' on '%s' failed, "
"sleeping before retrying again.", getpid(),
retries, daemon->name, daemon->socket);

close(daemon->fd);

You will start to see those connect attempt failure messages.

If that goes on for a time, you will then have:

ap_log_rerror(APLOG_MARK, WSGI_LOG_ERR(errno), r,
"mod_wsgi (pid=%d): Unable to connect to "
"WSGI daemon process '%s' on '%s' after "
"multiple attempts.", getpid(), daemon->name,
daemon->socket);

close(daemon->fd);

return HTTP_SERVICE_UNAVAILABLE;

At that point, HTTP client will send a 503 error message indicating
service unavailable.

So, it will not die straight away.

Graham

[JE]

Thanks a lot for the detailed explanation !

On Nov 26, 5:45 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

[JE]

Hi!

I thought a little bit about your answer.

On Nov 26, 5:45 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
>

> Thus up to 100 internal connection requests can queue up.

[...]

>
> If that limit is exceeded, then it will at that point fail and a retry
> mechanism within mod_wsgi will kick in:

Let's say I configure mod_wsgi daemon mode to accept at the most 1
connection at a time (processes = 1, threads=1).
That means that in a high traffic scenario - that I actually need to
configure
Apache's max_clients to 1+100+X
where X is number of clients that request static resources.
Do I also need to factor the connections in that are retrying to
connect to mod_wsgi? These are trying for about 30 seconds to connect,
right ?
I'm not sure how I should do it.
My goal is to configure mod_wsgi in such a way, that it should not eat
up all available connections defined by max_clients, eventhough it
cannot process them.
This would stop Apache from handling requests for static resources.

Thank you in advance !

Best regards,
Jan-Eric

[Graham Dumpleton]

If you are that paranoid about static resources not being able to be
handled, put a nginx server in front of Apache for handling static
media and have nginx proxy only dynamic web application requests
through to Apache/mod_wsgi.

In other words, don't try and make one tool do everything as static
file handling and dynamic web applications generally have different
requirements. Apache is not the best at static file serving and you
are much better off using nginx for that.

Graham

[JE]

> In other words, don't try and make one tool do everything as static
> file handling and dynamic web applications generally have different
> requirements. Apache is not the best at static file serving and you
> are much better off using nginx for that.

Thanks for the tip !