[ic] Which is best for performance/functionality mod_interchange or interchange under mod_perl

Jeff Dafoe interchange-users@icdevgroup.org
Wed Oct 23 22:20:01 2002


> It isn't a problem to have them big -- as long as you are not swapping,
> the overhead comes when they fork (and even then it is not that bad with
> any modern OS that has copy on write).
>
> With memory being the way it is these days, a few megabytes here and there
> doesn't cause problems unless there are lots of page faults.

    I have been able to get servers equipped with 2 GB of RAM to swap
readily when using a reasonably sized script (IC sized) under modperl even
though the script was specifically written for modperl from the start.  The
system was a perl CMS that processed templates.  The per-process size never
grew above 25 megs, but after less than 10 dynamic page requests so many
page faults had occurred that the majority of that memory became "unshared".
We were easily able to get swapping to occur with only 75 concurrent apache
processes.  We ended up setting MaxRequestsPerProcess to 3 in order to
maximize the number of concurrent requests the system could handle.
    We never had the opportunity to determine exactly why this was
occurring, I suspect it had something to do with the way memory is allocated
and freed within modperl.  The rapid unsharing of memory in modperl
processes has been documented by a couple of other people as well, with no
readily-accessible explanation available.

    While we are on the topic of performance, what are the thoughts on sql
versus text when doing product scans?  I know on a well-memoried system (I
have 2GB) that serious read caching occurs.  I also use postgresql, which
has never been a real speed daemon.  This makes me think that using "text"
for scans of the product database might actually occur faster than a sql
scan.


Jeff