On Jul 8, 4:16 am, Ramdas S <ram...@gmail.com> wrote:
> Hi,
>
> We have a web server where we are hosting around 12-15 django web sites most
> of them attracting modest traffic, except a couple which sees spiikes on and
> off. Together we estimate just about 20,000-40,000 page views.
>
> However we are expecting major spikes in traffic in the coming days and are
> moving to a 8 GB RAM quad core server.
>
> We are also trying to optimize the django apps.
>
> Presently we have memcached mod-python instances running. The database
> server is also running on the same server.
>
> What all should we do to ensure that such a server can handle huge volumes
> of traffic?
Don't use mod_python for a start. See:
http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html
Same issue can occur with mod_wsgi embedded mode, so use of mod_wsgi
daemon mode is best to avoid the problem.
> We are presently optimizing every site with whatever we can according to
> what Yahoo! recommends for improving site performance. But that's only at
> the client side.
>
> I am told that mod wsgi is more efficient than mod-python. How efficient? Do
> your recommend moving all sites to modwsgi?
Use of daemon mode certainly gives more predictable performance and
memory usage. Although memory usage and performance with mod_wsgi is a
bit better, in the context of a large fat Python web application using
a database, you wouldn't normally see any significant difference to
other similarly configured WSGI hosting mechanisms. This is because
all the overhead and bottlenecks are going to be in your application
and the database, not the server level.
> What about nginx? Is it worth exploring Nginx as alternative to Apache?
Using nginx as a front end proxy in front of Apache/mod_wsgi in order
to handle static media, deal with slow clients and avoid keep alive
resource issues in Apache is certainly a good idea.
Using fastcgi with nginx is reasonable but may just make management
harder as likely need a separate supervisor system to keep all the
Django fastcgi processes running, something which Apache/mod_wsgi
gives you for free.
The mod_wsgi module for nginx should possibly be avoided as it has
potential issues with blocking because of standard WSGI not being
suited for hosting on top of an event driven system. See:
http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html
> Is there anything else we need to look at?
Caching, caching and caching. Even if you are doing a measure of
caching, look at what other caching you can do. This also need not be
caching within the application, but could be front end caching
proxies.
As an example, for a lot of sites the bulk of traffic will be to the
front page of the site. If rather than going to the database for all
requests for that page you use cached data, you will speed up serving
up that heavily trafficked page. Better still, avoid requests even
going to the application for that page in the majority of cases by
having a caching proxy cache it with an expiry time of a few minutes.
Doing just this can in some cases dramatically reduce traffic actually
hitting your application.
Finally, if using mod_wsgi daemon mode, ensure you delegate different
Django instances to different process groups. This way you can control
the number of processes for each instance and for less trafficked
sites give minimum number of processes/threads. For more heavily
trafficked sites give more processes. This way you don't incur as much
memory usage for the smaller trafficked sites.
Graham
> Thanks for the advices...
>
> Also what is the realistic number of page views/ simultaneous connections
> that a Nehalem quad core Intel i-7 920, 8 GB RAM machine can handle? Any
> statistical experiences.
>
> Thanks
>
> --
> Ramdas S
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
