At 01:44 AM 4/20/00 +0300, Stas Bekman wrote:
>On Wed, 19 Apr 2000, Gerd Knops wrote:
>
> > Stas Bekman wrote:
> > > On Wed, 19 Apr 2000, Matt Carothers wrote:
> > > > On Tue, 18 Apr 2000, Stas Bekman wrote:
> > > >
> > > > > Let's assume that you have two different sets of scripts/code
> > > > > which have a little or nothing in common at all (different
> > > > > modules, no base code sharing), the basic mod_perl process
> > > > > before the code have been loaded of three Mbytes and each code
> > > > > base adds ten Mbytes when loaded. Which makes each process 23Mb
> > > > > in size when all the code gets loaded.
> > > >
> > > > Can't you share most of that 23mb between the processes by
> > > > pre-loading the scripts/modules in your startup.pl? I'd say the
> > > > main advantage of engineering dissimilar services as if they were
> > > > on separate servers is scalability rather than memory use. When a
> > > > site outgrows the hardware it's on, spreading it out to multiple
> > > > machines requires a lot less ankle grabbing if it was designed
> > > > that way to begin with. :)
> > >
> > > Geez, I always forget something :(
> > >
> > > You are right. I forgot to mention that this was a scenario for the
> > > 23 Mb of unshared memory. I just wanted to give an example. Still
> > > somehow I'm almost sure that there are servers where even with
> > > sharing in place, the hypothetical scenario I've presented is quite
> > > possible.
> > >
> > > Anyway, it's just another patent for squeezing some more juice from
> > > your hardware without upgrading it.
> > >
> > > But, sure I'll add the correction about the sharing memory which
> > > drastically changes the story :)
> > >
> > Actually in my experience the sharing of memory doesn't work as well
> > as one would hope. While compiling perl allocates memory for code
> > and data (variables) from the same memory pools, so code and
> > variables are interlaced. Over the lifetime of a apache/mod_perl
> > child a lot of memory pages are promoted from shared to unshared that
> > contain mostly code and one or two variables... If someone with more
> > knowledge of the perl internals were to change that, this would make
> > a huge difference for mod_perl users and everybody else writing
> > daemons in perl that spawn many children.
>
>The Perl is a language that uses weak data types, i.e. you don't specify
>variable size (type) like you do in the strong typed languages like C.
>Therefore Perl uses heap memory by allocating memory on demand, rather
>(unmodifiable) text and (modifiable) data memory pages, used by C. The
>latter get allocated when the program is loaded into memory before it
>starts to run, the former is allocated at the run-time.
>
>On heap there is no separation for data and text pages, when you call
>malloc it just allocates you a chunk you have asked for, this leads to the
>case where the code (static in most cases) and the variables (dynamic)
>land on the same memory pages.
>
>I'm not sure this a very good explanation. Perl gurus are very welcome to
>correct/improve my attempt to explain this.
>
>But the main point is that that's how Perl is written, and I don't know
>whether it can be changed.
That's how I understand it to be. But I could be wrong as well. :)
By the way, I think your section here is actually far-thinking. Although
Matt and others have pointed out that this scenario may not be the biggest
memory booster in the world in some cases, there is another consideration
that I think should be mentioned.
Reliability and Troubleshooting.
Right now, I dare say that most of you probably either are doing custom
mod_perl coding or are using an infrastructural tools such as EmbPerl, ASP
etc...
In these scenarios, it is relatively easy to troubleshoot your code because
you either [a] wrote it all or [b] you are running code on top of a
well-tested Apache::Mod_perl infrastructural application toolkit.
This is, I suspect, because as far as real-world open source applications
are concerned, mod_perl is a bit behind. Thousands of open source CGI
scripts exist in Perl for plain CGI. Few (if any) are in a repository to
work with mod_perl off the bat.
However, I see this changing. Efforts such as mine, SmartWorker's etc...
will eventually lead to a proliferation of another layer of infrastructural
component which is above the Tool level (EmbPerl/Apache::Session/etc). In
other words, a component level that is at the application level -- plug and
play calendars, bbses, web shopping carts, etc.
If people reach this point on mod_perl, you may find that some modules are
not written as well as others and so subtle side effects may be introduced
when you start throwing everyone's code together in one huge vat of mod_perl.
If this happens, I suspect it will be a lot easier to troubleshoot problems
that occur if you keep major application suites separate from each other.
eg Don't run SmartWorker on the same server as EmbPerl or the same server
as Extropia stuff etc... Because although it may work in the short-term...
you may end up pulling your hair out if someone ends up changing something
somewhere that causes a chain reaction for the other toolkit.
In addition, when you use tools to troubleshoot an App and check out the
state of other modules that are loaded (like Perl-Status), it is likely to
be cleaner if you are just running your custom app instead of many apps
together when you are trying to trace something down.
Anyway, that's just my two cents. Could be wrong on this... But I didn't
see it emphasized before and I think it is a point that will become more
relevant as application suites for Mod_perl will start getting released on
top of the purely infrastructural components that exist now.
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
