Tuesday, June 15, 2010

FreeBSD 8, Apache 2.2.14, Python 2.6.4, mod_wsgi 3.2 compile failure

This is a keyword laden post. I spent far too long trying to figure this out, and Google could not help me. Turns out it's really simple, but getting there was challenging, to put it mildly. Here goes:

/usr/local/include/pth/pthread.h:537:1: warning: this is the location of the previous definition
mod_wsgi.c: In function 'wsgi_discard_output':
mod_wsgi.c:11599: error: 'apr_bucket_type_t' has no member named 'pth_read'
mod_wsgi.c: In function 'wsgi_execute_remote':
mod_wsgi.c:12112: error: 'apr_bucket_type_t' has no member named 'pth_read'
apxs:Error: Command failed with rc=65536

If you are using the platform above, and get an error message that looks like that when building mod_wsgi 3.2, the problem is due to a configure option in your Python installation. Take the following steps:

cd /usr/ports/lang/python26
make config
make deinstall distclean
make install

Update the configuration, and disable GNU Pthreads. I'd also turn on SEM and THREADS, so that you can get the benefit of the multiprocessing module in Python 2.6.

Now, time to fix up mod_wsgi

cd /usr/ports/www/mod_wsgi3
make deinstall distclean
make install

And that will do it. You should now get everything working cleanly.

Announcing tgext.xmlrpc v0.8

This is an important update, and also one that is 100% backwards compatible.

This update allows you to have nice Python method signatures, as opposed to the hacky "*p, **kw" trick that v0.6 required on all methods.

To clarify, an example. v0.6 code required this:

class MyXmlRpc(XmlRpcController):
    @xmlrpc([['int', 'int', 'int']])
    def sumthem(self, *p):
        return p[0] + p[1]

v0.8 finally corrects this ugliness. This now works:

class MyXmlRpc(XmlRpcController):
    @xmlrpc([['int', 'int', 'int']])
    def sumthem(self, i1, i2):
        return i1+i2

Note that any code written for v0.6 will work just fine with v0.8. This is a purely cosmetic change, though a welcome one, I think.

It is available via PyPI and BitBucket (with documentation also on BitBucket).

Note that I did not forget to finish my Amazon EC2 benchmarking series. The next post in the series has been bugging me. I might not be William Shakespeare, but I do have some standards for my writing, and I've not been able to write up anything decent yet. I think I've finally figured out why I hated what I was writing, so will finish that series this week.

Wednesday, June 9, 2010

TurboGears and Amazon EC2 Benchmarking, Part 2: Requests per Second

That all important question has been asked, and is now answered: How fast is TurboGears? I started this series yesterday when I described my methodology. I conclude soon with my analysis of what I did, and what I found.

Tuesday, June 8, 2010

TurboGears and Amazon EC2 Benchmarking, Part 1: Methodology

This is going to be a multi-part series. As of right now, I've got at least three parts, and I may be adding another one in. I've just gathered a lot of data from Amazon, and the TurboGears EC2 images I made. Enough of it, in fact, that I'm not sure how to present all of it. For now, I'll explain how I gathered the data.