Flask and mod_wsgi performance

[Ice Prince]

Hi list,
Believe you are doing well.
I'm configuring a web application which using Apache + mod_wsgi + Flask and i have performance issue now.
My application is very tiny, it just responds some short text only.
My apache MPM is prefork as default, wsgi is configured to run in daemon mode.
Tested by ab -n 10000 -c 200 http:/test/test  i got a very good result as Request per second: 1500#/sec, time per request just 0.6ms.
But i make an actual testing which from test server, i fetch the url http:/test/test with speed is 100 request/second only, my web service become laggy, the response time reach to 3 seconds as my manual monitoring.
After calculation i found the actual requests i can handle only 40 requests/second.
I don't know how to do next, please give some some light. Many thanks.

Regards,
Tuan.

[Graham Dumpleton]

I would really need to see the Apache configuration related to mod_wsgi as well as the Apache prefork MPM settings you have configured.

So start by giving what you think covers that and I will ask for more if you haven't supplied everything.

Also confirm what version of mod_wsgi, Apache and Python you are using.

Graham

[Minh Tuan]

Dear Graham,

- Apache prefork MPM settings: I have not touched it yet, thus it is default:

- mod_wsgi version is 3.4, refer to your guide line here

- Apache version:

app@application:~/public_html/logs$ sudo apachectl -V

Server version: Apache/2.4.9 (Debian)

Server built:   Mar 29 2014 22:29:22

Server's Module Magic Number: 20120211:31

Server loaded:  APR 1.5.1, APR-UTIL 1.5.3

Compiled using: APR 1.5.1-dev, APR-UTIL 1.5.3

Architecture:   64-bit

Server MPM:     prefork

  threaded:     no

    forked:     yes (variable process count)

Server compiled with....

 -D APR_HAS_SENDFILE

 -D APR_HAS_MMAP

 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)

 -D APR_USE_SYSVSEM_SERIALIZE

 -D APR_USE_PTHREAD_SERIALIZE

 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT

 -D APR_HAS_OTHER_CHILD

 -D AP_HAVE_RELIABLE_PIPED_LOGS

 -D DYNAMIC_MODULE_LIMIT=256

 -D HTTPD_ROOT="/etc/apache2"

 -D SUEXEC_BIN="/usr/lib/apache2/suexec"

 -D DEFAULT_PIDLOG="/var/run/apache2.pid"

 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"

 -D DEFAULT_ERRORLOG="logs/error_log"

 -D AP_TYPES_CONFIG_FILE="mime.types"

 -D SERVER_CONFIG_FILE="apache2.

conf"

- Apache configure related mod_wsgi:

app@application:~$ sudo cat /etc/apache2/sites-available/ussd-pull.conf

<VirtualHost *:8080>

 

    # ---- Configure VirtualHost Defaults ----

 

    ServerAdmin loca...@abc.com

 

        DocumentRoot /home/app/public_html/http

 

        <Directory />

                Options FollowSymLinks

                AllowOverride None

                Require all granted

        </Directory>

 

        <Directory /home/app/public_html/http/>

                Options Indexes FollowSymLinks MultiViews

                AllowOverride None

                Require all granted

        </Directory>

 

    # ---- Configure WSGI Listener(s) ----

 

        WSGIDaemonProcess ussd_pull user=www-data group=www-data threads=200

        WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi

 

        <Directory /home/app/public_html/wsgi>

                WSGIProcessGroup ussd_pull

                WSGIApplicationGroup %{GLOBAL}

                Require all granted

        </Directory>

 

    # ---- Configure Logging ----

 

    ErrorLog /home/app/public_html/logs/error.log

    LogLevel warn

    CustomLog /home/app/public_html/logs/access.log combined

</VirtualHost>

- wsgi file:

app@application:~$ sudo cat ~/public_html/wsgi/ussd_pull.wsgi

import sys

sys.path.insert(0,'/home/app/public_html/apps/ussd_pull')

from ussd_pull import app as application

- Python version:

app@application:~$ python

Python 2.7.6 (default, Mar 22 2014, 15:40:47)

[GCC 4.8.2] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>>

So shame that i dont know where MPM parameters are of Apache 2.4 so it should default like 2.2 version:

<IfModule mpm_prefork_module>
    StartServers        5
    MinSpareServers     5
    MaxSpareServers     10
    MaxClients          150
    MaxRequestsPerChild 0
</IfModule>

and i've not installed the packet apache2-dev yet as your suggestions.

Many thanks.
Tuan.

--
You received this message because you are subscribed to a topic in the Google Groups "modwsgi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/modwsgi/rufSwTh6PLI/unsubscribe.
To unsubscribe from this group and all its topics, 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/d/optout.

--
  <====((=o-( ',_,' )-o=))=====>

Bản chất tốt nhưng cuộc đời xô đẩy!

[Graham Dumpleton]

What sort of throughput does your site get and how long is the average response time?

A setting of threads=200 for daemon mode is ill advised and although the way mod_wsgi daemon works it should largely mitigate the problems that are caused by such an over the top value, Python's less than stellar threading model may cause issues.

Also, have you validated that Apache is matching incoming requests properly and routing them into the daemon process? You can check where the request is being handled by doing the tests:

  http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode

  http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used

To be safe and ensure things aren't executing in embedded mode, I would suggest adding WSGIRestrictEmbedded directive to disable embedded mode altogether.

  http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html

  http://blog.dscpl.com.au/2012/10/why-are-you-using-embedded-mode-of.html

BTW, mod_wsgi version 3.4 has a security issue and you should try and upgrade, unless of course this is the patched version of the Debian package for mod_wsgi.

  http://blog.dscpl.com.au/2014/05/security-release-for-modwsgi-version-35.html

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.

[Minh Tuan]

Hi Graham,

Sorry for late reply cause you make me realize that i have to do more study as i'm quite newbie in here.

I read every words in your group, blog, also on stackoverflow that related to my configuration but seem i lack of many concepts thus cannot understand them thoroughly.

Back to your questions, i tried some tests and don't know why getting unstable result (10.8.39.26 is my app server as you well know):

app@application:~$ time curl "http://10.8.39.26:8080/ussd/main" > /dev/null 2&>1

 

real    0m0.025s

user    0m0.000s

sys     0m0.016s

app@application:~$ time curl "http://10.8.39.26:8080/ussd/main" > /dev/null 2&>1

 

real    0m0.251s

user    0m0.008s

sys     0m0.012s

Testing by:
ab -n 1000 -c 200 http://10.8.39.26/ussd/main

I got pretty good result as Time per request: 0.3 ms, Request per second: 3000 (#/sec).

Testing by call Asynchronous requests with speed 100 request/sec, the app become laggy, Apache2 child processes reached to maximum (150), responded time at that moment is 3 seconds. After this test, i divide by time and get the number: ~50 requests/second that my web application can serve.

About parameter as your advice:

mod_wsgi.process_group = 'ussd_pull'

mod_wsgi.application_group = ''

Especially, i don't know where to put WSGIRestrictEmbedded directive. It should be "outside of any
VirtualHost's". If i put it like this:

WSGIRestrictEmbedded On
<VirtualHost *:8080>
...
</VirtualHost>

The whole app is die with error log: Embedded mode of mod_wsgi disabled by runtime configuration: /home/app/public_html/wsgi/ota/wsgi

As my python app is very tiny, it just dig in DB 1 fist time only, to retrieve a short text and dedicates that text in to global variable, then use this variables to respond every sequence requests, i expect my app can server at least 500 request/seconds as i'm in plenty of hardware resource.

I'll upgrade to version 3.5 soon, it should be easy cause someone complied this version for my Debian distribution.

Many thanks and wish you healthy.

Tuan.

[Graham Dumpleton]

The error:

    Embedded mode of mod_wsgi disabled by runtime configuration

is likely indicative of what your problem is.

It says that whatever URL you are asking for is resolving to a directory containing a WSGI script where the name of the directory is:

    /home/app/public_html/wsgi/ota/wsgi

This doesn't match the configuration your showed before for where the application was being delegated to daemon process mode.

You before had:

        WSGIDaemonProcess ussd_pull user=www-data group=www-data threads=200

        WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi

        <Directory /home/app/public_html/wsgi>

                WSGIProcessGroup ussd_pull

                WSGIApplicationGroup %{GLOBAL}

                Require all granted

        </Directory>

The URL you are requesting can't be for that and whatever URL you are using is mapping to a WSGI application which isn't being delegated to a daemon process properly and instead is running in embedded mode.

This is evident because with WSGIRestrictEmbedded that error will only come up if the WSGI application was going to run in embedded mode.

Your performance issue thus is that running Python web applications in embedded mode can be sub optimal, especially when you are completely unrealistic in a benchmark as you are and are overloading the server beyond what would likely be reasonable traffic for your web site. You made it worse by issuing such a short test with only 1000 requests, because all you have gone and measured is the startup delays in loading your web application lazily into each Apache child worker process when it was started on demand to suddenly meet the influx of traffic.

Even if it had been properly delegated to the daemon process group, the configuration of:

     WSGIDaemonProcess ussd_pull user=www-data group=www-data threads=200

is still way over the top on threads.

I would start with using:

    WSGIDaemonProcess ussd_pull processes=3 threads=5

You don't need the user and group options when you want it to run as the Apache user.

Anyway, these are what you should do.

1. Find what part of the Apache configurations being used for the URL you are requesting as it wasn't what you quoted before. You want the WSGIScriptAlias that likely has:

    WSGIScriptAlias /ussd /home/app/public_html/wsgi/ota/wsgi/ussd_pull.wsgi

2. Show what the other WSGI directives are around that point and in particular the context of where the WSGIProcessGroup directive is. RIght now it doesn't appear to be at either VirtualHost scope or in a correctly defined Directory block matching the directory '/home/app/public_html/wsgi/ota/wsgi'.

3. Fix anything and validate that the WSGI application is actually running in daemon mode by following the test:

  http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode

4. Drop the number of threads in the WSGIDaemonProcess that is being used, perhaps starting with processes=3 and threads=5.

5. Keep in mind that running ab on a web server at full speed is a complete unrealistic way of testing a server. Try instead with siege and use a measured rate of traffic such as:

    siege -i -d 10 -c 100 http://10.8.39.26/ussd/main 

For 100 concurrent users even that is over the top as you wouldn't expect users to be issuing requests very 10 seconds.

6. Go watch my PyCon talk:

  http://lanyrd.com/2013/pycon/scdyzk/

It explains the sort of scenario you triggered by the way things are setup and they way you are testing it.

Graham

[Minh Tuan]

Opps, I apology for my terrible mistake, because my error log actually is:
Embedded mode of mod_wsgi disabled by runtime configuration: /home/app/public_html/wsgi/ussd_pull.wsgi

I set already:
 WSGIDaemonProcess ussd_pull processes=3 threads=5

Now, if i have "WSGIRestrictEmbedded On" of top of apache config file, i always get above error message and web responds code 500.

If i remove "WSGIRestrictEmbedded On", the web app will back to normal but apply mode check i got the result:

mod_wsgi.application_group = ''

This is strange as we intent to configure mod_wsgi run in daemon mode.

I think my Alias here still fine:
WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi

So how come the error happen?

Regards,
Tuan.

[Graham Dumpleton]

On 10/06/2014, at 5:15 PM, Minh Tuan <hands...@gmail.com> wrote:

Opps, I apology for my terrible mistake, because my error log actually is:
Embedded mode of mod_wsgi disabled by runtime configuration: /home/app/public_html/wsgi/ussd_pull.wsgi

I set already:
 WSGIDaemonProcess ussd_pull processes=3 threads=5

Now, if i have "WSGIRestrictEmbedded On" of top of apache config file, i always get above error message and web responds code 500.

If i remove "WSGIRestrictEmbedded On", the web app will back to normal but apply mode check i got the result:

mod_wsgi.application_group = ''

You ran the test for which sub interpreter, it that for embedded mode vs daemon mode if you are printing out mod_wsgi.application_group.

You want the one for mod_wsgi.process_group.

Can you check again.

Also indicate whether you have any other VirtualHost definitions which have WSGIScriptAlias directive in it.

You might be falling back to a different VirtualHost due to an incomplete VirtualHost setup and/or use of an IP address to access server.

Graham

[Graham Dumpleton]

On 10/06/2014, at 5:20 PM, Graham Dumpleton <graham.d...@gmail.com> wrote:

On 10/06/2014, at 5:15 PM, Minh Tuan <hands...@gmail.com> wrote:

Opps, I apology for my terrible mistake, because my error log actually is:
Embedded mode of mod_wsgi disabled by runtime configuration: /home/app/public_html/wsgi/ussd_pull.wsgi

I set already:
 WSGIDaemonProcess ussd_pull processes=3 threads=5

Now, if i have "WSGIRestrictEmbedded On" of top of apache config file, i always get above error message and web responds code 500.

If i remove "WSGIRestrictEmbedded On", the web app will back to normal but apply mode check i got the result:

mod_wsgi.application_group = ''

You ran the test for which sub interpreter, it that for embedded mode vs daemon mode if you are printing out mod_wsgi.application_group.

That was meant to say:

You ran the test for which sub interpreter, it is not that for embedded mode vs daemon mode if you are printing out mod_wsgi.application_group.

Stupid auto correct.

[Minh Tuan]

yes, i disappoint you again.

I check again with result:

mod_wsgi.process_group = ''

My apache configure now is:

#WSGIRestrictEmbedded On         -> if uncommend this, i get the error

(Yesterday i added 1 more alias in same Virtualhost and group just for study:
WSGIScriptAlias /ota /home/app/public_html/wsgi/ota.wsgi) now i completely remove it.

Regrads,
Tuan.

Regards,
Tuan.

[Minh Tuan]

I want to correct:
WSGIDaemonProcess ussd_pull processed=3 threads=5

T_T

[Graham Dumpleton]

On 10/06/2014, at 5:39 PM, Minh Tuan <hands...@gmail.com> wrote:

I want to correct:
WSGIDaemonProcess ussd_pull processed=3 threads=5

I hope you meant 'processes' and not 'processed'.

Instead of:

        WSGIDaemonProcess ussd_pull user=www-data group=www-data threads=200

        WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi

 

        <Directory /home/app/public_html/wsgi>

                WSGIProcessGroup ussd_pull

                WSGIApplicationGroup %{GLOBAL}

                Require all granted

        </Directory>

use:

        WSGIDaemonProcess ussd_pull user=www-data group=www-data threads=200

        WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi process-group=ussd_pull application-group=%{GLOBAL}

 
        <Directory /home/app/public_html/wsgi>

                Require all granted

        </Directory>

By specifying the process group and application group there is not way it can end up elsewhere.

If that still doesn't help, make sure you don't have separate files for the virtual host in sites-enabled and sites-available and you are editing the wrong one.

The file in sites-enabled should actually be a symlink to the file in sites-available.

Graham

[Minh Tuan]

Yes, i mean "processes". You are the man.

Everything are in line now, it's always my fault.

I still keep the old format and correct the Directory path is: /home/app/public_html/wsgi

WSGIRestrictEmbedded On
<VirtualHost *:8080>
...

WSGIDaemonProcess ussd_pull processes=3 threads=5

WSGIScriptAlias /ussd /home/app/public_html/wsgi/ussd_pull.wsgi
        <Directory /home/app/public_html/wsgi>     -> some how last time i changed it to /home/app/public_html/http

                WSGIProcessGroup ussd_pull
                WSGIApplicationGroup %{GLOBAL}
                Require all granted
        </Directory>

</VirtualHost>

After correct the path, now i have WSGIRestrictEmbedded On without any error messages and

mod_wsgi.process_group = 'ussd_pull'

I'm going to follow the step 5 and 6 as your above guide line. Many thanks. You are the best, really.

Regard,
Tuan.

[Minh Tuan]

Hi Graham,

I have done the test:

$ sudo siege -i -d1 -c300 http://10.8.39.26:8080/ussd/main
** SIEGE 2.70
** Preparing 300 concurrent users for battle.
The server is now under siege...^C
Lifting the server siege...      done.
Transactions:                2287634 hits
Availability:                 100.00 %
Elapsed time:                3853.32 secs
Data transferred:             342.52 MB
Response time:                  0.01 secs
Transaction rate:             593.68 trans/sec
Throughput:                     0.09 MB/sec
Concurrency:                    3.16
Successful transactions:     2287634
Failed transactions:               0
Longest transaction:            1.16
Shortest transaction:           0.00

But i have to tweak the daemon like below otherwise apache2 will quickly reach the maximum of child processes (my case is 150):

WSGIDaemonProcess ussd_pull processes=2 threads=100

I realize that change number of processes and theads are significant affect to the web performance. 

Now, should i stay here and tune the processes and thead or take a look in apache configuration, MPM...? Cause i don't have any special requirement for my web server.

Just one more basic question after read this article:

https://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Embedded mode mean we use Apache child processes to server requests.

So what is Apache responsibility in Daemon mode? When many requests come, Apache will use only 1 child process to route to process and thread of mod_wsgi?

What happen when number of request bigger than mod_wsgi's processe * thread, Apache will create another child process and we can serve another processe * thread requests more?

Thank you very much.
Tuan.

[Minh Tuan]

I meant Apache here is using prefork MPM. Thank you.

Regards,
Tuan.

[Graham Dumpleton]

It troubles me somewhat when you say 'Cause i don't have any special requirement for my web server. '.

How much traffic do you expect to get to this server?

For a response time of 0.01 seconds, then even presuming your host even had enough grunt and your network enough capacity, that is technically indicative of being able to handle well over 1 million requests per day.

Is your site really going to handle that amount of traffic?

I would suggest it is highly unlikely. In practice you would never usually expect to run that much traffic out of one server. Large web sites running much less than that traffic would have many hosts, because when you factor in databases and access to backend services, then raw speed of the server isn't going to be the bottleneck and the issue is going to be capacity due to response time, which often you can't deal with except by horizontal scaling, ie., more hosts.

It is a common problem I see that people overly obsess with trying to super optimise their web sites on a hello world when in the majority of cases you would never have enough traffic to even warrant such concerns.

I am sorry to say, but you appear to be falling into that trap of having overly optimistic expectations of the amount of traffic you are going to get.

I said for example to use:

     siege -i -d 10 -c 100

You ignored that and used:

    siege -i -d 1 -c 300

Which represents about up to 30 times as much traffic as I suggested you test with. So you were again overloading your server to the maximum.

I will repeat, you do not want to test a web server by overloading it. All that generally does it exacerbate the ability of your system as whole to handle web requests and you get a poor indication of what you server will really do with a more realistic throughput that your application may actually see.

Anyway, do what you think you need, but I think you are going off in the wrong direction.

The one last comment i will say is that there is no point having the total number of daemon mode threads (2*100=200) as you have it, being greater than MaxClients in Apache. This is because MaxClients is not even going to allow you to get 200 concurrent request through to the daemon processes as the Apache child processes are operating as proxies and so are limited to what MaxClients is set to.

Even a one to one relationship between MaxClients and daemon processes*threads is also wrong, as it constricts your ability to get requests into the daemon processes.

The appropriate ratio is a fuzzy figure that really depends on your specific application and the host you are running on, but a 4 to 1 ratio might be a better starting point.

So if MaxClient is 120, then use processes=6 and threads=5 on the daemon processes.

Just stop overloading your server and use more realistic levels of traffic to it to gauge how well it it working.

When you overload and from that get the notion that you need to add yet more processes or configure it a certain way, then more often than not you actually end up slowing things down for the typical case due to a poor configuration.

Graham

[Minh Tuan]

Thanks Graham,

I'll study carefully what you taught me.

Just want to describe my situation for your sympathize. I'm making a web server which will received HTTP 1.1 requests from another system called USSD Gateway of a Mobile Operator. Each time end user press USSD request on their handset (such as *101#), the USSD Gateway will send request to my Web server, grab some short text of content, then display it on end user handset.

The USSD Gateway able to make 400 requests/sec toward my Webserver and i have to respond asap because end user cannot wait in a USSD service. By that, i have to serve millions requests per day usually.

So what i'm trying is make my webserver can respond 400 concurrent requests within (let say) < 0.5 sec.

Appreciate for your whole-hearted and wish you healthy.

Tuan.

[Graham Dumpleton]

For that sort of high volume application you really should not be trying to do it on one server instance purely from the perspective of redundancy in the event of your server going down. So build your system with redundancy in mind and have an architecture which is designed to spread load across multiple servers and you are already on the path of being able to scale out to more servers if the load requires it.

Just please don't ramp up the number of threads in a Python web application with the expectation that it will solve capacity issues as adding more threads usually makes things worse because of how threading works in Python. In mod_wsgi daemon mode you will be protected against completely ridiculous threads setting as it uses a LIFO strategy as to which thread to give a new request, so if you over allocate it never activates the redundant threads, but still better not to do it in the first place.

Graham

[Jason Garber]

Agreeing with Graham that you should balance connections across servers.  I suggest that you consider placing nginx in front and proxying to 2-3 back end servers.

As for modwsgi performance under real world conditions,  we recently had a case where Google Chrome was viewing a video by requesting 1 byte per request.  20,000 requests in less than an hour.  Each request needed authenticated (redis/postgresql) and access checks performed (postgresql) before retuning x-accel-redirect to nginx. 

My point is that while 20,000 per hour is no huge number, it effortlessly handled it with fairly standard apache prefork / modwsgi 6 processes 15 threads config.

I find that letting nginx handle the front end, I can get a lot more done with a lot fewer python threads, plus you are setup to terminate ssl and load balance for free too. 

We allocate a separate port in apache for each app to keep things clear.

Listen 127.0.0.1:15671
NameVirtualHost 127.0.0.1:15671
<VirtualHost 127.0.0.1:15671>
   ....

Then in nginx, we use in the server container the following (approx) config:

Location static-stuff
   root /path/to/app/static

Location /
   proxy_pass 127.0.0.1:15671

Strongly suggest you do that and re-test.

Jason

[Minh Tuan]

Thank you for the solutions. A professional web service should be implemented like that.

I have a whole world to learn and i'm trying. Enjoy the football matches.

Cheers,

Tuan.

[Graham Dumpleton]

One thing I would very much suggest is that you keep an eye out on this mailing list or my twitter account for mention of some blog posts about this whole subject.

I have been doing various tests this weekend using my new magic for capturing and charting metrics out of mod_wsgi to illustrate the sorts of improvements one can get from tuning but also in using a front end.

As an example, from a pretty standard configuration of Apache/mod_wsgi I have managed to go from about 300 requests/sec up to more than 1200 requests/sec. The final arrangement would even handle you specific problem case of slow mobile clients.

I feel I am getting to the point where I can blog about this stuff as a way of bringing some awareness to the new metrics capabilities.

I usually post on my own blog, but for the series of blog posts I have in mind it more than likely will end up on the blog site of the company I work on.

Graham

[Graham Dumpleton]

On 15/06/2014, at 7:06 PM, Graham Dumpleton <graham.d...@gmail.com> wrote:

One thing I would very much suggest is that you keep an eye out on this mailing list or my twitter account for mention of some blog posts about this whole subject.

I have been doing various tests this weekend using my new magic for capturing and charting metrics out of mod_wsgi to illustrate the sorts of improvements one can get from tuning but also in using a front end.

As an example, from a pretty standard configuration of Apache/mod_wsgi I have managed to go from about 300 requests/sec up to more than 1200 requests/sec. The final arrangement would even handle you specific problem case of slow mobile clients.

Whoops. Screwed those numbers up. For my later tests I accidentally started using a different WSGI application to what I started with. Now I can't get nice clean results possibly because family watching Hulu across the same home network, I think. :-(

Anyway, something is getting totally screwed up and will have to do over again. My best results in the end were actually more like 3000 requests/sec, so actually even bigger difference. Starting to question though whether low end tests results also affected by other issues though, although they had been quite consistent for last few days.

[Jason Garber]

I can say we are eager to see these upcoming blog posts as having literally built a business on modwsgi and having fast growing apps - very interested.

Thanks!

[Minh Tuan]

Very interesting. I'll be around. Thank you sir.

Regards,

Tuan.

[Fahim Ansari]

Hi Graham,

I am trying to find your blog update about how you achieved performance increase upto 3000 req/sec. If you can point me to the place where you have written about it, that would be great.

...

[Graham Dumpleton]

To have a web application perform well involves a lot more than just tweaking web server settings.

What have you done so far to identify where in your application the performance bottlenecks are?

More typically the bottleneck is in the use of backend services such as databases. Why do you think it is the web server at this point?

Even if I can find the post, which I am not sure if I ever wrote, I don’t want you thinking it is some magic pill that is going to solve all the issues you have elsewhere in your application stack.

If you want to post your current Apache/mod_wsgi setup I can look at it and comment. A general overview of what your application does and how it is connected to backend services would also help to understand things.

Graham

Visit this group at https://groups.google.com/group/modwsgi.