Lets not forget that (last time I checked) there are some 5500+ lines of
code in the Quixote package. Its not a fair comparison to make between a
general framework like Quixote and say a custom, point solution that solves
only a single problem - such as a CGI script that makes a database
connection, does something and terminates.
As an FYI, I did a comparison of Apache benchmarks against static html.
quixote CGI and quixote via SCGI for discussion elsewhere (a wee bit of
Python advocacy mixed in with 'understand what CGI is') - here's an excerpt:
Example - Apache Benchmark against three targets that all return the same
content.
index.html - raw html, no other processing happening
demo.cgi - a Python CGI script that churns through 5500 lines of Python
code (Quixote, a web application framework built in Python)
demo.lrp - the same code as in the prior example, but this time run as a
long running web process in a manner similar to mod_php or mod_perl (I am
intentionally over-simplifying the differences for this discussion) etc.
Results:
ab -n 2000 -c 8
requests/second transfer rate
index.html 2877 4487.94
demo.cgi 12 18.24
demo.lrp 835 1248.12
Impact on the box:
index.html - Running the test against straight html is very quick as you'd
expect. It runs so fast that its difficult to gauge the effect on the
machine except that its clear there is lots more capacity sitting in
reserve. Load might be around .40 - .50 / 60-75% idle.
demo.cgi - Load average on the box peaked at over 8.50 and the CPU's were
0% idle (mostly user)
demo.lrp - Load about .30 - .50, CPU idle 35%, very approximately
>Am Fre, 2002-07-26 um 09.11 schrieb Eckhard Licher:
> > Hello,
> >
> > after having explored several Python appservers, frameworks and the
> like (which all have their specific pros and cons) I finally found
> quixote (by accident) and I have to admit that I very much liked the
> concept instantly. Having not (yet) gone much beyond the demo examples I
> already experienced severe performance problems.