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 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 > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-discuss _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
