Open Source Notes, Wiki, Forums. We Proudly Use Debian GNU/Linux
I’ve been able to get MovableType and libapache2-mod-fcgid to play nicely together, and tonight I tried to get MovableType and mod_perl2 to work. Alas, I’m not sure it can happen:
http://codewitch.org/2007/10/mt-and-mod-perl-2.html
I gave up on this and decided to continue using mod-fcgid. It works well enough.
I’ve been working with PHP for a long time, and more recently and intensely, Perl and Python. I like all three languages, but since I’ve heard PHP get bashed so much, I have to say in some ways I expected more from Perl and Python.
They are very nice, but for my uses, all three languages are fairly similar. I’m doing web development using SQL, XML and XSL, so I’d probably end up seeing a bigger difference using Postgres over MySQL, or Xalan-C instead of libxslt.
I’ve been unable to measure memory consumption of PHP and Python, but for mod_perl I’ve been using GTop to measure memory consumption. I’ve been able to measure te execution time requests on each platform, but I only see those numbers as relevant for self comparison, meaning I won’t use those numbers to say one language is faster than another in my context, because I can’t be sure that the start and stop points are the same within each program.
I have noted a few things in my experience:
* mod_perl is good for integrating with Apache. Duh!
* python and mod_wsgi is nice for controlling application setups from apache, and the wsgi interface is nice, but otherwise it seems quite similar to mod_fcgid
* PHP is of course a very convenient language for getting things going, used with xcache and mod_fcgid, the performance is quite nice too
This looks very interesting… should be helpful in getting me more acquainted with perl. To install on Lenny, I first installed php5-dev, but unfortunately that still didn’t do it. Looks like this module needs the –embed option set in the php interpreter to be used. Going to have to hold of on this to install it on a testing environment rather than a development machine.
Now I’m trying to get PHP installed in such a way I can use it… I tried getting the perl makefile to use the php headers installed by debian, but it wants to look in /usr/local/*. Hmmm.
UPDATE: I was able to get this going. 
* php-5.2.6
* ./configure –enable-embed=shared –enable-maintainer-zts
* make
* make install
That put the new php into /usr/local. Then I installed PHP::Interpreter manually after trying to get it via CPAN, which didn’t happen. When I tried to use it, I got complaints about Exporter, so I added that as a use include, and it worked! Getting it to work with mod_perl and even as a regular cgi-bin file was challenging, but I got it to go:
#!/usr/bin/perl use Exporter; use PHP::Interpreter; print "Content-Type: text/html\n\n"; my $php = PHP::Interpreter->new(); my $old_hander = $php->set_output_handler(\$scalar); my $output = $php->eval(q^ phpinfo(); ^); my $outbuf = $php->get_output; print $outbuf;
sub handler { my $r = shift; my $php = PHP::Interpreter->new(); my $scalar; my $old_hander = $php->set_output_handler(\$scalar); my $output = $php->eval(q^ phpinfo(); ^); my $outbuf = $php->get_output; $r->print($outbuf); return Apache2::Const::OK; }
Why bother doing this? The novelty of it is pretty good by itself!
Next up, a more challenging configuration setup:
--enable-embed=shared \ --enable-maintainer-zts \ --disable-rpath \ --disable-static \ --with-pic \ --with-pear=/usr/share/php \ --enable-calendar \ --enable-sysvsem \ --enable-sysvshm \ --enable-sysvmsg \ --enable-bcmath \ --with-bz2 \ --enable-ctype \ --without-gdbm \ --with-iconv \ --enable-ftp \ --with-gettext \ --enable-mbstring \ --enable-shmop \ --enable-sockets \ --enable-wddx \ --with-libxml-dir=/usr \ --with-xsl=/usr \ --with-zlib \ --with-openssl=/usr \ --enable-zip
The Server API Ham and Cheese ?
External Links
cpan.org/dist/PHP-Interpreter/lib/PHP/Interpreter.pm
http://www.perlmonks.org/?node_id=612502
http://search.cpan.org/src/GSCHLOSS/PHP-Interpreter-1.0.1/README
Yes I’ve got more:
Does mod_deflate cause problems with memory expansion? I *think* its due to Apache claiming small bits of memory, which would eventually level off. Using GTop, I see the Apache process add about 20kb of memory usage every request. If I turn off compression, it goes away. Yeh - I guess it has to do with how the output streams out of Apache. If the deflate output filter doesn’t know how much data is coming, its going to add a little more, just in case its needed. By turning off (aka disable) output buffering in the perl output handler, the deflate filter knows ahead of time how much memory it will need, and if it needs to allocate some more. I am doing this using the following method:
sub handler { $| = 0; my $r = shift; my $output; ... }
Hmmm, tested that again, the memory still bumps up a little each request. Meh, so I turned off compression, and am now using nginx as a reverse proxy to compress the content:
25013 www-data 15 0 4968 1420 700 S 0.0 0.1 0:00.17 nginx 25544 www-data 15 0 42384 25m 532 S 0.0 2.6 0:00.00 apache2 25545 www-data 18 0 68024 30m 5592 S 0.0 3.2 0:01.88 apache2 25587 www-data 15 0 68480 31m 5592 S 0.0 3.2 0:01.03 apache2
Oh yes, and of course I have varnish setup in front of nginx to cache content too.
Good stuff:
* use strict;
* use warnings;
* Running apache as a single process is helpful for identifying memory leaks with gtop.
Surprise:
Nginx is very efficient. Good.
Latest Comments
RSS