FAPWS3s roadmap

1. Timers

(Implemented since release 0.5)

I would like to implement the libev timers in the next release. This is an extremely useful feature because it will allow you to increase the speed of most of the website quite drastically.

Thanks to the libev library, Fapws3 is an "event based" webserver. This means for example, that you will not be forced to commit all of your database updates after every changes (like most systems do), but you could delegate this task to a timer ;-).

This will dramatically improve the overall website performance!!!

For sure such asynchronous commit must be use with precautions



2. Defer

(Implemented since release 0.7)

Defer mechanism allow you to delegate the execution of some tasks without impacting the normal flow of your script. This is not a thread, but as the same effect.

3. Better docmentation

User's community contribution is here resuested. Feel free to send me your proposed texts by email (william _dot_ os4y _at_ gmail.com)

4. A test 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 execute the tests and share the results with us, on our website.

Here also the user's community help is well come

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 FAPWS: 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:

More over the script must collect some critical info about the context of the machine:

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.

5. HTTP 1.1

Currently FAPWS close and open connections for each transactions. We could still improve the performance by re-using the same connection for all transactions between one client and the server; this is mainly the objective of http 1.1

Fork me on GitHub