Torsten Foertsch wrote:
These figures match my observations. It also means that you are not using big
content generators in the response phase like Catalyst.
Correct. Response content is generated by backend servers, which is then
delivered to clients either from the local cache, or via mod_proxy.
Did you know this little trick?
In PostReadRequest or so:
$r->pnotes->{xp}=$r->pool->new;
$r->push_handlers(PerlFixupHandler=>sub {delete $_[0]->pnotes->{xp}; 0});
No, I did not. Thanks. I'm not sure if I want to (or even need to) use
it though, but it's definitely good to have as an option. Even if it is
hackish :)
Did you know that you can even share data between Perl interpreters by
using "threads" and "threads::shared"?
I'm assuming that this will only work for interpreters inside the same
child process? If so, then I don't see that much use for it. If on the
other hand it would work globally across all interpreters, I might have
some use for it.
already in the parent process before it forks. I am thinking of a patch to
implement this. But it would mean to abandon growing and shrinking of the
interpreter pool and the limit of requests per interpreter. But in the end I
think it would be more reasonable than it is now.
This would be perfect in my use case. I don't need to grow or shrink the
interpreter pool, and limiting the number of requests shouldn't be
needed either - the limit can be set on the apache process side. If you
come up with a patch for this, I'd be happy to give it a try!
Cheers,
-- Jani
