perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew O'Brien" <>
Subject RE: Problem using Embperl on Debian Lenny
Date Wed, 16 Jul 2008 02:44:46 GMT

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

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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message