Script timed out before returning headers

1,364 views
Skip to first unread message

Fini Decima

unread,
Sep 16, 2013, 10:29:47 PM9/16/13
to mod...@googlegroups.com

I have an installation of MediaCore, a media serving application built atop the Django framework I have i running on Apache2 using mod_wsgi.

Sometimes it works, other times, it also works, but it takes forever to load, and I get some error messages in Apache's error file like these: =

<code>

[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[error] [client IP-ADDR] Script timed out before returning headers: mediacore.wsgi, referer: http://IP-ADDR/
[info] [client IP-ADDR] (70007)The timeout specified has expired: core_output_filter: writing data to the network
[info] [client IP-ADDR] (70007)The timeout specified has expired: core_output_filter: writing data to the network
[error] [client IP-ADDR] mod_wsgi (pid=25066): Exception occurred processing WSGI script '/var/www/mediacore.wsgi'.
[error] [client IP-ADDR] IOError: failed to write data
[info] [client IP-ADDR] (32)Broken pipe: core_output_filter: writing data to the network
[info] [client IP-ADDR] (32)Broken pipe: core_output_filter: writing data to the network

</code>

Even as I'm writing this, a video I clicked several minutes ago is still trying to load.

Here's my media.wsgi file

<code>

activate_this = '/var/www/virtualECK/bin/activate_this.py'

execfile(activate_this, dict(__file__=activate_this))


deployment_config = '/var/www/deployment.ini'

temp_dir = '/var/www/data/tmp'


# NOTE: Before running MediaCore, you will need to update the two paths

# above to point to the appropriate locations for your installation.


import os

os.environ['TMPDIR'] = temp_dir


if __name__.startswith('_mod_wsgi_'):

    # Set up logging under mod_wsgi

    from paste.script.util.logging_config import fileConfig

    fileConfig(deployment_config)

    # Load the app!

    from paste.deploy import loadapp

    application = loadapp('config:'+deployment_config)

</code>


And here's my VirtualHost configuration:


<code>

<VirtualHost *:80>

        ServerAdmin *


        DocumentRoot /var/www

        # For best performance the number of processes should equal the number of CPU

        # cores (but please note that each process may use about 500 MB RAM).

        WSGIDaemonProcess eckmedia user=www-data group=www-data \

        processes=1 \

        threads=1 \

        display-name=%{GROUP} \

        python-path=/var/www/virtualECK/lib/python2.7/site-packages \

        python-eggs=/var/www/data/python-egg-cache

        WSGIProcessGroup eckmedia

        # Intercept all requests to /* and pass them to mediacore.wsgi

        WSGIScriptAlias / /var/www/mediacore.wsgi process-group=eckmedia application-group=%{GLOBAL}


        <Directory />

                Options FollowSymLinks

                AllowOverride None

        </Directory>

        <Directory /var/www/>

                Options Indexes FollowSymLinks MultiViews

                AllowOverride None

                Order allow,deny

                allow from all

        </Directory>


        # Make all the static content accessible.  

        <Directory /var/www/eckmedia/mediacore/public/*>

                Order allow,deny

                Allow from all

                Options -Indexes

                WSGIScriptReloading On

        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        LogLevel info

        CustomLog ${APACHE_LOG_DIR}/access.log combined


</code>


And in Apache2.conf, I have:

<code>

# prefork MPM

<IfModule mpm_prefork_module>

    StartServers          7

    MinSpareServers       5

    MaxSpareServers      10

    MaxClients          150

    MaxRequestsPerChild   0

</IfModule>

</code>

Any ideas what could be causing the errors?

TIA

Fini Decima

unread,
Sep 17, 2013, 7:13:49 PM9/17/13
to mod...@googlegroups.com
What I've observed is that after every 3 or 4 page loads, the sites takes a long time to load.  And after it loads, the process repeats itself.

Graham Dumpleton

unread,
Sep 17, 2013, 8:47:00 PM9/17/13
to mod...@googlegroups.com
You have a very poorly setup configuration. Your WSGI application can only handle one request at a time. If one request takes a long time to run, it will block out everything else and if it blocks for too long, it will timeout.

I would thus very much suggest not using processes=1 and threads=1 for daemon mode.

You could also be suffering issues due to third party C extension modules which will not working in sub interpreters and which block and cause process to hang, thus invoking mod_wsgi deadlock timeout.

I would suggest using:

WSGIApplicationGroup %{GLOBAL}

Also go watch:


which explains various stuff about Apache configuration for mod_wsgi.

Graham

--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+u...@googlegroups.com.
To post to this group, send email to mod...@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/groups/opt_out.

Graham Dumpleton

unread,
Sep 17, 2013, 8:51:18 PM9/17/13
to mod...@googlegroups.com
On 18/09/2013, at 10:47 AM, Graham Dumpleton <graham.d...@gmail.com> wrote:

You have a very poorly setup configuration. Your WSGI application can only handle one request at a time. If one request takes a long time to run, it will block out everything else and if it blocks for too long, it will timeout.

I would thus very much suggest not using processes=1 and threads=1 for daemon mode.

You could also be suffering issues due to third party C extension modules which will not working in sub interpreters and which block and cause process to hang, thus invoking mod_wsgi deadlock timeout.

I would suggest using:

WSGIApplicationGroup %{GLOBAL}

Oh, you already use:

application-group=%{GLOBAL}

to WSGIScriptAlias, which does the same things.

Because you are using process-group option to WSGIScriptAlias, then WSGIProcessGroup is actually redundant.

Graham

Fini Decima

unread,
Sep 17, 2013, 9:06:17 PM9/17/13
to mod...@googlegroups.com
Thanks for the response.

What, then, are the optimal settings for "processes=" and "threads="?

Graham Dumpleton

unread,
Sep 17, 2013, 9:08:04 PM9/17/13
to mod...@googlegroups.com
That depends on your web application and what it does.

Watch that talk I referenced, plus another talk I did the prior year:


Graham

Fini Decima

unread,
Sep 25, 2013, 1:42:12 PM9/25/13
to mod...@googlegroups.com
I watch those presentation previously. Very well done.

I managed to solve the issue by changing "file_serve_method" in my deployment.ini to utilize xsendfile, then configured XSendfile in Apache. 

I might still need to mess with MPM, but for now it works.

Thanks
Reply all
Reply to author
Forward
0 new messages