William's journal

Fapws3-11 is out

Sat, 14 Apr 2012 11:00:42 GMT

Despite what said in February, I decide to release a new version of Fapws3 for Python-2.x.

Indeed, thanks to several testors (Blacknoir, Wigunawan) Fapws3 was crashing on some systems.
This was a nasty bug to solve, because I can't reproduce it on my machines.
Since it's sounds ok now, I've decided to still release a last :-) version for those willing to use it on Python-2.x lower than 2.7 (included).

Pypi: http://pypi.python.org/pypi/fapws3/0.11.dev
TGZ: https://github.com/william-os4y/fapws3/tarball/v0.11
Github: https://github.com/william-os4y/fapws3/tags

If you permit me, I'm using this communication email to also share the status of the current development's branch: python3.
Indeed, since February, I've still progressed, and one of the main added feature concern the possibility to upload files into a temporary file (no more in memory).
This close the issue of small system (low memory) having to deal with big uploads (bigger than the available memory).

I'm now focusing on testings and documentation.
Indeed, by reading the comments, here and there, on internet about Fapws3, some people are complaining about the poor documentation. I thought that the (big) list of samples would be enough, but ... sounds clear it's not clear as a real documentation.
This is a task on the list since a long time that I have to tackle. So, I'll do it for the Python3 release.
As said by Python developers, this Python3 code is perfectly running on Python2.7.
But the good news is that it has passed all tests on a NetBSD system having python2.6 :-).

All that said, I thanks all contributors having proposed interesting code, patches, tests results, recommendations, ...
(cfr README)

Fapws3-0.10 is out

Sun, 12 Feb 2012 11:41:33 GMT

Despite lot of progress on the python3 branch, I propose a new release
of Fapws3 for python2.x.

Indeed, since 1 year (date of the last stable release), lot of new
features have been added into Fapws :-).
And several are coming from, you, the community !!! Thus, I first
thank all contributors (code, tests, ...).
This is a great achievement.
More specifically, I will thank Stiletto, Liu Qishuai and Keith for
their active contributions.

To make it short, this release comes with the following new features:
- support of tuple for callback output.
- support of socket. Thanks to this, Fapws3 is serving webpages via a
socket instead of a port.
- better support for OSX

You can download the tarfile from the github website:
https://github.com/william-os4y/fapws3
Or directly via the following link:
https://github.com/william-os4y/fapws3/tarball/v0.10
Pypi users can grab it there too: pip install fapws3

As said in the mailinglist, the python3 version of Fapws3 is nearly
out (this release will be backward compatible with python2.7).
Thus I plan to have 2 parallel branches so that there is a need for
python2.5 or 2.6.
This will change in the following months, but currently Fapws3 for
python2.x is in the master branch.

Python tests used to compare different OSes.

Sat, 26 Mar 2011 10:41:20 GMT

A bit like Jaime has did with Ruby (http://linbsd.org/), I've used the python test's scripts to compare different OSes.

All OSes are installed on the same machine (each is own partition) with default install parameters. All Hardware elements remains the same during the tests. The machine is a 4 years old PC running AMD CPU 2.4GHZ with 2GB Ram.

Tests were made with the latest Python2 release: 2.7.1.

To avoid binary packages glitches, I've downloaded and compiled Python myself on each OSes by executing the standard ./configure; make. Compiler, ... are the default one proposed by each OSes.

To get the time spent on each test, I've just add 1 line in the regretest.py script provided within the python tar file:
line 581: print test_times
In other words, at the end of the tests, this print a list of tuple: (time spent, test name).

I've tested it with NetBSD-5.1, FreeBSD 8.2, Ubuntu 10.10 and Archlinux. The Archlinux system has been fully updated just before the tests, I'll thus call it Arch 03/2011.

To be detailed, the command used after compilation was:
./python -Wd -3 -E -tt Lib/test/regrtest.py -ucpu

(This is was you will execute if you perfrom a "make test"). I've just focussed the tests on CPU set of tests.

The global results are:
------------------------

Netbsd 5.1 wins 64
FreeBSD 8.2 wins 14
Ubuntu 10.10 wins 84
Arch 03/2011 wins 196

But having 2 results very close to each other does not really means that 1 OS is significantly better than the others. To take this into account, I've introduced the tolerance principle. This means that every OSes having a result very close (x percent) to the best result will also win the test.

If we accept a tolerance of 5%, the results are:
Netbsd 5.1 wins 97
FreeBSD 8.2 wins 34
Ubuntu 10.10 wins 145
Arch 03/2011 wins 245

If we accept a tolerance of 10%, the results are:
Netbsd 5.1 wins 136
FreeBSD 8.2 wins 54
Ubuntu 10.10 wins 186
Arch 03/2011 wins 275

The detailed results are:
----------------------------------
(Livejournal does not allow me to post the full reports, because they are too long. I, thus, post a subset of them. PLease contact me (william _dot os4y at_ gmail dot_ com)if you want the full one by email).

With tolerance 0:
=============

test_abc
	Netbsd 5.1:	0.06109,	delta =   0.00%
	FreeBSD 8.2:	0.06670,	delta =   9.18%
	Ubuntu 10.10:	0.06814,	delta =  11.54%
	Arch 03/2011:	0.08548,	delta =  39.92%
winner is:  Netbsd 5.1

test_abstract_numbers
	Netbsd 5.1:	0.00120,	delta =   0.16%
	FreeBSD 8.2:	0.00256,	delta = 114.16%
	Ubuntu 10.10:	0.00140,	delta =  17.51%
	Arch 03/2011:	0.00119,	delta =   0.00%
winner is:  Arch 03/2011

test_aepack
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_aifc
	Netbsd 5.1:	1.49062,	delta =  28.61%
	FreeBSD 8.2:	1.17668,	delta =   1.52%
	Ubuntu 10.10:	1.19231,	delta =   2.87%
	Arch 03/2011:	1.15902,	delta =   0.00%
winner is:  Arch 03/2011

test_al
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_anydbm
	Netbsd 5.1:	0.00736,	delta =   0.00%
	FreeBSD 8.2:	0.01428,	delta =  94.00%
	Ubuntu 10.10:	1.17291,	delta = 15838.95%
	Arch 03/2011:	0.03939,	delta = 435.24%
winner is:  Netbsd 5.1

...

- With 5% tolerance:
================

test_abc
	Netbsd 5.1:	0.06109,	delta =   0.00%
	FreeBSD 8.2:	0.06670,	delta =   9.18%
	Ubuntu 10.10:	0.06814,	delta =  11.54%
	Arch 03/2011:	0.08548,	delta =  39.92%
winner is:  Netbsd 5.1

test_abstract_numbers
	Netbsd 5.1:	0.00120,	delta =   0.16%
	FreeBSD 8.2:	0.00256,	delta = 114.16%
	Ubuntu 10.10:	0.00140,	delta =  17.51%
	Arch 03/2011:	0.00119,	delta =   0.00%
winners are:  Netbsd 5.1, Arch 03/2011

test_aepack
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_aifc
	Netbsd 5.1:	1.49062,	delta =  28.61%
	FreeBSD 8.2:	1.17668,	delta =   1.52%
	Ubuntu 10.10:	1.19231,	delta =   2.87%
	Arch 03/2011:	1.15902,	delta =   0.00%
winners are:  FreeBSD 8.2, Ubuntu 10.10, Arch 03/2011

test_al
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_anydbm
	Netbsd 5.1:	0.00736,	delta =   0.00%
	FreeBSD 8.2:	0.01428,	delta =  94.00%
	Ubuntu 10.10:	1.17291,	delta = 15838.95%
	Arch 03/2011:	0.03939,	delta = 435.24%
winner is:  Netbsd 5.1

...

- With 10% tolrerance:
==================

test_abc
	Netbsd 5.1:	0.06109,	delta =   0.00%
	FreeBSD 8.2:	0.06670,	delta =   9.18%
	Ubuntu 10.10:	0.06814,	delta =  11.54%
	Arch 03/2011:	0.08548,	delta =  39.92%
winners are:  Netbsd 5.1, FreeBSD 8.2

test_abstract_numbers
	Netbsd 5.1:	0.00120,	delta =   0.16%
	FreeBSD 8.2:	0.00256,	delta = 114.16%
	Ubuntu 10.10:	0.00140,	delta =  17.51%
	Arch 03/2011:	0.00119,	delta =   0.00%
winners are:  Netbsd 5.1, Arch 03/2011

test_aepack
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_aifc
	Netbsd 5.1:	1.49062,	delta =  28.61%
	FreeBSD 8.2:	1.17668,	delta =   1.52%
	Ubuntu 10.10:	1.19231,	delta =   2.87%
	Arch 03/2011:	1.15902,	delta =   0.00%
winners are:  FreeBSD 8.2, Ubuntu 10.10, Arch 03/2011

test_al
	Netbsd 5.1:	NA
	FreeBSD 8.2:	NA
	Ubuntu 10.10:	NA
	Arch 03/2011:	NA
no winners

test_anydbm
	Netbsd 5.1:	0.00736,	delta =   0.00%
	FreeBSD 8.2:	0.01428,	delta =  94.00%
	Ubuntu 10.10:	1.17291,	delta = 15838.95%
	Arch 03/2011:	0.03939,	delta = 435.24%
winner is:  Netbsd 5.1

...

Release of FAPWS3-0.9

Sat, 22 Jan 2011 17:17:27 GMT

I'm really happy to announce a new release of Fapws3: 0.9.

This release contains several fixes and some interesting new features:
- Avoid a crash in case you forget the "return" command in your callback method
- a better django adaptor (look in the samples)
- a session object which allow you to associate a python object
(typically a dictionary) to a session ID
- a cookie parser (in base.py)
- better management of connections broken by the client
- a new multipart object allowing you to better manage uploads
- a new Html form generator: SimpleForm

Several contributions from lot of people. I would specifically thanks:
- Vincent for the contribution of SimpleForm and Session object
- Maxim for the Django adapter
- Shigin for the broken/slow connections
- Satori for the coding layout/organisation
- ... and several other persons.

I also use this email to present the last performance test's results
I've made to compare Fapws3 and Cherokee+uwsgi.
Both a really close, but Fapws3 eats much less memory. Fapws3 is
amongst the best :-)

Such memory impact was the key element for alarm system on which I've
contributed (funny project).

Lot of work since the last release, but lot of fun and very good collaborations.
Thanks all for that.

For the next release I would like to improve the algorithm of the file upload.
Currently Fapws3 load the whole file before giving back the hand to
the python callback and the multipart object.
To optimise memory foot print, it should directly use the selected multipart object.

william

github: https://github.com/william-os4y/fapws3/
website: http://www.fapws.org/
PyPI: http://pypi.python.org/pypi/fapws3/0.9.dev

Mon, 22 Nov 2010 21:30:29 GMT

I'm happy to announce the release of Fapws-0.8.1.
This release fix several fixes: datetime: setup.py, ...

On the other hand I'm really happy to see more and more positive
feedbacks about Fapws ;-).

Just to point one, I would mention a public website:
www.hannut-chapter.be running Fapws-0.8 since 60 days today ;-)
Moreover, this site is directly connected to Internet (no proxy).
Since 60 days, no issues, no memory leaks !!!!
It runs on a very cheap shared server with few HW resources.

Visit us on www.fapws.org
download: https://github.com/william-os4y/fapws3/

William

Release 0.6 of Fast Asynchronous Python Wsgi Server

Tue, 27 Jul 2010 08:27:46 GMT

This new Fapws3 release fixes several bugs and bring the new "timers" feature.
http://github.com/william-os4y/fapws3
http://pypi.python.org/pypi/fapws3/

As you can see in the sample, timers allow you to execute a recurrent tasks with a predefined frequency.
I'm using it in the sample to show you the performance impact it can has on a commit.
This is just a sample and I know that this will not fit every cases.

I'm currently working on a real "defer" where you can as Fapws3 to execute a tasks asynchronously from the rest of the application.
Current tests I'm doing are really promising, but wait and see ;-). Maybe for the next release.

I inform you that Fapws3 users' community is increasing and I frequently receive positive feedbacks, questions, ... .
Those questions are mainly coming from the lack of documentation regarding Fapws3.
Thus, I would request help from you for 2 main items.

People interested to provide some help have to contact me by email.

1. Documentation
------------------------------
To allow those people to better step-in Fapws3, I request help from you to improve the documentation of Fapws3.
This can be generic docs, howtos, trips, ...

To be pragmatic, send me your texts (html format) in text files, I'll add them on the website.
If the requests are too frequents, I will check to implement a wiki (but this is for later).

2. Tests script
------------------------
I have the idea to implement a script that will perform some tests and send results on our website (www.fapws.org). Every people interested could be execute the tests and share the results with us, on our website.

The idea is to have a system like some linux distributions are doing: collecting some specific informations and share them by sending it to a webserver.
I plan to send them via an http POST request.

Basically, I'm thinking about a script that will use the "ApacheBenchamrk" tool and will test some basic features of Fapws3: return a list object, return an iterable object and return a file (you have then in the famous hello_world.py sample).
Thus the script will return data like " Req/sec, Concurrency Level, Time taken for tests, Complete requests, Failed requests:, Write errors:, Requests per second, Transfer rate"
More over the script must collect some critical info about the context of the machine: cpu model, libev_flag, kernel (uname -a), fapws3 version, libev version, python version.

This will gives an idea of the performance on different systems.
This will show on which system Fapws3 can runs.
...

To provide some ideas, I'm thinking about something like:


LOG="bench_`date +%Y%m%d%H%M%S`.log"
nice -n 20 ab -n100000 -c10 http://127.0.0.1:8080/hello >> $LOG
nice -n 20 ab -n50000 -c10 http://127.0.0.1:8080/long >> $LOG
nice -n 20 ab -n50000 -c10 http://127.0.0.1:8080/iteration >> $LOG
#Parse $LOG
#Collect machine data
#send them to www.fapws.org

The server script will be something like:


# -*- coding: utf-8 -*-

import fapws._evwsgi as evwsgi
from fapws import base
from fapws.contrib import views
import os
import platform


def hello(environ, start_response):
    global switch
    start_response('200 OK', [('Content-Type','text/html')])
    switch=1
    evwsgi.trigger_idle()
    return ["hello world!!"]

staticlong=views.Staticfile("long.txt") #this is the long test residing in hello_world's sample

def iteration(environ, start_response):
    global switch
    start_response('200 OK', [('Content-Type','text/html')])
    yield "hello"
    yield " "
    yield "world!!"

def getenv(environ, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    env={}
    env['LIBEV_FLAGS']=os.environ.get('LIBEV_FLAGS','') #best would be to catch the default too
    env['libev']=evwsgi.libev_version()
    env['python']=platform.python_version()
    env['uname']=platform.uname()
    #other parameters still to implement
    return [str(env)]
   

def start():
    evwsgi.start("0.0.0.0", "8080")
    evwsgi.set_base_module(base)
   
    evwsgi.wsgi_cb(("/hello", hello))
    evwsgi.wsgi_cb(("/iterhello", iteration))
    evwsgi.wsgi_cb(("/long", staticlong))
    evwsgi.wsgi_cb(("/getenv", getenv))

    evwsgi.set_debug(0)   
    evwsgi.run()
   

if __name__=="__main__":
    start()

For sure, on the server side, a Fapws3 script must be written to collect all the feedbacks, store then in a small DB (preferable sqlite) and also present them into nice tables, and, maybe, some charts.

W.

Release 0.5 of Fast Asynchronous Python Wsgi Server

Tue, 25 May 2010 16:12:45 GMT

I'm pleased to announce the release of Fapws3-0.5.
This release fix several big fixes mainly for the iterator objects.

Please note that, to better match the wsgi recommendations, the method "evwsgi.start" requires now 2 strings.
Thanks to adapt your existing Fapws server accordingly.

I would also report you some user's feedbacks:
- Fapws, and thus libev, have been compiled on AIX 5.3
- Fapws is serving (without any frontend like pound, nginx, lighttd, ... ) a django website since +40 days without any interruptions. This website has +- 40 registred users logging and logout every days; and about 200 anonymous visitors per day.

Amongst others, thanks to Marc and Tamas for their contributions

For further details, I recommend you our website: http://www.fapws.org and our github page: http://github.com/william-os4y/fapws3

Download: http://github.com/william-os4y/fapws3/downloads

Have fun

William

Non blocking connections

Thu, 05 Nov 2009 15:37:52 GMT

By testing my Fapws3 webserver on different type of systems, I've discovered a strange behaviour of the Linux kernels.

Indeed on Linux, despite my dfferent tests, I've never had the "EAGAIN" error. On the opposite, on OpenBSD 4.6 I receive a lot of those errors during the write process.

OpenBSD is reporting that this error pop's-up because the resource is not available. Within a non-blocking context this sounds logic. Indeed, the resource can still be busy with the previous write when we try to send the new one.

Now the valid question is why we don't have such behaviour on the linux kernel ?

I must deeper investigate, but if someone has a explanation, I'm interested.

William
http://github.com/william-os4y/

ps:
I've used OpenBSD-4.6
Linux-2.6.31 from Archlinux and Ubuntu

Release of Fapws3-0.3 (Fast asynchronous python wsgi server)

Fri, 17 Jul 2009 08:08:53 GMT

I'm happy to announce the release of Fapws3-0.3.

This release does not bring new features, but fix several bugs.

Let's have fun with that peace of code ;-)

You can get it from my GitHub repository: http://github.com/william-os4y/fapws3/
Or directly via the following link: http://github.com/william-os4y/fapws3/tarball/v0.3.1

For discussions, ideas, ... feel free to join the mailinglist: http://groups.google.com/group/fapws

I've tested it with Python 2.4, 2.5, 2.6 with libev-3.6 on linux and freebsd machines (with and without pound).

I'm using it for production websites native or with Django. Contributions to have Fapws running with other wsgi framework are welcome.

William

FAPWS-0.2 (WSGI server based on libev)

Wed, 25 Feb 2009 20:29:22 GMT

I'm really happy to announce the release of FAPWS3-0.2 a WSGI webserver based on libev.

This release include several bugfixes.

You can got it on my github website: http://github.com/william-os4y/fapws3/tarball/v0.2

Most importantly, with this release FAPWS becomes much more stable and useful.

I've tested it with many different type of configurations and it has always resisted to my differents Stress tests (with ApacheBenchmark tool):
- Django webpage with a complex (and ugly) sql command with 300 concurrent requests
- Simple Django webpage with 300 concurrents requets
- for a simple Jpg files I've got 3524#/sec.

Thanks to give it a trial.

William

ANNEXES:
========

Tests with 300 concurrent requests.

Heavy Django page:
------------------

Server Software:        fapws3/0.2
Server Hostname:        127.0.0.1 
Server Port:            8084      

Document Path:          /acts/2009/
Document Length:        24554 bytes     

Concurrency Level:      300
Time taken for tests:   166.334 seconds
Complete requests:      1000            
Failed requests:        0              
Write errors:           0              
Total transferred:      19772014 bytes 
HTML transferred:       19667754 bytes 
Requests per second:    4.81 [#/sec] (mean)
Time per request:       62375.084 [ms] (mean)
Time per request:       207.917 [ms] (mean, across all concurrent requests)
Transfer rate:          116.08 [Kbytes/sec] received

Much more simple Django page
-----------------------------

Server Software:        fapws3/0.2
Server Hostname:        127.0.0.1 
Server Port:            8084      

Document Path:          /membres/Off/
Document Length:        4918 bytes

Concurrency Level:      300
Time taken for tests:   23.178 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      5290304 bytes
HTML transferred:       5154064 bytes
Requests per second:    43.14 [#/sec] (mean)
Time per request:       6953.497 [ms] (mean)
Time per request:       23.178 [ms] (mean, across all concurrent requests)
Transfer rate:          222.89 [Kbytes/sec] received

Simple jpg file
----------------

Server Software:        fapws3/0.2
Server Hostname:        127.0.0.1 
Server Port:            8084      

Document Path:          /static/images/img04.jpg
Document Length:        13974 bytes

Concurrency Level:      300
Time taken for tests:   28.369 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1416300000 bytes
HTML transferred:       1397400000 bytes
Requests per second:    3524.99 [#/sec] (mean)
Time per request:       85.107 [ms] (mean)
Time per request:       0.284 [ms] (mean, across all concurrent requests)
Transfer rate:          48754.28 [Kbytes/sec] received

Fapws3-0.1 versus Fapws2-0.3: First comparison

Tue, 30 Dec 2008 11:20:58 GMT

As promised, you can see here under results of performance tests I've made.

Machine: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ A
OS: Linux 2.6.27-ARCH #1 SMP PREEMPT
Benchmark tool: ApacheBench, Version 2.3 ($Revision: 655654 $)
Python: Python 2.6.1
Libev: libev-3.49
Methodology: run webserver and ApacheBench ("ab" in short) on the same host; 
but I use "nice -n20" for "ab". Wait enough time between each run to assure all "waiting" 
connections  will be effectively closed (+- 1 minute on my machine). Execute each 
tests 5 times and take one "ab" report which is representative (to avoid abnormal good/bad 
results).

Observations

(results are in the annexes):

Errors: we don't see it in the results here bellow, but neither Fapws2 neither Fapws3 have 
generated errors.
Requests per seconds: Fapws3 is a bit better(10%) than Fapws2 for low number of concurrent 
requests. Above 500 concurrent requests Fapws2 is a bit better (5%).
mean: Fapws3 has a better mean than Fapws2 for all tests.
median: Fapws3 is better for all tests
Standard deviation: Both are equal until 100 concurrent requests. Above Fapws2 is better.

To summarize I would say that, thanks to libev, Fapws3 is not too bad.

As comparison, I've added results of cherrypy (threaded). By the way Charrypy is not bad 
at all ;-). We can see that, as expected (cherrypy is fully written with python), 
that number of requests per seconds are much lower than Fapws. We also see the impact of 
a threaded system on the Standard Deviation. With such a big standard deviation, user's 
perception can be quite various.

William

Annexes

Fapws3-0.1	Fapws2-0.3
Server Software: fapws3/0.1 Document Path: /test Document Length: 13 bytes Concurrency Level: 10 Complete requests: 10000 Requests per second: 5565.03 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 2 0.7 2 17	Server Software: fapws2/0.3 Document Path: /hello Document Length: 13 bytes Concurrency Level: 10 Complete requests: 10000 Requests per second: 4964.60 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 2 0.0 2 3
Server Software: fapws3/0.1 Document Path: /test Document Length: 13 bytes Concurrency Level: 100 Complete requests: 10000 Requests per second: 5798.24 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 3 4.4 2 212	Server Software: fapws2/0.3 Document Path: /hello Document Length: 13 bytes Concurrency Level: 100 Complete requests: 10000 Requests per second: 4847.79 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 12 21 1.1 21 28
Server Software: fapws3/0.1 Document Path: /test Document Length: 13 bytes Concurrency Level: 500 Complete requests: 10000 Requests per second: 4464.30 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 2 20 36.1 3 368	Server Software: fapws2/0.3 Document Path: /hello Document Length: 13 bytes Concurrency Level: 500 Complete requests: 10000 Requests per second: 4818.79 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 85 103 2.6 104 107
Server Software: fapws3/0.1 Document Path: /test Document Length: 13 bytes Concurrency Level: 1000 Complete requests: 10000 Requests per second: 4300.18 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 60 120 46.3 92 220	Server Software: fapws2/0.3 Document Path: /hello Document Length: 13 bytes Concurrency Level: 1000 Complete requests: 10000 Requests per second: 4594.43 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 11 154 92.7 221 680

Charrypy-3.1.1
Server Software: CherryPy/3.1.1 Document Path: / Document Length: 13 bytes Concurrency Level: 10 Complete requests: 10000 Requests per second: 1040.73 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 5 105.4 3 9608
Server Software: CherryPy/3.1.1 Document Path: / Document Length: 13 bytes Concurrency Level: 100 Complete requests: 10000 Requests per second: 1910.31 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 0 26 268.2 3 4884
Server Software: CherryPy/3.1.1 Document Path: / Document Length: 13 bytes Concurrency Level: 500 Complete requests: 10000 Requests per second: 1250.71 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 228 659.8 5 6243
Server Software: CherryPy/3.1.1 Document Path: / Document Length: 13 bytes Concurrency Level: 1000 Complete requests: 10000 Requests per second: 1518.28 [#/sec] (mean) Connection Times (ms) min mean[+/-sd] median max Total: 1 275 865.1 5 6324

Fapws3-0.1 has just been released

Sun, 28 Dec 2008 13:51:15 GMT

Hello all,

After several months of hesitations, work, trials and tests, I'm very happy to announce the first release of Fapws3.

Fapws3 is a full re-write of Fapws2 but based on libev.

Indeed, since the API changes in libevent (>1.4.0) we were forced to modify the libevent sources before compiling it, just for the usage of Fapws2. This was not really comfortable.
Moreover, libev is incredibly very well documented.

Fapws2 will stay open just for bug fixing, but my future work will now be focused on Fapws3.

This has been successfully tested on Linux 2.6.27 and FreeBSD-6.1 with libev-3.49.

Benchmark between Fapws2 and Fapws3 is on going and will be published as soon as possible.

And because the number of people willing to discuss about Fapws is increasing, I've setup a dedicated mailing-list: http://groups.google.com/group/fapws
Feel free to join ;-).

William

ANNEXES:
--------

source repository for version 0.1
Download fapws3-0.1 as a tarball
Git repository: http://github.com/william-os4y/fapws3/tree/master
Demo site running wsgi_wiki with Fapws3: http://fapws3.vmrt.homelinux.com/

my contact details

Mon, 03 Nov 2008 14:17:29 GMT

Since the crash of my server: opensource4you.com, I've spent lot of time to recover my files from few old backups.

I've not yet find back my mailing-lists for fapws, but interested people can contact me at my new gmail account: william dot os4y at gmail.com

Sorry for disturbance.

William

FAPWS2 on github

Sun, 02 Nov 2008 07:56:58 GMT

Thanks to Piranha, I've discovered a git repository provider: github.

The new fapws2 git repository is now: http://github.com/william-os4y/fapws2/tree/master.

For interested people, I've got several good feedback about FAPWS2. Some of them have internet websites runnning without any problems. Some have even reported an uptime of +2 months without any issue.
You are always free to send me your websites running with fapws2, if they are public, I'll be happy to talk about them ;-).

My current work with FAPWS is to facilitate the integration with libevent. Indeed, for fapws2, I'm using a different methodology to parse URL than libevent does. This force me to modify the code of libevent (evhttp_handle_request); which is not a so good solution.

William

Year the reasons why the server as desapeard

Tue, 02 Sep 2008 15:35:51 GMT

I've stored all emails from the sivit.fr support team into one Yahoo folder. Even the emails send into the Yahoo Spam.

As you can see under suddenly, all of the sivit's communications were filtered out by Yahoo as Spam.
Indeed, they have used wrong email format with the fromaddress. That's why yahoo complains.

On that suddent email problem, they don't give any answers.

They claim that I've been informed on time about the issue and the associated risks. But, between the first mail and crash of the machine, we hae only 10 hours. Which are the sleeping hours.

This was, thus, rather impossible to treat them accordingly.

More over, they never explained why the server has been destroyed.
And for sure, they have never give any excuses.

This is just my, bad, story with them.
You should not be generalised, because, maybe, some customers are happy with their quality of service.

Up to everyone to decide if they are trustable.

Repository is down

Tue, 02 Sep 2008 02:39:11 GMT

After a Technical intervention of sivit.fr, the dedicated server has been removed.
The server opensource4you.com is, thus, no more available.

I'm no more trusting them and will surely no more use their services.

I'll keep you informed when a new repository will be setup.

William

using fapws2 as a proxy

Tue, 15 Apr 2008 12:00:21 GMT

On current multi core machine, I have the idea to run several fapws2 instances for complex websites. That way I will have several fapws2 server dealing each a part of the web application.

To stay with fapws2, that means that one instance will be a "front end" web server. He will querying the others.

But what is the best way to implement such proxy mechanism (by only using libevent, no threads) ?
People having knowledge, references of document exaplaining it, ... are welcome ;).

William

fapws2 with libevent-1.4.3-stable

Tue, 15 Apr 2008 11:48:09 GMT

I've just tried compiling fapws2 with the brand new libevent library. With all the changes that they have made inside libevent, I was suprised that fapws2 is running without major changes ;).

Patch for libevent-1.4:
Remove "static" for the procedure called "evhttp_handle_request" in http.c.
FAPWS2 over-writte this procedure, thus it cannot be static ;(.
I've provided my evhttp_handle_request (with backward compatibility), but the libevent development team has not include it ;(.

On the most important feature of fapws2: performance, and based on my simple "hello world" sample, I see a small improvement: 6%. (633#/sec with libevent-1.4.3 against 594#/sec with libevent-1.3e).

Additional tests must be made with this new library but the starting point is promising ;).

William

git repository
Tar file here

Annexe

Patch on the libevent-1.4.3 sources

[libevent]$ diff http.c http_orig.c
1936c1936
< void
---
> static void

with fapws2 based on libevent-1.4.3

[fapws2]# ab -n 1000 -c10 http://127.0.0.1:8080/hello
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        fapws2/0.3
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        13 bytes

Concurrency Level:      10
Time taken for tests:   1.579206 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      105000 bytes
HTML transferred:       13000 bytes
Requests per second:    633.23 [#/sec] (mean)
Time per request:       15.792 [ms] (mean)
Time per request:       1.579 [ms] (mean, across all concurrent requests)
Transfer rate:          64.59 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       3
Processing:     1   15   9.5     12      48
Waiting:        0   14   9.4     12      48
Total:          3   15   9.5     12      48

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     13
  75%     14
  80%     15
  90%     38
  95%     42
  98%     45
  99%     46
 100%     48 (longest request)

with fapws2 based on libevent-1.3e

[root@myhost fapws2]# ab -n 1000 -c10 http://127.0.0.1:8080/hello
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        fapws2/0.2
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        13 bytes

Concurrency Level:      10
Time taken for tests:   1.683275 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      105000 bytes
HTML transferred:       13000 bytes
Requests per second:    594.08 [#/sec] (mean)
Time per request:       16.833 [ms] (mean)
Time per request:       1.683 [ms] (mean, across all concurrent requests)
Transfer rate:          60.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1   16   9.5     13      58
Waiting:        0   15   9.4     13      55
Total:          3   16   9.5     13      58

Percentage of the requests served within a certain time (ms)
  50%     13
  66%     14
  75%     16
  80%     19
  90%     29
  95%     42
  98%     44
  99%     48
 100%     58 (longest request)

Fapws2-0.2 ready for tests

Mon, 12 Nov 2007 19:14:07 GMT

I've just released the 0.2 version of FAPWS2 (Fast Asynchronous Python WebServer) which is WSGI compliant.

With this release, several bug fixes has been done (binaries are better working, cookies, ...).
Now, FAPWS2 can now serve Django application (GET and POST), the admin page is working too ;-).

Please not that FAPWS2 has been developed based on libevent-1.3x releases (on linux, but has been reported to work on Mac-OSX too).

TGZ: http://www.opensource4you.com/downloads/fapws2-0.2.tgz
Git repository: http://www.opensource4you.com/cgi-bin/gitweb.cgi?p=fapws2;a=summary

Your feedbacks, comments, tests results, ... are very welcome.

William

fapws2 (based on evhttp api of libevent) is working ;-)

Thu, 08 Nov 2007 08:30:50 GMT

Nearly 1 month after my last post, I've got a working version of fapws using the http api of libevent.

Thanks to a wonderfull book call "C in a nutshell", the python API documentation and to the google code search engine, I've been able to write the required code; but also to track memory leaks, debug, ...

Thus, definitively YES, writing python API in C is not that difficult (for a python developer who don't know C)

Concerning our WSGI webserver, it can serve +1100#/sec on my Athlon-XP 1.2Ghz. It can resist to massive C10k attacks and it can serve Django applications (look into the samples).

It was really exiting and funny to write this peace of code and I would thanks all people who provide me help, feedbacks and productive remarks. I would also specially thanks Lateef J. who has guide me (more than the others) even concerning stupid questions I have had.

Because of a better integration with C, this new fapws (called fapws2, see later) is +-40% quicker than fapws for the simple hello_world.
For Django application, it runs 30% quicker than CherryPy 3.0.2 (thread base).
(I'm not against cherrypy, which is a great webserver. But Cherrypy is, for me, the best one, thus the reference.).
At least, Fapws2 prove that select based webserver can be a good alternative to thread base one.

The goal was to show the feasibility and the capabilities, lot of works still need to be done on this peace of code. Do not use it others than for tests.
The prove-of-concept is finished, now, based on the results, a project can start. In that context help of everyone is welcome: for testing, coding, documentation, and ... to find a better name (sounds that fapws is too close to fap which is not related to serious IT matters ;-) ).

Source code is here: http://www.opensource4you.com/cgi-bin/gitweb.cgi?p=fapws2;a=summary
tgz is here: http://www.opensource4you.com/downloads/

William (william _:at: opensource4you :dot:_ com)

PS:
Like for my previous post, prove (apache benchmark) will come soon.

(added on November, 10th)
ANNEXE
----------------
FAPWS2 performance on "hello world":

[root@myhost]# nice -n20 ab -n1000 -c10  http://127.0.0.1:8080/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        fapws2/0.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        13 bytes

Concurrency Level:      10
Time taken for tests:   1.313237 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      105000 bytes
HTML transferred:       13000 bytes
Requests per second:    761.48 [#/sec] (mean)
Time per request:       13.132 [ms] (mean)
Time per request:       1.313 [ms] (mean, across all concurrent requests)
Transfer rate:          77.67 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1   11  13.0      8     107
Waiting:        0   10  12.3      7     107
Total:          2   11  13.0      8     107

Percentage of the requests served within a certain time (ms)
  50%      8
  66%      8
  75%      8
  80%      9
  90%     33
  95%     40
  98%     41
  99%    106
 100%    107 (longest request)

FAPWS perofrmance on "Hello world"

[root@myhost]# nice -n20 ab -n1000 -c10  http://127.0.0.1:8080/hello
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        fapws/0.7
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        11 bytes

Concurrency Level:      10
Time taken for tests:   1.909155 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      112000 bytes
HTML transferred:       11000 bytes
Requests per second:    523.79 [#/sec] (mean)
Time per request:       19.092 [ms] (mean)
Time per request:       1.909 [ms] (mean, across all concurrent requests)
Transfer rate:          57.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    8  11.0      6     108
Processing:     3   10   9.5      8     110
Waiting:        0    6   8.9      5     108
Total:         13   18  13.3     14     112

Percentage of the requests served within a certain time (ms)
  50%     14
  66%     14
  75%     15
  80%     16
  90%     43
  95%     47
  98%     49
  99%    112
 100%    112 (longest request)

On this example, FAPWS2 is 45% quicker than FAPWS.

Libevent has pure http API

Mon, 08 Oct 2007 17:19:18 GMT

It's now long time since my last post.

This surely does not means that I'm stopping FAPWS, at contrary I'm more and more convinced that one of the beauty of Python reside in his gluing capabilities.
This observation is probably not new to lot of people, but for my personal case it's better now than never ;-), no ?

After that small philosophical intro, please go back to our main interest: integrate libevent within the python world.
What's great with libevent is that since several release, they have introduced several HTTP low level APIs: send_reply, send_error, ...
I've tried to use them thanks to pyrex, ctype and swig.

With every of those tools I'm facing issues, problems, ... to get a webserver working correctly.
Because I want FAPWS to be light, efficient and stable, I don't like the idea to add layers on which I don't have too much control. Hoooooo, I'm already hearing some voices ;-). The point is not linked with those tools, but more to my competencies to be able to have them working correctly. Indeed, when you are new to C (which is my case) and try to understand how to use swig, trust me, this is not piece of cake.
Thus I'll use the simple, low level Python API for this project. This will be a way for me to learn C and C API of Python.

Will it be easy to learn C from Python ?

We will see.
Any how, any helps are welcome ;-).

Here after, you can see a minimalist webserver serving the famous "Hello World!":

import ctypes
import sys

libevent=ctypes.cdll.LoadLibrary('libevent.so')

def root_handler(req, *arg):
    #print "got request:", req
    libevent.evbuffer_new.restype=ctypes.c_void_p
    #Build a buffer and put page content into it
    buf=libevent.evbuffer_new()
    libevent.evbuffer_add_printf.argtypes=[ctypes.c_void_p, ctypes.c_char_p]
    libevent.evbuffer_add_printf(buf,"Hello world!\n\n")
    #send the buffer with a return code of 200
    libevent.evhttp_send_reply.argtypes=[ctypes.c_void_p, ctypes.c_int, ctypes.c_char_p, ctypes.c_void_p]
    libevent.evhttp_send_reply(req, 200, "OK", buf)
    return 1


    
def main():
    #We just initialise and give the server address and port
    libevent.event_init()
    libevent.evhttp_start.argtypes=[ctypes.c_char_p, ctypes.c_short]
    libevent.evhttp_start.restype=ctypes.c_void_p
    http=libevent.evhttp_start('0.0.0.0',8080)
    #we lik the call to root_handler at a request of "/"
    FUNC=ctypes.CFUNCTYPE(ctypes.c_int, ctypes.c_void_p)
    libevent.evhttp_set_cb.argtypes=[ctypes.c_void_p, ctypes.c_char_p, ctypes.c_void_p]
    libevent.evhttp_set_cb(http,"/",FUNC(root_handler), None)
    #we loop and wait events ;-)
    libevent.event_dispatch()
    #we close the loop
    print "end loop main" 
    libevent.evhttp_free.argtypes=[ctypes.c_void_p]
    libevent.evhttp_free(http)

if __name__=="__main__":
    main()

Note: I don't know exsactly why, but the server does not stop when you hit "-c". You must kill it ;-(.

Amazingly, I'm able to get 1700#/sec on my 1.2Ghz Athlon.

Annexes:

[myhost ~]$ ab -n2000 -c10 http://127.0.0.1:8080/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)

Server Software:
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        14 bytes

Concurrency Level:      10
Time taken for tests:   1.170227 seconds
Complete requests:      2000
Failed requests:        0
Write errors:           0
Total transferred:      196000 bytes
HTML transferred:       28000 bytes
Requests per second:    1709.07 [#/sec] (mean)
Time per request:       5.851 [ms] (mean)
Time per request:       0.585 [ms] (mean, across all concurrent requests)
Transfer rate:          163.22 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       3
Processing:     2    5   2.5      4      15
Waiting:        1    5   2.6      4      15
Total:          2    5   2.5      4      15

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      7
  80%      7
  90%      9
  95%     11
  98%     13
  99%     14
 100%     15 (longest request)
[myhost ~]$

Fast Asynchronous Python Web Server

Tue, 27 Mar 2007 21:01:43 GMT

I'm really happy to announce that we've reached (I'm no more alone on this project) a first interesting objective with FAPWS: FAPWS-0.6!!!

Indeed, We don't have memory leaks any more, the server is much more stable and the WSGI implementation is now rather complete (Thanks Alex).

I've tested it with a simple Django wiki (http://e-scribe.com/news/171) ... and it works :-)!!!.
In this specific case the added value of FAPWS is not that big (114 #/sec vs 81 #/sec with lighttpd+flup-scgi). But If I look at my simple wiki (code is in the samples folder of the fapws .tgz), It can go up to 628#/sec!!!.

Even with all those bugs fixes, WSGI adaptations, ... the overall performance of FAPWS remains at a very high level (for a python web server): 898#/sec.

I would here thanks Alex for his very valuable collaboration related to WSGI; Roberto and Lateef for their tests, ideas and feedbacks (I really hope I've not forgot someone)
The active users community is not that big, but the quality is there ;-); and most important we have lot of fun with FAPWS.

As I've already said, don't hesitate to give your feedbacks, ideas, comments, ...

William

PS:
- simple demo web site running FAPWS: http://www.opensource4you.com:8080/
- Code repository: http://www.opensource4you.com/cgi-bin/gitweb.cgi
- download: http://www.opensource4you.com/downloads/

ANNEXES
-----------


[root@bsdhome ~]# nice -n 20 ab -n 1000 -c10 http://localhost:8080/hello
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software:        fapws/0.6
Server Hostname:        localhost
Server Port:            8080

Document Path:          /hello
Document Length:        11 bytes

Concurrency Level:      10
Time taken for tests:   1.113 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Total transferred:      112000 bytes
HTML transferred:       11000 bytes
Requests per second:    898.47 [#/sec] (mean)
Time per request:       11.13 [ms] (mean)
Time per request:       1.11 [ms] (mean, across all concurrent requests)
Transfer rate:          100.63 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1     4    1.6      5    16
Processing:     2     6    1.9      6    18
Waiting:        1     5    1.8      5    16
Total:          9    11    1.0     10    19

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     11
  80%     11
  90%     12
  95%     13
  98%     14
  99%     19
 100%     19 (last request)

FAPWS status and progress

Tue, 13 Feb 2007 19:21:23 GMT

I've been busy since last 2 months to fix several bugs in the current implementation.
I've nevertheless add some minor features that increase a little bit the global performance: internal caching, refactory of some classes, ...

Now fapws can resist nicely to massive attacks:
- via the ApacheBenchmark tool with 100, 200, ... concurrent connections.
- via 50 "wget -r" in parallel.
- both combined.

Fapws still need to be enhanced in the HTTP headers parsing. I suspect that it can crash is the header is not correctly formatted.

Based on the same html page, Fapws can reached (on my machines) 728#/sec. This is a major step compared to CP or Twisted (198#/sec). But, we still have room for improvement, indeed I have 4235#/seq with Lighttpd.

Many thanks for the different feedback, comments, suggestion and bug fixes I've received.

William

PS:
- simple web site running FAPWS: http://www.opensource4you.com:8080/
- Code repository: http://www.opensource4you.com/cgi-bin/pygitweb/views.py?project=fapws%2F.git

release of fapws-0.5 (Fast Asynchronous Python Web Server)

Sun, 12 Nov 2006 14:03:36 GMT

Now that several bugs are now fixed in the kernel of FAPWS. FAPWS is now much more stable and resits very correctly to C10K attacks.

On my Gentoo PC (1.2Ghz), Fapws can perform 3x faster than Cherrypy-3.0. Not because CP3 is bad, but because the heart of FAPWS is written in C (libevent). Thanks to libevent (and pyevent), you are able to run FAPWS on Windows, Linux, *BSD, Mac OSx and Solaris machines.

As said before, FAPWS is targeted to run on small hardware (limited memory, ...) like several Virtual Dedicated Servers (VDS) offer.

Up to now, the WSGI implementation is quite simplistic. If people are willing to improve this part of FAPWS with me, they are welcome ;-) (william _at_ opensource4you.com)

William.

links:

FAPWS repository

FAPWS-0.5.tgz

Demo of FAPWS wiki

ANNEXE:
---------------

(I've made 5 concurrent requests and started CP3 with 10 threads).

Server Software:        fapws/0.5
Server Hostname:        localhost
Server Port:            8081

Document Path:          /hello
Document Length:        11 bytes

Concurrency Level:      5
Time taken for tests:   8.421295 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      570000 bytes
HTML transferred:       55000 bytes
Requests per second:    593.73 [#/sec] (mean)
Time per request:       8.421 [ms] (mean)
Time per request:       1.684 [ms] (mean, across all concurrent requests)
Transfer rate:          66.02 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    3   1.4      3      15
Processing:     2    4   1.7      5      17
Waiting:        0    2   1.7      2      13
Total:          7    7   1.6      7      18

Percentage of the requests served within a certain time (ms)
  50%      7
  66%      8
  75%      9
  80%      9
  90%      9
  95%      9
  98%     10
  99%     12
 100%     18 (longest request)




Server Software:        CherryPy/3.0.0beta2
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      5
Time taken for tests:   25.149331 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      710000 bytes
HTML transferred:       60000 bytes
Requests per second:    198.81 [#/sec] (mean)
Time per request:       25.149 [ms] (mean)
Time per request:       5.030 [ms] (mean, across all concurrent requests)
Transfer rate:          27.56 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        3   10   4.8     10      27
Processing:     6   14   4.9     15      30
Waiting:        0    7   5.9      7      26
Total:         23   24   1.7     24      35

Percentage of the requests served within a certain time (ms)
  50%     24
  66%     24
  75%     25
  80%     25
  90%     26
  95%     26
  98%     32
  99%     33
 100%     35 (longest request)

Fast Asynchronous Python Web Server

Sun, 29 Oct 2006 12:58:32 GMT

As said in my previous post, the code of
FAPWS is now available. As my repository is git, you can browse the code on my python gitweb.

If you want to see it running, you can see a demo here.

- FAPWS requires to have libevent and pyevent.
- FAPWS works on linux and Windows.
- FAPWS is based on WSGI.
- FAPWS is very light.
- FAPWS is very very fast!!!

William