And.... its Spanish!! http://es.wikipedia.org/wiki/Servidor_HTTP_Cherokee
Finally a Spanish international tool working fine :-D
by the way, it is shown as the best and fastest modern web server
http://www.cherokee-project.com/benchmarks.html
p.s: I'm Spaniard
El 18/01/2010 18:06, Ivan P escribió:
No this is not bytecode compiled. What is odd is that I thought I
compiled admin yesterday to get great performance improvement, but now
compiling is not making a difference. I'm somewhat confused. So, I
cannot give much more data on this topic at the moment.
Why I chose Cherokee in the first place, though, was for the reported
ease of setup, since I have much work and little time. I think in that
domain it and uWSGI succeed. The setup was painless, it is flexible,
easy to tweak, uses next to no memory and seems reliable.
On Jan 18, 7:30 pm, mdipierro<mdipie...@cs.depaul.edu> wrote:
This more like what I would expect. Is this bytecode compiled? It
makes a difference.
On Jan 18, 10:15 am, Ivan P<ivanv...@gmail.com> wrote:
OK, I had some flaws in the last test that, I have realized, were
affecting the performance. For example uwsgi was outputing a whole lot
of data into gnome-terminal, which used much CPU. The new benchmark
with uwsgi running as a daemon:
Concurrency Level: 5
Time taken for tests: 22.585 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 6906000 bytes
HTML transferred: 6531000 bytes
Requests per second: 44.28 [#/sec] (mean)
Time per request: 112.923 [ms] (mean)
Time per request: 22.585 [ms] (mean, across all concurrent
requests)
Transfer rate: 298.62 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 65 113 6.2 111 164
Waiting: 65 112 6.2 111 164
Total: 66 113 6.2 111 164
Percentage of the requests served within a certain time (ms)
50% 111
66% 112
75% 113
80% 115
90% 119
95% 125
98% 133
99% 138
100% 164 (longest request)
ALSO, I tried running uwsgi with 4 worker processes by adding the
option "-p 4":
Concurrency Level: 5
Time taken for tests: 14.575 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 6906000 bytes
HTML transferred: 6531000 bytes
Requests per second: 68.61 [#/sec] (mean)
Time per request: 72.876 [ms] (mean)
Time per request: 14.575 [ms] (mean, across all concurrent
requests)
Transfer rate: 462.71 [Kbytes/sec] received
On Jan 18, 6:20 pm, mdipierro<mdipie...@cs.depaul.edu> wrote:
You are right, the admin interface does not do db IO. From your test
it is slow. Not sure why that is.
On Jan 18, 2:14 am, Ivan P<ivanv...@gmail.com> wrote:
Hmmm, you are right. But, since I was loading the index page of the
standard admin interface, that I have not compiled, I guess it is
whatever the admin defaults are (does admin even use a db?). Right?
On Jan 18, 12:15 am, mdipierro<mdipie...@cs.depaul.edu> wrote:
In your benchmark, did you set migrate=False and bytecode compile the
app? Did you use Auth? How many additional tables?
On Jan 17, 3:11 pm, mdipierro<mdipie...@cs.depaul.edu> wrote:
These tests basically measure lots of things at once and are dominated
by the database. If your are using sqlite, it locks the database
completely on every request so there is no concurrency.
I think we need a standard app for testing with various options:
1) db, no-db
2) 1,10,100 tables
3) view, no-view
4) compiled, not-compiler
On Jan 17, 2:49 pm, Ivan P<ivanv...@gmail.com> wrote:
Alex,
Actually, this is my first try at a production deployment, and I have
not set up another to test against. Is there a standard "ab" test that
is usually run for comparison in web2py community? In any case I ran
the following command with sqlite as the backend server (but doubt it
matters for this page) for the cherokee setup and the web2py builtin:
ab -n 1000 -c 5 url
===CHEROKEE results===
Server Software: Cherokee/0.99.39
Server Hostname: cparts.localhost
Server Port: 80
Document Path: /admin/default/index
Document Length: 5658 bytes
Concurrency Level: 5
Time taken for tests: 41.809 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 6031000 bytes
HTML transferred: 5658000 bytes
Requests per second: 23.92 [#/sec] (mean)
Time per request: 209.043 [ms] (mean)
Time per request: 41.809 [ms] (mean, across all concurrent
requests)
Transfer rate: 140.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 65 208 11.3 208 283
Waiting: 65 208 11.3 208 283
Total: 69 209 11.2 208 283
Percentage of the requests served within a certain time (ms)
50% 208
66% 212
75% 214
80% 215
90% 219
95% 223
98% 235
99% 245
100% 283 (longest request)
===CHERRY PY results===
Server Software: CherryPy/3.2.0beta
Server Hostname: localhost
Server Port: 8000
Document Path: /welcome/default/index
Document Length: 6531 bytes
Concurrency Level: 5
Time taken for tests: 41.120 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 6892000 bytes
HTML transferred: 6531000 bytes
Requests per second: 24.32 [#/sec] (mean)
Time per request: 205.601 [ms] (mean)
Time per request: 41.120 [ms] (mean, across all concurrent
requests)
Transfer rate: 163.68 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 51 205 66.0 197 499
Waiting: 50 201 65.2 193 499
Total: 52 205 66.0 197 499
Percentage of the requests served within a certain time (ms)
50% 197
66% 222
75% 240
80% 254
90% 296
95% 328
98% 368
99% 402
100% 499 (longest request)
Sure, I'll make it a slice.
On Jan 17, 11:01 pm, Alex Fanjul<alex.fan...@gmail.com> wrote:
Many thanks for your tutorial Ivan,
I'll give it a try... have you noticed any improvements with cherokee?
could you show us your "ab" benchmarks?
regards,
Alex F
P.S: try to make an slice in web2pyslices.com
El 14/01/2010 23:14, Ivan P escribi :
Inspired by Phyo Arkar's howto on setting up web2py with Cherokee and
FCGI I tried the setup, but was somewhat unsatisfied with the fcgi
method and decided to try uWSGI. I am happy I did so, since it proved
to be real easy and uWSGI is a real powerhouse and deserves attention
of the whole python webdev community. On to the howto.
I. Compile from source and run the latest uWSGI, 0.9.3 in my case
(available herehttp://projects.unbit.it/uwsgi/wiki).
1. Download the source from and unzip.
2. To compile you must install packages python-dev and libxml2-dev (at
least thats what they are called on a debian-based system)
3. When compiling simply run pick a makefile which matches your OS and
python version and run something like "make -f Makefile.Linux.Py26".
This produces only one executable named uwsgi26, where 26 is my python
version. You can put it in /usr/local/bin.
5. To run it, you have two options:
5a) Create an xml file and call it, for example, config.xml. Put
something like this in it:
<uwsgi>
<pythonpath>/var/web2py/</pythonpath>
<app mountpoint="/">
<script>wsgihandler</script>
</app>
</uwsgi>
In this file "pythonpath" is where your web2py directory is and
"script" is the file you want to run, in this case its web2py's
"wsgihandler.py". Now run uWSGI like this, but replace "www-data" with
the owner of your web2py directory, if its the same as your current
user omit the sudo command:
sudo -u www-data uwsgi26 -s /tmp/uwsgi.sock -C -x config.xml
Why you need to change user is because web2py writes things (session
data for example) to disc during execution, so the uwsgi process,
which runs the web2py code, has to be the owner of the directories
that contain the framework. Note that uwsgi now opened a socket we
called "/tmp/uwsgi.sock" About other options consult the uwsgi manual
or "uwsgi -h".
5b) You can omit the xml file and pass all the info via command line,
...
read more »
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.com
www.mhproject.org
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
