Hi Neil, > There definitely seems to be some kind of problem with the current > binary Embperl package included with Lenny. All I did was > build Embperl > from the Debian source (using the standard build procedure, > rather than > the "debian way") and everything "just worked". No changes to the > config. Very strange! Oh well, at least it works now, which > is a relief.
I can only guess at some helper library missing or perl library versioning problem. The apt-get build-dep process should have fixed you right up there. Shrug. Worked for me on my dev VM this morning. Happy to work through debian-isms off-list if you would like. > What is your experience of Lenny's stability with respect to software > updates? I hear they are entering a freeze soon. On the one hand, I > would think that must mean that it must be pretty stable, but on the > other hand someone commented that you sometimes see a flurry > of hurried > (and sometimes unwise) updates checked in to beat the freeze. Are you > running it on a production server? Currently, I'm planning on > installing > Lenny on my server this Wednesday, just biting the bullet and > upgrading > everything. I've been running Apache 1.3, mod_perl 1 and > Embperl 1.3 for > the last eight years or so, but when I tried installing that > on Lenny it > seemed to break - maybe perl 5.10 or something. This is what made me > consider the sweeping upgrade... should be easier to just live in the > apt-get world, too. We are running debian Lenny in production but it doesn't have any sort of automatic updating in place. We have a mirror system that we develop/deploy to and test all dist-upgrades there before deciding things are safe enough for prod. I would build up a debian lenny VM and get the site working there first before attempting a live upgrade like that. Better would be to build up a VM working with your current debian version and do your dist-upgrade testing on that so you can note down any problems that may arise during the upgrade process. That said, about 6 months ago we did the same thing (one machine was even a debian woody install - that's 3 major releases behind so we just rebuilt from scratch for that one). I posted a short script to the list a fair while back that goes through all embperl files and upgrades the syntax from 1.3 to 2.0-compliant (eg only one statement in a plus block, no trailing semicolon, round brackets required in foreach statements etc). Aside from changing the apache config files and finding a few places where I needed to put [$ syntax EmbperlBlocks $] to stop embperl choking on some funky table structures things went very smoothly. That particular site uses Embperl::Object quite heavily and its probably our most complex so I was pretty happy overall. > With my old apache setup, I had two builds (on the same > machine) working > as a back-end mod_perl, and a front-end lightweight reverse > proxy. I'm > wondering if I'll need to do that with Apache 2.2; it seems > that it has > caching built in, so maybe no need to proxy for performance. The idea > was that I could run a lot more of the caching reverse proxy > instances > (since they use much less memory) and so with caching this > allowed me to > withstand several slashdottings without breaking a sweat. But if > everything is coming through the mod_perl apache, then I > won't be able > to run as many instances. I don't know how that will affect > performance > yet, it should be interesting. Have fun playing with it :) We don't bother caching at the output layer as so much of our display is dynamic and user-driven but I've implemented memcache for some parts of our DB query load and for throw-away sessions. I don't know how much site-specific complexity there is in your caching reverse proxy but maybe you want to look at Varnish for caching or perlbal/lighttpd instead of apache if you're worried about memory use. I know we regularly have apache children sitting at the 80MiB mark and it stacks up quick. Cheers, Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
