So can this be a replacement for apache/mod_wsgi? Can I just proxy django requests from nginx straight through to the spawning server?
Jannis Leidel
· 1 year ago
Eric, great article, going to try that out now.
Although I think there is a typo in "spawn -factory=.." which needs to be "spawn --factory=.."
And don't you mean "The next thing to do is go to the directory which holds your **settings.py**.." instead?
Mads Sülau Jørgensen
· 1 year ago
This sounds very very interesting, but for a real test, try bumping the number of cocurrent requests to something fun like 500. A number like that should make your OS grind into a slow and painfull death (assuming you are using mpm_prefork and not running with an external wsgi process group).
Also, you really need to either perform a "warmup" of apache to force it into spawning it's offspring, once the processes are all started in apache (again, assuming you are using mpm_prefork) you should get almost the same speed.
The main benifit of not using os threads is not the speed of which your requests finish, but the scalability!
Oscar
· 1 year ago
With Macports (on leopard) I had to symlink spawn to /opt/local/bin myself, which isn't very hard:
cd /opt/local/bin; sudo ln -s /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/spawn;
Then OS X users can try this out :-)
Graham Dumpleton
· 1 year ago
What was the URL you were requesting against actually doing? For example, Django site home page, or something else?
MacOS X often gives quite divergent results to other platforms for some Python network based applications, but for similar type setup as Apache which comes with Leopard, that is, 100 processes with single thread in each, best I could manage with a hello world application for 'ab -c 20' was about 1250 requests/sec for Spawning and yet for mod_wsgi it was around 4000 requests/sec. Spawning produced improved results when threads were introduced, that is 10 processes with 10 threads each, resulting in 1500 requests/sec, but still quite short of mod_wsgi.
Maybe you can do some more tests using just a hello world WSGI application as that should give a better indication of relative raw performance as it takes database and rendering systems out of the equation.
dobrych
· 1 year ago
Really great news! It much easy to deploy!
donkton
· 1 year ago
Have you tried out yield ... http://yield.sf.net/ ? It has a WSGI interface but the rest is written in C++. They claim they outperform anybody else. Would be interesting to compare...
Al
· 1 year ago
Eric,
For me, your site is loading nice and fast - however the same cannot be said for all of the third party sites you call out to.
Al.
Alexander Solovyov
· 1 year ago
Eric, thanks for the link, it appeared really when I've been interesting in software like Spawning. :)
I have found some time ago thing named fapws2 and two days ago my friend found another thing named cogen. They both are wsgi servers, and I decided to have small test between all servers I know (test is not absolutely comprehensive and was made only for my own needs).
I tried it with a few different thread settings, and with high numbers (>50) Python kept crashing really hard on my Mac (not even an exception, just the plain Python crash).
I didn't do too much testing, but 5 processes / 15 threads performed quite well.
nuggien
· 1 year ago
Maybe it's just me, but my apache/mod_python setup consistently outperforms spawning. "ab -c 20 -n 10000" was my test and apache/mod_python beat spawning in every pairing of processes/threads.
Graham Dumpleton
· 1 year ago
It actually goes beyond warming up of Apache, but I believe you more or less have identified where the results may be a bit suspect.
As far as I can tell with Spawning is that because it knows it is only hosting the one application, it can preload the application when it first starts all the processes. On the other hand Apache/mod_wsgi by default uses lazy loading and the application code is only loaded when the first request hits a process. You would therefore see a delay for initial requests and with large frameworks like Django, that can be noticeable.
This would be compounded by fact that Apache may also dynamically spawn additional processes if number of concurrent requests greater than initial number of processes.
So, I would suspect that these results for Apache/mod_wsgi may be counting application startup cost which makes them misleading.
Graham Dumpleton
· 1 year ago
You can't use as little as 500 requests when doing a benchmark as what you get can be greatly affected by operating system performance in making processes active and any server/application startup costs. The way the referenced benchmarks have been done are therefore probably not a good indicator of relative performance.
For Apache/mod_wsgi the slowest configuration was also chosen and for some of the results for tested systems show all of the requests failing which means the application wasn't even being tested properly.
gotor
· 1 year ago
performance is spawning red holt is the games copy world i tried it with a few different thread setting, and with higt numbers (>250) python kept crashing really hard on my microsoft windows
It feels like quite helpful, but if it can be used on windows platform?
wilk
· 1 year ago
I also did some tests (on debian lenny) and spawning was _a lot_ (3 or 4 times) slower than mod_wsgi....
Alexander Solovyov
· 1 year ago
> You can't use as little as 500 requests when doing a benchmark as what you get can be greatly affected by operating system performance in making processes active and any server/application startup costs.
There was few ab runs for every server setup before doing each control test (and btw there was few runs of ab -n 500), so there is no overhead from system. By the way, I was curious and used to run `ab -c 200 -n 2000` for few of setups (I'm not sure why I've chosen -c 50 -n 500, maybe I need to re-do testing?), and results was almost the same (relatively, of course).
> For Apache/mod_wsgi the slowest configuration was also chosen
Huh... How to speed up? I'm curious to see how mod_wsgi will win. :)
> for some of the results for tested systems show all of the requests failing which means the application wasn't even being tested properly.
Failing? Where? I see 'Failed requests: 0' for all of results...
Andrew Ingram
· 1 year ago
If you set it to use one process it works quite nicely as a replacement for django's built-in test server. (I found having more than one process caused it to have problems consistantly picking up source changes).
Graham Dumpleton
· 1 year ago
In respect of the errors, all I can say is I must have been drinking too much cheap vodka, otherwise I blame Google, as I clicked through to the ab output from Google translation of original Russian article and so Google screwed up formatting.
... more to come, since only 1000 characters allowed per post.
Graham Dumpleton
· 1 year ago
Anyway, I still believe using only 500 requests in a benchmark is not reliable. Personally I try never to use anything less than 10000, at least when trying to gauge raw performance. Using a high number of concurrent requests can also be problematic depending on the web server and how it is configured.
For example with Apache, if the configuration is prefork and the idle number of processes is a lot less than 50 and in between a prior test and a new test the Apache maintenance tasks has kicked in and shutdown any extra processes it may have created for prior test, then it would need to go and start extra process again to satisfy the transient demand being created. Since it is a new process the application has to be loaded again.
... more again
Graham Dumpleton
· 1 year ago
If publishing benchmarks it is important to document full configuration. If this isn't provided then one can't duplicate it nor be sure how it was set up. One also can't rely on one test only, you would need to do it across a range of concurrency values as different servers behave differently for different levels of concurrency.
Doing a test of single concurrency with a hello world application is also important as that gives best indication of underlying performance. Looking at your comparison you are not using a hello world application but some real world application where requests can take up to 2 seconds each. The actual work of the underlying web server in respect of an individual request would be in the order of tens of milliseconds which is a very small percentage of your overall request time. As a result you aren't even testing the underlying web server, you are really testing the application, its rendering system and any database access.
Eric Florenzano
· 1 year ago
Graham,
Simply put: you are way smarter than I am, so I'm going to basically take your word for it that mod_wsgi is faster :)
The page that I tested was the index page of this site, which gets loaded from Memcached. It was already loaded into Apache. The only reason that I can see for Spawning to have been faster in my tests is because it actually has a non-negligable amount of data to respond with, leveraging its nonblocking IO/coroutine reactor.
Like I said, I'm no statistician and I only did a VERY rudimentary test. The main point was not to put down mod_wsgi as I really like it (and have put my money where my mouth is--donating through micropledge), but instead to point out another interesting server that people might not know about.
Graham Dumpleton
· 1 year ago
The point if anything in me responding was trying to understand how the test was conducted. I have no problem if something is truly faster than mod_wsgi, just means I'll try and make mod_wsgi faster if possible, and if not, make it more attractive to people in other ways as an overall solution.
Also, even if one underlying hosting mechanism is faster than other, normally when one loads up a large application, the difference as far as how each performs is usually negligible in the end. This is because the hosting mechanism isn't normally where the bottleneck is. This is why I don't understand why the results you were getting were markedly different and why I was speculating whether it was somehow counting time taken to load application for Apache/mod_wsgi.
Consider dropping over to mod_wsgi list on Google groups, as have thread there with some analysis about Spawning going already which might be of interest.
Teste
· 1 year ago
Teste
Alexander Solovyov
· 1 year ago
You're simply right, especially talking about application. I'm going to repeat my post (maybe in English), using this application: http://my.piranha.org.ua/perftest.tar.bz2
Using this application and nginx + fapws2 I've got 3900 req/s (this is `ab -c 100 -n 10000`).
Using mod_wsgi I've got 3100 req/s with next config:
They both are way better than any Python server (fapws2 is primarily C module). Maybe I shouldn't use daemon mode for getting better speed?
Alexander Solovyov
· 1 year ago
I've got 3500 req/s after disabling daemon mode. But this means that every apache child will get python interpreter inside and that I can host only 1 web site in apache (or I'll get even bigger childs).
Rob van der Linde
· 1 year ago
Although Spawning + Django is working absolutely fine on my desktop PC running Ubuntu, I did notice that CPU usage is upto 100% constantly on both cores, even if the Django project is idle and not serving anything. It doesn't seem to affect my machine performance at all thought, because it took me a while to even realize this.
Chris
· 1 year ago
Just set this up and Munin is showing 4GB of RAM committed...that doesn't sound very good.
web design company
· 1 year ago
Why do they use greenlets instead of Python 2.5 generators?
Test²
· 1 year ago
test²
Валерий Дасаев
· 8 months ago
Я тоже также думал, пока не прочитал пару аналогичных статей по этой же теме.
wholesale jewelry
· 7 months ago
Good site,i like ur blog,i will visit it often,thanks.
ladies golf gloves
· 7 months ago
Thanks for the help; a friend of mine has been trying to figure this out for weeks!
925 silver jewelry
· 7 months ago
Good site,i like ur blog,i will visit it often,thanks.
SC2
· 7 months ago
performance is spawning red holt is the games copy world i tried it with a few different thread setting, and with higt numbers (>250) python kept crashing really hard on my microsoft windows
club penguin
· 6 months ago
I still believe using only 500 requests in a benchmark is not reliable. Personally I try never to use anything less than 10000, at least when trying to gauge raw performance. Using a high number of concurrent requests can also be problematic depending on the web server and how it is configured.
jewelry wholesale
· 6 months ago
jewelry
jiames
· 6 months ago
Thanks for this, we will find more from this.
Online High Schools
· 6 months ago
i will visit it often,thanks.
Accredited High School Diploma
· 6 months ago
Good site,i like ur blog
Online High School Diploma
· 6 months ago
Thanks for the help
custom conservatories
· 6 months ago
"Eventlet" is very easy to use my friend told me that.
Cheap WoW Gold
· 6 months ago
You are so kind, you topic is so meaningful for us.
injectuon molding
· 6 months ago
thanks for your posts, nice!
jewelry
· 6 months ago
jewelry wholesale
jewelry wholesale
· 6 months ago
jewelry wholesale
jewelry
· 6 months ago
wholesale jewelry
hitloop
· 6 months ago
This sounds very interesting, but for a real test, try to reach the number of requests for cocurrent something fun, like 500. Some, like the operating system to grind to a slow and painful death
Online university credit trans
· 6 months ago
It doesn't seem to affect my machine performance at all thought, because it took me a while to even realize this.
Accredited Online university
· 6 months ago
Nice & Great Site.
Writing Legal Document
· 6 months ago
Nice work you have done, I like it.
Lighting Fixtures
· 6 months ago
It is nice and a great work out by you guys.really feel interesting.
sexy Lingerie
· 6 months ago
As the net moves to IPv6 I think this will become more viable and I can see this really taking off. While there are a number of things that need to be worked on. If we start now, maybe by the time edge to edge connectivity is a reality once again, this will be mature enough.
free games
· 6 months ago
It is really interesting.It doesn't seem to affect my machine performance at all thought, because it took me a while to even realize this.Thanks for the post.
Dissertation Advice
· 6 months ago
That's great of u..well done..nice workk
Essay Writing Service
· 6 months ago
Nice post...Gooooood work!!!!!!!!!!thanks for the share..
jordan shoes
· 6 months ago
Nice work you have done, I like it.
jordan shoes
· 6 months ago
wholesale jewelry
ugg boots
· 6 months ago
jewelry wholesale
nike shoes
· 6 months ago
It is nice and a great work out by you guys.really feel interesting
tiffany jewellery
· 6 months ago
That's great of u..well done..nice workk
Fat loss program
· 5 months ago
Well done..nice work done.,.If we start now, maybe by the time edge to edge connectivity is a reality once again, this will be mature enough.
weight loss
· 5 months ago
Good post...thanks for the info given...I still believe using only 500 requests in a benchmark is not reliable. Personally I try never to use anything less than 10000, at least when trying to gauge raw performance.
Carleton
· 5 months ago
Hello. The first step to getting the things you want out of life is this: Decide what you want. I am from Montenegro and too poorly know English, give true I wrote the following sentence: "Fleas primarily are annoying biting pests."
Thank :( Carleton.
Stop Dreaming Start Action
· 5 months ago
accurate, concise, bold! Are you me. thank you and wish a nice day
Rusli Zainal Sang Visioner
· 5 months ago
hello, this is my first time i visit here. I found so many interesting in your blog especially its discussion. keep up the good work.
glasgow cosmetic dentistry
· 5 months ago
Effective way of sharing useful stuff and interesting information.
dissertation
· 5 months ago
I found so many interesting in your blog especially its discussion. keep up the good work.
wholesale jewelry
· 5 months ago
Good website,nice post,thanks alot.
evden eve nakliyat
· 5 months ago
Thanks, at last that has found that wished to read here. By the way, I have drawings on this theme.Evden eve nakliyat , Where it is possible to throw off?
I need a payday loan immediate
· 5 months ago
Kickass stuff..Thanks a lot for putting this out.
biuro podróży oświecim
· 5 months ago
Effective way of sharing useful stuff and interesting information.
Effective way of sharing useful stuff and interesting information.
SEP
· 5 months ago
great share
Kontes
· 5 months ago
nice info
Free Online Yoga
· 5 months ago
Great stuff..Kudos for putting this out.
psycholog online
· 5 months ago
If you're viewing this on my website directly, then you've already used Spawning, as I've switched over this blog to use the new server. Let me know what you think! Has my site slowed to a crawl? Good to see that :)
rusli zainal sang visioner
· 5 months ago
good info for me, very thanks
sare
· 5 months ago
c t j
lingerie wholesale
· 5 months ago
Hope to know more important things regarding design from it.
ed hardy
· 5 months ago
EDHardy2Sale is a famous ed hardy store which sell directly ed hardy clothing, shoes, boots, swim suit and other cheap ed hardy.
tiffany and co
· 5 months ago
It was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader.Thanks again.
staje
· 5 months ago
good title i like it very much
koxp
· 5 months ago
Thanks for the great tutorial.
white wedding
· 5 months ago
Couldn't be any easier to improve my throughput - thanks! I saw about a ~20 gain in my tests.
cameraboy
· 5 months ago
o, yeh, thanks
wakacje
· 5 months ago
Good stuff!
Bilety lotnicze
· 5 months ago
I have no idea what this is about :p.
film izle
· 5 months ago
thanks man
araba resimleri
· 5 months ago
thanks man
film seyret
· 5 months ago
thanks man
youtube
· 5 months ago
thanks man
film seyret
· 5 months ago
thanks man
sohbet
· 5 months ago
that's a great post, thank you!
radyo dinle
· 5 months ago
that's a great post, thank you!
000-076
· 5 months ago
at last it happened, good to hear that
pizzadude2
· 4 months ago
great article!!! i use this to run django apps at the retirement homes my grampa uses.
Peluang Usaha
· 4 months ago
Thanks for sharing,i need more learn about this topic...
anung
· 4 months ago
Great infomation, it's my first time come to your blog and i like your articles
All Comments
Although I think there is a typo in "spawn -factory=.." which needs to be "spawn --factory=.."
And don't you mean "The next thing to do is go to the directory which holds your **settings.py**.." instead?
Also, you really need to either perform a "warmup" of apache to force it into spawning it's offspring, once the processes are all started in apache (again, assuming you are using mpm_prefork) you should get almost the same speed.
The main benifit of not using os threads is not the speed of which your requests finish, but the scalability!
cd /opt/local/bin;
sudo ln -s /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/spawn;
Then OS X users can try this out :-)
MacOS X often gives quite divergent results to other platforms for some Python network based applications, but for similar type setup as Apache which comes with Leopard, that is, 100 processes with single thread in each, best I could manage with a hello world application for 'ab -c 20' was about 1250 requests/sec for Spawning and yet for mod_wsgi it was around 4000 requests/sec. Spawning produced improved results when threads were introduced, that is 10 processes with 10 threads each, resulting in 1500 requests/sec, but still quite short of mod_wsgi.
Maybe you can do some more tests using just a hello world WSGI application as that should give a better indication of relative raw performance as it takes database and rendering systems out of the equation.
For me, your site is loading nice and fast - however the same cannot be said for all of the third party sites you call out to.
Al.
I have found some time ago thing named fapws2 and two days ago my friend found another thing named cogen. They both are wsgi servers, and I decided to have small test between all servers I know (test is not absolutely comprehensive and was made only for my own needs).
So there are some results: http://dumpz.org/1789/
I've written small article about that, but sadly it is in russian: http://piranha.org.ua/blog/2008/07/31/wsgi-serv...
I haven't written anything that couldn't be seen on previous link, but if there are some interest, I can translate it to English.
Could you perhaps describe the setup in a little more detail(maybe post the settingsfile too?), I would really like to duplicate it.
Martin
sudo apt-get install python-setuptools
sudo apt-get install libssl-dev
Regards,
Antonio
Lima-Peru
I tried it with a few different thread settings, and with high numbers (>50) Python kept crashing really hard on my Mac (not even an exception, just the plain Python crash).
I didn't do too much testing, but 5 processes / 15 threads performed quite well.
As far as I can tell with Spawning is that because it knows it is only hosting the one application, it can preload the application when it first starts all the processes. On the other hand Apache/mod_wsgi by default uses lazy loading and the application code is only loaded when the first request hits a process. You would therefore see a delay for initial requests and with large frameworks like Django, that can be noticeable.
This would be compounded by fact that Apache may also dynamically spawn additional processes if number of concurrent requests greater than initial number of processes.
So, I would suspect that these results for Apache/mod_wsgi may be counting application startup cost which makes them misleading.
For Apache/mod_wsgi the slowest configuration was also chosen and for some of the results for tested systems show all of the requests failing which means the application wasn't even being tested properly.
http://pastebin.com/f30eaf404
There was few ab runs for every server setup before doing each control test (and btw there was few runs of ab -n 500), so there is no overhead from system. By the way, I was curious and used to run `ab -c 200 -n 2000` for few of setups (I'm not sure why I've chosen -c 50 -n 500, maybe I need to re-do testing?), and results was almost the same (relatively, of course).
> For Apache/mod_wsgi the slowest configuration was also chosen
Huh... How to speed up? I'm curious to see how mod_wsgi will win. :)
> for some of the results for tested systems show all of the requests failing which means the application wasn't even being tested properly.
Failing? Where? I see 'Failed requests: 0' for all of results...
... more to come, since only 1000 characters allowed per post.
For example with Apache, if the configuration is prefork and the idle number of processes is a lot less than 50 and in between a prior test and a new test the Apache maintenance tasks has kicked in and shutdown any extra processes it may have created for prior test, then it would need to go and start extra process again to satisfy the transient demand being created. Since it is a new process the application has to be loaded again.
... more again
Doing a test of single concurrency with a hello world application is also important as that gives best indication of underlying performance. Looking at your comparison you are not using a hello world application but some real world application where requests can take up to 2 seconds each. The actual work of the underlying web server in respect of an individual request would be in the order of tens of milliseconds which is a very small percentage of your overall request time. As a result you aren't even testing the underlying web server, you are really testing the application, its rendering system and any database access.
Simply put: you are way smarter than I am, so I'm going to basically take your word for it that mod_wsgi is faster :)
The page that I tested was the index page of this site, which gets loaded from Memcached. It was already loaded into Apache. The only reason that I can see for Spawning to have been faster in my tests is because it actually has a non-negligable amount of data to respond with, leveraging its nonblocking IO/coroutine reactor.
Like I said, I'm no statistician and I only did a VERY rudimentary test. The main point was not to put down mod_wsgi as I really like it (and have put my money where my mouth is--donating through micropledge), but instead to point out another interesting server that people might not know about.
Also, even if one underlying hosting mechanism is faster than other, normally when one loads up a large application, the difference as far as how each performs is usually negligible in the end. This is because the hosting mechanism isn't normally where the bottleneck is. This is why I don't understand why the results you were getting were markedly different and why I was speculating whether it was somehow counting time taken to load application for Apache/mod_wsgi.
Consider dropping over to mod_wsgi list on Google groups, as have thread there with some analysis about Spawning going already which might be of interest.
Using this application and nginx + fapws2 I've got 3900 req/s (this is `ab -c 100 -n 10000`).
Using mod_wsgi I've got 3100 req/s with next config:
WSGIDaemonProcess piranha user=piranha group=www-data threads=4 processes=2
They both are way better than any Python server (fapws2 is primarily C module). Maybe I shouldn't use daemon mode for getting better speed?
I am from Montenegro and too poorly know English, give true I wrote the following sentence: "Fleas primarily are annoying biting pests."
Thank :( Carleton.
Jewelry Market
Korean Jewelry
Jewelry Market
Korean Jewelry
その後 → ニチダン生命 → アクサグループライフ生命 → アクサ生命 となり、契約は引き継がれていると思います。
retirement homes my grampa uses.