You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Brian France <li...@firehawksystems.com> on 2002/04/18 22:03:41 UTC
Performance numbers, HELP!
Hello,
I am part of a small group of engineers that is looking in to
replacing our current proprietary template technology. We are
looking at mod_perl with some template layers and PHP. I have been
using Embperl since the early days (before 0.20-beta) and would love
to use it, but the performance numbers are just not there. Here is
what the group has found:
Test Server:
P3 800Mhz
512Meg Ram
FreeBSD 4.3
Apache 1.3.19 (Complied options listed below)
PPT: Proprietary template technology DSO
PHP: PHP 4.1.2 DSO with php_accelerator
ASP: mod_perl 1.26 DSO with Apache::ASP 2.31
MAS: mod_perl 1.26 DSO with HTML::Mason 1.04
EMB: mod_perl 1.26 DSO with HTML::Embperl 1.3.4
SSP: mod_perl 1.26 DSO with SimpleASP
SimpleASP is a very simple perl module that handles ASP syntax (it
was written in a day). It turns the page into a function call,
printing anything not between <% %> tags and evaluates the stuff that
is.
We ran 6 different test configurations. Only loading the testing
DSO's. Each of the mod_perl configurations had a separate startup.pl
file that loaded the standard Apache packages, the testing template
package and the 2 perl packages needed for the test page (See below).
Each test requested a page written in the native language which was
about 33K and about 41K after rendering.
The test runs were as follows.
Server Warm up: 10,000 requests at 25 concurrent connections
Test 1: 20,000 requests at 25 concurrent connections
Test 2: 20,000 requests at 50 concurrent connections
Test 3: 20,000 requests at 75 concurrent connections
Test 4: 20,000 requests at 100 concurrent connections
Test 5: 20,000 requests at 150 concurrent connections
Test 6: 20,000 requests at 200 concurrent connections
Test 7: 20,000 requests at 300 concurrent connections
Test 8: 20,000 requests at 400 concurrent connections
Here are the results:
025 050 075 100 150 200 300 400
---------------------------------------------
PTT: 059 117 172 207 220 208 199 200
PHP: 060 118 173 211 235 252 249 241
ASP: 039 042 051 ** *** *** *** ***
MAS: 058 102 119 121 116 108 * ***
EMB: 040 040 039 039 028 026 * ***
SSP: 060 118 172 218 246 268 277 277
---------------------------------------------
MAX: 062 125 187 250 294 294 294 294
MAX: This is the max possible. There is a 400ms delay in one of the
"PROPRIETARY TEST MODULE" which simulates a delay of back end servers
that would supply data. Max of 294 is the calculated max due to a
network bandwidth limit.
* was not run, don't know why
** test skipped because melted the box and needed a reboot
*** test skipped because last test failed
Any idea on what is going on and why the Embperl numbers are so low?
I added debugging to make sure the pages were being cached and after
the warm up the all showed 100% cache hits. The surprise to the
group was the SPP numbers and how it out performed them all.
Side Note: I wanted to try to use Embperl 2.0, but I couldn't get it
to compile and didn't have the time to spend on it.
Let me know if you need any more info or have any ideas on what to
try. I still have the test machines setup and can tweak a few things
and run the tests again.
Thanks,
Brian
--------------------------------------------------
Other Data:
Trust me all changes or compiled in modules that are listed as
PROPRIETARY do no effect the server performance in a bad way.
Server compiled with....
-D EAPI
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D NO_LINGCLOSE
-D USE_FLOCK_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D <PROPRIETARY>
-D GZIP
-D HTTPD_ROOT="<REMOVED>"
-D SUEXEC_BIN="<REMOVED>"
-D DEFAULT_PIDLOG="<REMOVED>"
-D DEFAULT_SCOREBOARD="<REMOVED>"
-D DEFAULT_LOCKFILE="<REMOVED>"
-D DEFAULT_XFERLOG="<REMOVED>"
-D DEFAULT_ERRORLOG="<REMOVED>"
-D TYPES_CONFIG_FILE="<REMOVED>"
-D SERVER_CONFIG_FILE="<REMOVED>"
-D ACCESS_CONFIG_FILE="<REMOVED>"
-D RESOURCE_CONFIG_FILE="<REMOVED>"
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_info.c
mod_status.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_expires.c
mod_headers.c
mod_so.c
mod_setenvif.c
mod_<PROPRIETARY>.c
mod_<PROPRIETARY>.c
mod_<PROPRIETARY>.c
mod_<PROPRIETARY>.c
mod_<PROPRIETARY>.c
mod_<PROPRIETARY>.c
mod_ssl.c
server.conf: Everything else was set to Apache defaults but:
Port 80
HostnameLookups Off
KeepAlive Off
KeepAliveTimeout 0
test.conf
---------------------------------------------
LoadModule perl_module <REMOVED>libperl.so
PerlSetupEnv Off
PerlTaintCheck Off
PerlWarn Off
SetEnv EMBPERL_DEBUG 0
SetEnv EMBPERL_OPTIONS 16
SetEnv EMBPERL_ESCMODE 0
SetEnv EMBPERL_LOG /tmp/embperl.log
PerlRequire "<REMOVE>/conf.test/startup-embperl.pl"
<Files "*.emb">
SetHandler "perl-script"
PerlHandler HTML::Embperl
DefaultType text/html
</Files>
starup.pl Embperl Session management DISABLED becuase I don't have
the Apache::SessionX.pm installed
---------------------------------------------
#!/usr/bin/perl
use Apache;
use Apache::Status;
use Apache::Registry;
use Apache::Constants;
use HTML::Embperl;
use lib '<REMOVED>';
use <PROPRIETARY TEST MODULE>;
use <PROPRIETARY TEST MODULE>;
1;
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Gerald Richter <ri...@ecos.de>.
>
> >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: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Brian France <li...@firehawksystems.com>.
At 3:16 PM +0200 4/20/02, Gerald Richter wrote:
>That are really a lot of hits...
Do you ah, Yahoo! :-)
>Did you use any cacheing of the output with Mason and/or Embperl?
Yes for Embperl, but I don't know for Mason. That was the first time
I had installed Mason and used it.
>If for
>examples headers or footers are more or less static Mason and Embperl are
>able to cache the generated output, so the Perl code has to be run only
>once. If the header and/or footer is a really static page, then you should
>use the syntax "Text" in Embperl 2,this will speed things up again and
>Embperl 2 use a concept of providers, so it is very simple possible to write
>a pure text provider which will speed up inclusion of static files even
>more, because no Perl code will be involved anymore.
Yes, the pages were static, but we wanted to make sure they were
evaluated because not all of our included pages are static. Most of
them are dynamic as well.
>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?
<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. I am sure
we will be switching to 2.0 eventually, but I don't think it will
happen any time soon. We have some deep modifications in 1.3 right
now which makes it hard to keep up with that version.
>P.S.S. Do you know what the PHP Accelerator does? Does it some kind of
>output caching? I am not a PHP guru, so I have to ask. If it is some kind of
>caching, maybe we can do a similar thing for Embperl?
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.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Gerald Richter <ri...@ecos.de>.
>
> For me these numbers are great and I plan on moving to 2.0 as soon as
> I can for my personal stuff. This works for me because I am only
> getting about 1 *request* per second, but at work we need to be able
> to deal with on average 18750 *page views* per second (1.62 billion
> page views per day on average). Of course this is spread across
> multiple machines, but you also need to take into consideration the
> number of machines needed, cost of machines, cost to maintain the
> software on all those machines, etc.
>
That are really a lot of hits...
Did you use any cacheing of the output with Mason and/or Embperl? If for
examples headers or footers are more or less static Mason and Embperl are
able to cache the generated output, so the Perl code has to be run only
once. If the header and/or footer is a really static page, then you should
use the syntax "Text" in Embperl 2,this will speed things up again and
Embperl 2 use a concept of providers, so it is very simple possible to write
a pure text provider which will speed up inclusion of static files even
more, because no Perl code will be involved anymore.
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.
As you say the slow down for more concurrent connections, is because of the
memory usage. Perl itself uses a lot of memory, so all Perl based solutions
will need more memory. Embperl uses some more memory than Mason, to provide
features like auto form fill, dynamic tables etc. The main point to consider
here is Apache 2.0 and mod_perl 2.0. The problem with Apache 1 is, that
every concurrent connection uses it's own Apache process, so every
connection needs the same amount of memory. With Apache 2.0 you can run it
as threads, where the threads share the memory that the Perl code takes up.
If correct configured this will safe very much memory.
Basicly PHP and Perl solutions are about the same speed at 25 concurrent
connections. At this number of concurrent connections, the memory isn't a
factor, because there is enough memory to hold all 25 processes in physical
memory. So as the concurrent connections increases at some point the machine
runs out of physical memory and beginns to swap. As you already mentioned
that's the reason why Perl solution doesn't scale so well, but if we
consider Apache 2.0, which will reduce the memory footprint, the Perl
solutions may come into play again.
Apache 2.0 is finaly released some weeks ago, mod_perl release candidate is
currently under heavy testing. One part of the improvement from b5 to b6 of
Embperl was to make the internal data strcuture ready for Apache/mod_perl
2.0 and threading. Embperl currently doesn't compile with Apache 2.0, but if
necessary we could get this working in a short time frame.
You say you personaly prefer Embperl, but PHP is faster for now. As you
surely know, you not only have to consider performance, but also how much
effort it takes to write and maintain an application. Of course when you
have so much hits, performance is a really important, but if you feel
Perl/Embperl is better for writing your application and if we could get
nearly the same performance with using Apache 2.0 threads, then maybe using
Embperl is a possibility again?
As I said Embperl currently not compiles with Apache 2.0 and I have put a
lot of time into the changes from b5 to b6, so for now I have to do some
other jobs to earn some money, before I can again put some more time into
Embperl.
But in case you would like to use Embperl and Apache 2.0 and need it in a
short time frame, I can offer you to do it as a consulting job for you. In
this case you we could get it working quickly. (there are also some other
optimizations which could be done, but this will not have the same amount of
improvment as using threads)
Gerald
P.S. I happy that you like Embperl and use it already for such a long time
:-)
P.S.S. Do you know what the PHP Accelerator does? Does it some kind of
output caching? I am not a PHP guru, so I have to ask. If it is some kind of
caching, maybe we can do a similar thing for Embperl?
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Brian France <li...@firehawksystems.com>.
At 9:39 PM -0400 4/19/02, Cameron McBride wrote:
>Perhaps this is an obvious note that you caught, but you mentioned
>turning on debugging. You didn't do this for the *actual* test, did
>you? I understand that would have a performace effect. (you
>probably didn't, but I just thought I would mention it)
Yes debug was off for the test, but I ran a few before the test with
it on to make sure it was caching.
>Another question -- what exactly did you have each of the
>scripts doing?
The test file would include/execute 3 other files (header, footer,
common section). 2 calls were made into our C/C++ code. Perl module
wrappers were written for the mod_perl test and php to C/C++
extensions were written for the PHP test. One call was a simple
string input, mangled in C/C++ and then displayed. The other call
created a multi-level hash in C/C++ then copied into the native
language (perl/PHP), then displayed it. This call also had a 400ms
delay which was to simulate back end server delay, this is were the
lower Max limit comes in (25/.4=62.5).
> I examined a few of those packages you benchmarked
>recently, and it seems they had very different strengths and
>weaknesses. They each developed to fill a slightly different niche.
>I imagine such a rigorous performance test would be biased on what
>exactly you asked them to do for it.
> Perhaps I am mistaken, and if so
>-- please enlighten me! ;-)
This is true. Our test page was setup to simulate the most common
things we do (calls to our C/C++ code and servers).
>One thing I found slightly disturbing, was the high ranking of PHP
>numbers to the perl solutions. I imagined that PHP might win, as it
>is a web based option *designed* to be a web scripting language from the
>ground up -- but I did not expect such a large difference in numbers.
Trust me, I feel the same way, but I have run the test multiple times
and get the same numbers. Just to make sure you know that the PHP
setup was with PHP Accelerator (http://www.php-accelerator.co.uk/).
Two numbers that were recorded during the tests were idle times and
virtual active memory. I only have those numbers for the PPT, PHP
and SSP test, but what they showed were interesting. Our current
proprietary technology used far less memory than PHP or mod_perl/SSP.
PHP was in the middle for memory usage and mod_perl/SSP used *a lot*
of memory. I believe the low numbers for Embperl after 100-150
current connections is because it runs low on memory and start
swapping. This can be fixed by adding more memory, but this test
server is close to *thousands* of boxes were have in production.
I have run two more test for PHP, one with no caching and one with
the Zend Optimizer at optimization_level=15. The Zend Optimizer
doesn't help one bit, look at the numbers.
PPT: Proprietary template technology DSO
N-PHP: PHP 4.1.2 DSO with no caching
O-PHP: PHP 4.1.2 DSO with Zend Optimizer (level=15)
A-PHP: PHP 4.1.2 DSO with PHP Accelerator
ASP: mod_perl 1.26 DSO with Apache::ASP 2.31
MAS: mod_perl 1.26 DSO with HTML::Mason 1.04
EM2: mod_perl 1.26 DSO with Embperl 2.0b7
EMB: mod_perl 1.26 DSO with HTML::Embperl 1.3.4
SSP: mod_perl 1.26 DSO with SimpleASP
025 050 075 100 150 200 300 400 concurrent connections
---------------------------------------------
PTT: 059 117 172 207 220 208 199 200 requests per second
N-PHP: 059 098 110 110 110 110 109 107 requests per second
O-PHP: 058 096 107 106 107 106 106 106 requests per second
A-PHP: 060 118 173 211 235 252 249 241 requests per second
ASP: 039 042 051 ** *** *** *** *** requests per second
MAS: 057 098 114 114 108 094 067 064 requests per second
EM2: 057 095 101 095 099 089 056 030 requests per second
EMB: 040 040 039 039 028 026 * *** requests per second
SSP: 060 118 172 218 246 268 277 277 requests per second
---------------------------------------------
MAX: 062 125 187 250 294 294 294 294 Max concurrent connections
>I also want to thank you Brian, such a test was very interesting and thought
>provoking.
Thanks!
>Cameron
>
>PS -- Richter: *I* still think Embperl is the best. ;-)
I second that!! I took one file and tried to write it in PHP and it
took 52 lines of code to do what I did in 25 with Embperl, I am
sticking with Embperl!
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Cameron McBride <ca...@cwru.edu>.
> > At 8:19 PM -0400 4/19/02, Marcus Doemling wrote:
> >What unit are your performance numbers? I was wondering what
> >these numbers reflect and how they are measured.
> The top label numbers are the concurrent connections test and the
> data number are how many request per second the machine could output.
> All the test were done with Apache Benchmark.
>
> Brian
Thanks Marcus, I was actually wondering the same thing!
Brian,
Perhaps this is an obvious note that you caught, but you mentioned
turning on debugging. You didn't do this for the *actual* test, did
you? I understand that would have a performace effect. (you
probably didn't, but I just thought I would mention it)
Another question -- what exactly did you have each of the
scripts doing? I examined a few of those packages you benchmarked
recently, and it seems they had very different strengths and
weaknesses. They each developed to fill a slightly different niche.
I imagine such a rigorous performance test would be biased on what
exactly you asked them to do for it. Perhaps I am mistaken, and if so
-- please enlighten me! ;-)
One thing I found slightly disturbing, was the high ranking of PHP
numbers to the perl solutions. I imagined that PHP might win, as it
is a web based option *designed* to be a web scripting language from the
ground up -- but I did not expect such a large difference in numbers.
I also want to thank you Brian, such a test was very interesting and thought
provoking.
Cameron
PS -- Richter: *I* still think Embperl is the best. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Brian France <li...@firehawksystems.com>.
Hi Marcus,
The top label numbers are the concurrent connections test and the
data number are how many request per second the machine could output.
All the test were done with Apache Benchmark.
Brian
At 8:19 PM -0400 4/19/02, Marcus Doemling wrote:
>What unit are your performance numbers? I was wondering what
>these numbers reflect and how they are measured.
>
>Thanks,
>Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Marcus Doemling <ma...@fysix.com>.
What unit are your performance numbers? I was wondering what
these numbers reflect and how they are measured.
Thanks,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Brian France <li...@firehawksystems.com>.
Hi,
At 5:37 AM +0200 4/19/02, Gerald Richter wrote:
> > Any idea on what is going on and why the Embperl numbers are so low?
>> I added debugging to make sure the pages were being cached and after
>> the warm up the all showed 100% cache hits. The surprise to the
> > group was the SPP numbers and how it out performed them all.
>
>Of course a simple module is faster than a more complex, but when you use it
>you find yourself adding all these features that the more complex ones
>already have and at the end your resulting application will not be much
>faster, but you spend much more time developing it.
I completely agree. The SPP was done to see the difference between
the more mature template systems and a plain striped down one.
> > Side Note: I wanted to try to use Embperl 2.0, but I couldn't get it
> > to compile and didn't have the time to spend on it.
>
>If you really want to benchmark, you should use 2.0! 2.0 is much faster then
>1.3.4. Make sure you use 2.0b7 which is even faster then b5. You can install
>1.3.4 and 2.0b7 at then same time, so you can run your benchmark with both
>modules. I would like to see a comparison of the two, that is not made by
>myself. Anyway if you start a new project, you should build on top of 2.0
>and not 1.3.4, because 2.0 is not only faster, but also has much more
>possibilities.
>
>Tell me what trouble you have with compiling and we will find what's ging
>wrong.
I took some time and went back and got 2.0b7 installed and ran the
test for it and here are the numbers again. EM2 : Embperl-2.0b7. I
also re-ran the Mason test as it was not doing the right thing to
included files. It was just printing the contents of the 3 files
instead of executing them and displaying the contents. This made the
numbers closer to Embperl.
025 050 075 100 150 200 300 400
---------------------------------------------
PTT: 059 117 172 207 220 208 199 200
PHP: 060 118 173 211 235 252 249 241
ASP: 039 042 051 ** *** *** *** ***
MAS: 057 098 114 114 108 094 067 064
EM2: 057 095 101 095 099 089 056 030
EMB: 040 040 039 039 028 026 * ***
SSP: 060 118 172 218 246 268 277 277
---------------------------------------------
MAX: 062 125 187 250 294 294 294 294
For me these numbers are great and I plan on moving to 2.0 as soon as
I can for my personal stuff. This works for me because I am only
getting about 1 *request* per second, but at work we need to be able
to deal with on average 18750 *page views* per second (1.62 billion
page views per day on average). Of course this is spread across
multiple machines, but you also need to take into consideration the
number of machines needed, cost of machines, cost to maintain the
software on all those machines, etc.
Gerald I just want to say that I think you have created a GREAT thing
with Embperl and I will always continue to use it. The whole point
of the message was not to slam Embperl, but making sure I wasn't
missing something in the configuration with mod_perl or Embperl.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Performance numbers, HELP!
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
> Any idea on what is going on and why the Embperl numbers are so low?
> I added debugging to make sure the pages were being cached and after
> the warm up the all showed 100% cache hits. The surprise to the
> group was the SPP numbers and how it out performed them all.
>
Of course a simple module is faster than a more complex, but when you use it
you find yourself adding all these features that the more complex ones
already have and at the end your resulting application will not be much
faster, but you spend much more time developing it.
> Side Note: I wanted to try to use Embperl 2.0, but I couldn't get it
> to compile and didn't have the time to spend on it.
>
If you really want to benchmark, you should use 2.0! 2.0 is much faster then
1.3.4. Make sure you use 2.0b7 which is even faster then b5. You can install
1.3.4 and 2.0b7 at then same time, so you can run your benchmark with both
modules. I would like to see a comparison of the two, that is not made by
myself. Anyway if you start a new project, you should build on top of 2.0
and not 1.3.4, because 2.0 is not only faster, but also has much more
possibilities.
Tell me what trouble you have with compiling and we will find what's ging
wrong.
> Let me know if you need any more info or have any ideas on what to
> try. I still have the test machines setup and can tweak a few things
> and run the tests again.
>
If you really want to speed up 1.3.4 you have to disable the features that
other modules not provide and set
optDisableCleanup
optDisableChdir
optDisableHtmlScan
SetEnv EMBPERL_OPTIONS 657
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org