>
> >Another question: Did you use Embperl::Object? Embperl::Object currently
> >does some more stat calls then necessary, which slows it down. That is
> >something that I like to optimize before the final 2.0 release.
>
> No, I just did a "use Embperl" and set the handler for all .emb2
> pages. Will this matter one way or the other?
>
Embperl::Object does some extra work (search for files, setup @ISA etc.), so
it will make things slower . Since you don't get this extra work with the
other systems, it wouldn't have been fair to use it in this comparison.
> <snip talk about Apache 2.0>
>
> As much as I would love to switch to Apache 2.0, I don't think it
> will gain us much. We use (or should I say we are stuck with)
> FreeBSD and the thread support is ... well ... not there.
Ok, so this is no way to go...
There is one thing which could be done with Apache 1.3 that goes in the same
direction, also it doesn't save as much memory as using threads. You could
preload and precompile the pages for Embperl 2.0 in the parent process. As
long as no writing to these memory locations takes place, the memory will be
shared between all child processes. Also the child process seems to use the
same amount of virtual memory, they actually takes up less phycial memory.
To do this, create a startup.pl and include it with
PerlRequire startup.pl
in your httpd.conf, in the startup.pl say
use Embperl ;
Embperl::Execute ({inputfile => 'file1.emb2', import => 0}) ;
Embperl::Execute ({inputfile => 'file2.emb2', import => 0}) ;
Embperl::Execute ({inputfile => 'file3.emb2', import => 0}) ;
....
Load all the files you use in this way. I can't exactly say how much this
will reduce the overall memory useage (because it highly depends on the
content of your files), but it's really worth a try.
Another note: I have wondered why the numbers of Embperl 2.0 goes so much
down at 400 concurrent requests compared to Mason and found that there is a
small memory leak in b7. This memory leak sums up at the high number of
concurrent requests. Of course I will fix this memory leak and then we could
expect better numbers at high concurrentcy level.
>
> Looking at the afterburner code (another PHP Accelerator) all it does
> is copy the internal PHP compile function, and change it with it's
> own. What the new compile function does it check in the cache to see
> if it is already compile, if so check the timestamp, return the
> cached compiled code or compile it, save it in the cache and return
> it. It is amazing that at 100+ concurrent connections it doubles the
> request per second compared with no cache.
>
Ok, Embperl does this already (otherwise it would use less memory), so
nothing we can do here
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]
