A great part of VPS users run a CentOS, also a lot of real servers run CentOS nowadays. Usually this happens as CentOS users hope that it should be more stable, tested and secure then other distributions as being derived from an enterprise commercial one.
This might be true for most cases, but while developing PyHP we found a lot of “unknown mysterious bugs” that happened only on CentOS. After some investigation we found that apr_stat on CentOS always returns 0 as file size (this made quite interesting to allocate buffers or use mmap to read files) and also that bucket brigades had a strange behaviour, and as strange I mean that in some conditions they never considered terminated the request and caged the user in a wonderful infinite loop (as in “while(true)” not as teleporting the user to apple head quarters).
As a big percentage of PyHP users rely on CentOS we had to rewrite some parts to use lstat instead of apr_stat and also move away from bucket brigades to ap_should_client_block. If you are using CentOS and find any problem with PyHP try to upgrade to the latest svn trunk, also if you are using the svn trunk please upgrade to the latest one as there was a bug caused by the process of migrating from bucket brigades to apr_should_client_block that might prevent your users from being able to upload big files.
PyHP got the ability to save sessions on a database, the new PyHPSessionBackend config variable can be set to “db” or “file”, and PyHPDBSessionUser, PyHPDBSessionPass and PyHPDBSessionUri can be specified to set which database to use to store sessions and which user to access the database.
This works only on mysql as mysql is currently the only database supported by the pyhp database backend. Sessions will be saved in the pyhp_sessions table which will be created by pyhp itself, so remember to give to the user you choose the ability to create tables inside the selected database.
PyHP got a new parser on subversion repository (click here to download), the new parser is still experimental and needs a lot of testing, but it has some interesting new features:
- Parsing errors reporting
- Block based indentation
- Faster parsing and inclusion
First of all, now parsing errors like unmatching tags are reported on pyhp log. It will be reported the line and the file for which the error has happened (also if the file has been included).
Next now you can indent your code as you wish inside your <?pyhp?> code blocks. PyHP will reformat the indentation based on the first line indentation. You will just have to indent your code in the same way inside the <?pyhp?> block, but the blocks can be indented as html tags now.
The new parsers is written with ragel state machines generator and it performs faster then the old one.
As the new parser might have bugs you can still compile enabling the old parser by passing –enable-newparser=no to the configure script.
Good news for PyHP. Latest SVN version got a few bug fixes and a big session management improvement. Now session collision is handled in a more coherent way, it’s a major improvement and I suggest to everyone using it to upgrade to svn revision. Also a few fixes have been implemented to catch programming errors by the developer that caused PyHP to crash making it more stable.
SVN revision 24 of PyHP now supports multiple headers!
This broke code that iterates over the old headers_in dictionary because now every value inside headers_in is a list instead of a string. On the other side code writing inside headers_out should continue to work because it is possible to insert both a string or a list inside headers_out dictionary to set only one header or multiple headers.
You can try it from here: http://pyhp.svn.sourceforge.net/viewvc/pyhp.tar.gz?view=tar
New features in PyHP this week on the SVN version
- it is now possible to set sessions timeout with PyHPSessionTimeout config variable
- The Result object from the Database Layer is now iterable and will work as performing multiple .fetch() calls
- pyhp.status is now exposed to return a status code different from HTTP_OK (200)
- pyhp.content_type is now exposed to permit serving images and files different from text/html
Also some performance tests has been performed on mod_pyhp in production mode and the results are here available:
Time taken for tests: 1.419409 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Non-2xx responses: 500 (hello_world.pyhp returns 500 on last pyhp)
Total transferred: 1558000 bytes
HTML transferred: 1344000 bytes
Requests per second: 352.26 [#/sec] (mean)
Time per request: 2.839 [ms] (mean)
Time per request: 2.839 [ms] (mean, across all concurrent requests)
Transfer rate: 1071.57 [Kbytes/sec] received
The results reveal to be quite good compared to other popular web development tools like WEBrick, mod_python and mod_php. Still they have a bunch of space for improvement to reach the “standard” ~600req/sec that more mature solutions obtain. Probably .pyhp files caching might be implemented to increase a lot performances.
I will provide a complete comparations to the other major web tools as soon as I have some time to set up a concrete test suite.