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.
On Sunday, June 15, 2014 at 5:11:26 AM UTC-7, Graham Dumpleton wrote: > > > On 15/06/2014, at 7:06 PM, Graham Dumpleton <[email protected] > <javascript:>> 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. > > 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 > > On 15/06/2014, at 2:32 AM, Minh Tuan <[email protected] <javascript:>> > wrote: > > 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. > > > > On Wed, Jun 11, 2014 at 9:26 PM, Jason Garber <[email protected] > <javascript:>> wrote: > > 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 > On Jun 11, 2014 3:17 AM, "Minh Tuan" <[email protected] <javascript:>> > wrote: > > 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. > > > On Wed, Jun 11, 2014 at 1:39 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > 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 > > On 11/06/2014, at 2:37 PM, Minh Tuan <[email protected] <javascript:>> > wrote: > > 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. > > > > > > > On Tue, Jun 10, 2014 at 3:15 PM, Minh Tuan <[email protected] > <javascript:>> wrote: > > 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. > > > > On Tue, Jun 10, 2014 at 2:46 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > > On 10/06/2014, at 5:39 PM, Minh Tuan <[email protected] <javascript:>> > 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 > > T_T > > > On Tue, Jun 10, 2014 at 2:37 PM, Minh Tuan <[email protected] > <javascript:>> wrote: > > 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 > > <VirtualHost *:8080> > > > # ---- Configure VirtualHost Defaults ---- > > > ServerAdmin [email protected] <javascript:> > > > 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> > > (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. > > > > On Tue, Jun 10, 2014 at 2:24 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > > On 10/06/2014, at 5:20 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > > > On 10/06/2014, at 5:15 PM, Minh Tuan <[email protected] <javascript:>> > 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. > > 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 > > 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. > > > On Tue, Jun 10, 2014 at 1:10 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > 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 > <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 > > > > On 10/06/2014, at 3:45 PM, Minh Tuan <[email protected] <javascript:>> > wrote: > > 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 > <http://localhost: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 > <http://localhost: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 > <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. > > > > On Mon, Jun 2, 2014 at 6:13 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > 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 > > On 02/06/2014, at 9:04 PM, Minh Tuan <[email protected] <javascript:>> > wrote: > > 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 > <https://groups.google.com/forum/#!topic/modwsgi/bCEGfcXPQFE> > - 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 [email protected] <javascript:> <javascript:> > > > 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. > > > > On Mon, Jun 2, 2014 at 5:27 PM, Graham Dumpleton <[email protected] > <javascript:>> wrote: > > > On 02/06/2014, at 8:18 PM, Ice Prince <[email protected] <javascript:>> > wrote: > > > 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. > > 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 > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > -- > 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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > > > > -- > <====((=o-( ',_,' )-o=))=====> > > Bản chất tốt nhưng cuộc đời xô đẩy! > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > > > > -- > <====((=o-( ',_,' )-o=))=====> > > Bản chất tốt nhưng cuộc đời xô đẩy! > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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 > [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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! > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "modwsgi" group. > To unsubscribe from this topic, visit > > ... -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
