Hi Neil,
I think what you are doing is correct. I guess the problem is that Perl is
storing it's compiled code and data in the same memory pages, so when the
data gets modified, the code isn't also shared anymore. Embperl 2.0 may
behave better, because it compiled all the code as whole chunck, so it's
less likely that code and data gets mixed up in the same memory page.
Maybe you gain a little memory by limitied the requests per childs (e.g. to
100). Since you already have compiled the perl code in the parent, a child
startup should not cost to much.
>
> First of all, I had to change my EmbperlObject files to enable preloading
(using
> 1.3.4). The problem lay in lines like this, which are at the start of
every
> subroutine module:
>
> [! Execute ({isa => '../Journal.epl'}) !]
>
> I found that I had to change this to an absolute path, like this:
>
> [! Execute ({isa => '/full/path/to/parent/Journal.epl'}) !]
>
> Is this because EmbperlObject uses the filename given in Execute as a key
to
> some kind of internal hash?
>
Embperl object sets up a search path. You can do the same for your
preloading with the path parameter.
> I
> wonder if Apache 2.x will handle this any better with threads. No idea how
all
> that works on Linux...
Apache/mod_perl 2.0 use Perl's ithreads, there Perl will take care to
separate data and code and Perl will make sure to share the code among all
threads. I expected it to be a great inprovement in memory uitlization
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
