On Jun 30, 2007, at 2:40 AM, Tony van der Hoff wrote:
Well, it is my intention that the modules should be reloaded if
they've
changed; that's the whole point of using Apache::Reload, so I'm
pleased it
works. Presumably, if they haven't changed, the only performance
hit is a
stat to the file system, and then only on those modules which
explicitly
call Apache::Reload. I think I can live with that :)
Thats the intention of the devel environment. But aside from the
performance hit, reload doesn't work perfectly. some module changes
won't get picked up due to class override / superclass conflicts,
other changes will cause Reload to just crash your server. when
you're running reload, you're ideally having the stat and a clean
reload -- in practice you can get larger performance hits from the
stat being read wrong and tons of crashes.
However, without the ability to restart the server, and short of
renaming
the files, how should I update my software? It won't happen much at
the
production end, but it will certainly happen. Shouting Never,
Never, Never
is all very well, and undoubtedly good advice, but it's a bit
impractical
without an alternative.
assuming you're on a nix/bsd -- you need to be able to restart the
server. if you can't , then you shouldn't be using mod_perl. see
if you can run apache on a port you can control, then proxypass to it.
mod_perl does a lot of performance/memory optimizations by using the
copy-on-write model for vars and caching compiled subs. when you
'reload' code, you're just redefining the subs... which means they
get unshared.
illustration
start parent-a
fork child-a child-a child-a
update code
reload
child-a child-a child-b
child-a child-b child-b
child-b child-b child-b
i'm not sure how reload affects the master-process memory-- but I
have a funny feeling that new children will spawn with the pre-update
code, then stat to the new code
What are the other problems you refer to? I've been lurking on this
list for
some months, but have not seen anything mentioned, and Google
doesn't throw
up anything on the first few pages.
look back within the past 18-6 months. there was a lot of reload
talk then. not as much lately.
also, you should never do an apachectl restart/graceful.
you want to do a full apache stop, and then apache start. the
integrated restart command will essentially cause a memory leak ( its
not really leaking, but the memory isn't recycled/overwrriten -- so
your process will double on size the first restart, etc etc etc )
On Jun 30, 2007, at 6:13 AM, Clinton Gormley wrote:
With regards using Apache::Reload in production, my understanding is
that, while Apache::Reload is really useful for development, there are
edge cases where things get messed up, and which require a stop-
start to
get them working again. And for this reason, we would not usually
consider using this module in production.
its much less edge-cases than it is use-cases.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
