On Mar 31, 2007, at 12:02 AM, Joe Schaefer wrote:
You're wandering into largely unchartered territory by using APR:: outside of mod-perl, so I would try to be conservative if possible, and follow the examples in the test code. APR::Pool has a good set of tests, so I'm really not sure the problem is there or somewhere in apreq's xs. It just stood out that you were using a new pool for each subroutine call, which probably isn't the best way to do things.
OK, thanks for the advice. I'm actually a bit surprised this is uncharted territory.
I'm working on trying to improve the performance of Catalyst's body parsing. We're currently using the all-Perl HTTP::Body, and it actually beats APR::Request for urlencoded data. The regexes are pretty simple, so this isn't too surprising.
Where I hope it will help a lot more is multipart/form-data parsing, but I don't have this working yet to see. I also want to use it to replace some uses of URI::Escape which is fairly slow compared to apreq.
The reason I want it to work outside of Apache is so that people running Catalyst is FastCGI mode, or using one of the standalone Perl servers, can benefit from the improved performance. I have a grand plan of building a standalone XS module that does a lot of what apreq does, but without all the Apache requirements. URI escaping/ unescaping, header parsing, cookies, query strings, body data, etc. A lot of the apreq code could be used in something like this I think. The barrier to entry with apreq is pretty high at the moment, when compared to a standard CPAN module.
-Andy
