I don't have any experience with large installations like this, but
here's a few strategies that could mitigate the need for a
large pool of servers:
** keep the processing that actually occurs in WebKit to a minimum by
serving all static requests directly from Apache / Squid. Only serve
dynamic content from WebKit.
** follow the Apache tuning guidelines
(http://httpd.apache.org/docs/misc/perf-tuning.html)
** use mod_webkit
** if you have a smp server(s), WebKit might scale better if you run
one WebKit process per processor to overcome Python's global
interpreter lock. This will require multiple ports and multiple
mod_webkit entries in your httpd.conf file. You'll need extra RAM to
do this.
** Use mod_rewrite to do relative path calculations instead of doing
them in Python code. e.g. if you have site global directories for
your stylesheets, images, etc. that you need to access from multiple
subdirectories of the site, do something like this:
<VirtualHost *>
ServerName http://www.calrudd.com
ServerAlias calrudd.com
DocumentRoot "/var/www/www.calrudd.com/public_html"
<Location /WK>
WKServer localhost 8086
SetHandler webkit-handler
</Location>
RewriteEngine on
RewriteRule .*/GlobalImages/(.*)$
/GlobalImages/$1 [L,PT]
RewriteRule .*/spacer.gif$
/GlobalImages/spacer.gif [L, PT]
RewriteRule .*/GlobalStylesheets/(.*)$
/GlobalStylesheets/$1 [L, PT]
RewriteRule .*/GlobalJavascript/(.*)$
/GlobalJavascript/$1 [L, PT]
RewriteRule .*/ImageStore/(.*)$
/ImageStore/$1 [PT]
</VirtualHost>
This much easier and way more efficient than calculating these
relative paths in your Servlet code. It allows you to do this:
<img src="GlobalImages/xx.jpg" width="XX" height="XX" />
rather than this:
<img src="${pathToRoot}GlobalImage/xx.jpg" width="XX" height="XX" />
** use aggressive caching wherever possible:
- in your app code
- in your db access
- in your html generation
** use URIs that can be cached outside of WebKit (using Squid or
something like that) -- no query strings wherever possible
** design your db schema and queries well
** design your application well
** keep the Python performance tips in mind while developing
(http://manatee.mojam.com/~skip/python/fastpython.html)
Some helpful strategies are
1) use shortcut namebinding like this:
def __init__(self):
self._lock = lock = Lock()
self._lock_acquire = lock.acquire
self._lock_release = lock.release
def doSomething(self):
self._lock_acquire()
...
self._lock_release()
2) always convert globals to locals by using default args:
def doSomething(self, arg1, arg2,
currTime=time.time):
...
# do something with currTime()
** use apache-bench and Steve Purcell's HTTPSession.py to profile
your site and identify hotspots.
** you'll probably identify a small number of URIs that eat up most
of your processing time. If you really need to (and I doubt you
will), you can achieve significant performance gains by hardwiring
each of them to a particular WebKit port / process and bypassing all
the URI-to-servlet mapping that WebKit usually does. To do this,
you'll either need to hack WebKit yourself or use the experimental
refactoring of Webware that I've been working on (search for
WebwareExpRefactoring on the Wiki). If you use
WebwareExpRefactoring, these hard-wired servlets can be run in the
same process as your normal servlets.
On Wednesday 20 March 2002 07:38, Geoffrey Talvola wrote:
> Huy Do wrote:
> > Hi all,
> >
> > I am in the process of starting a major development project
> > in Python, and
> > was evaluating the use of Webware as the framework for the
> > application.
> >
> > I am basically looking for views on whether Webware can handle
> > 400-500 concurrent users 24/7 365 days a year, with minimal down
> > time and administration. Performance, reliability and robustness
> > is a major issue in
> > our project. I say this because our current application
> > (which is being
> > rewritten) offers the last two but not the first. Webware
> > needs to be able
> > to provide a platform which can satisfy these requirements.
>
> I wouldn't choose Webware unless you were comfortable being the
> first person to build a site in Webware the handles that much
> traffic. (I certainly haven't heard of any existing Webware sites
> that handle that much traffic.)
>
> Certainly you'd need a substantial pool of servers running WebKit,
> with a robust load balancer that supports session affinity using
> cookies (if you're planning on using cookie-based sessions). And
> assuming you're using an RDBMS back-end, you'll have to make sure
> it can handle the load. Given that, I don't see why WebKit
> wouldn't be able to support 500 concurrent users.
>
> I don't know how many servers you'd need in the pool. Anyone have
> any back of the envelope estimates?
>
>
> - Geoff
>
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
|