You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Alexander Hartmaier <Al...@t-systems.at> on 2002/04/16 08:57:43 UTC
Embperl 2.0b7 approx. 10 times slower than 1.3.x
Hi!
We use Embperl to generate dynamical pages for our router & switches bandwidth
statistics.
We poll them using snmp and store the data in an oracle database we access usind
dbi and dbd::oracle.
The "old" machine:
800Mhz PIII with 256MB ram
RedHat 6.2
Apache 1.3.19 with mod_perl 1.25 and embperl 1.3.1
The "new" machine:
866Mhz PIII with 256MB ram
RedHat 7.2
Apache 1.3.22 with mod_perl 1.26 and embperl 2.0b7
The slowest embperl script generates a html file which shows a selectable table.
I attached it here:
(See attached file: view-table.epl)
In this embperl logfile you see how long the script takes to run:
(See attached file: embperl.log)
I tried for one week to change apache settings and other things but the thing is
damn slow! Almost 1 minute for the biggest table which has ~2100 lines with 16
fields per line.
The httpd process on the "new" machine uses all available processor ressources
available for the whole time!
I hope you can help me!!!
THX Alex
Re: Embperl 2.0b7 approx. 10 times slower than 1.3.x
Posted by Wim Kerkhoff <wi...@nyetwork.org>.
On 16-Apr-2002 David Lloyd wrote:
>
> Alexander
>
>> The "old" machine:
>> 800Mhz PIII with 256MB ram
>> RedHat 6.2
>> Apache 1.3.19 with mod_perl 1.25 and embperl 1.3.1
>>
>> The "new" machine:
>> 866Mhz PIII with 256MB ram
>> RedHat 7.2
>> Apache 1.3.22 with mod_perl 1.26 and embperl 2.0b7
>>
>>
>> The slowest embperl script generates a html file which shows a selectable
>> table.
>
> Oh ext3 isn't killing postgres? Or it's not the updated postgres? Or
> it's not the crappy kernel (2.4.X) series with VM problems?
I'm not familiar with the RedHat releases, but I doubt it's one of these.
Kernel 2.4.18 is mostly fixed, and the Postgres 7.2 is faster then 6.4 and 7.0.
One would think it's not an issue with the filesystem (whether it be ext3 or
ReiserFS or whatever), since the data should be cached.
Other things to check are the indexes on the table, PostgreSQL optimizations
(/etc/postgresql/postgresql.conf), and other standard things.
> How can you be SURE it's embperl? Try going back to 1.3.1 and seeing
> whether that actually changes things...6.2 is a LOT different to 7.2.
On the 'new' machine, install 1.3.1, keeping everything else the same. 1.3.1
and 2.0b7 use different namespaces (HTML::Embperl:: and Embperl::), and will
happily co-exist. I'm doing it on my lowly server and it's quite happy.
Regards,
Wim Kerkhoff -|- www.nyetwork.org -|- wim@nyetwork.org
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl 2.0b7 approx. 10 times slower than 1.3.x
Posted by David Lloyd <ll...@rebel.net.au>.
Alexander
> The "old" machine:
> 800Mhz PIII with 256MB ram
> RedHat 6.2
> Apache 1.3.19 with mod_perl 1.25 and embperl 1.3.1
>
> The "new" machine:
> 866Mhz PIII with 256MB ram
> RedHat 7.2
> Apache 1.3.22 with mod_perl 1.26 and embperl 2.0b7
>
>
> The slowest embperl script generates a html file which shows a selectable table.
Oh ext3 isn't killing postgres? Or it's not the updated postgres? Or
it's not the crappy kernel (2.4.X) series with VM problems?
How can you be SURE it's embperl? Try going back to 1.3.1 and seeing
whether that actually changes things...6.2 is a LOT different to 7.2.
DSL
--
On this day, this day of wrath
All shall dissolve in flames
As attested by David and the Sybil...
(...translation of the third part of the Requiem Mass)
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl 2.0b7 approx. 10 times slower than 1.3.x
Posted by Wim Kerkhoff <wi...@nyetwork.org>.
On 16-Apr-2002 David Lloyd wrote:
>
> Wim
>
>> code. Inside that eval block, the entire results of the query are being
>> loaded into memory. Instead of doing that, only put the $dbh->prepare
>> and $sth->execute in the eval. In the display code, process each row one at
>> a time, via something like this:
>
> That confirms my suspicion - it may not be Embperl at all. If Alexander
> is running one of the kernels with a very bad VM, then that could easily
> make it go really slow.
Aye. There are two many differences between RedHat 6.2 and 7.2 to point fingers
at Embperl immediately.
Regards,
Wim Kerkhoff -|- www.nyetwork.org -|- wim@nyetwork.org
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Embperl 2.0b7 approx. 10 times slower than 1.3.x
Posted by David Lloyd <ll...@rebel.net.au>.
Wim
> code. Inside that eval block, the entire results of the query are being
> loaded into memory. Instead of doing that, only put the $dbh->prepare
> and $sth->execute in the eval. In the display code, process each row one at
> a time, via something like this:
That confirms my suspicion - it may not be Embperl at all. If Alexander
is running one of the kernels with a very bad VM, then that could easily
make it go really slow.
DSL
--
On this day, this day of wrath
All shall dissolve in flames
As attested by David and the Sybil...
(...translation of the third part of the Requiem Mass)
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
RE: Embperl 2.0b7 approx. 10 times slower than 1.3.x
Posted by Wim Kerkhoff <wi...@nyetwork.org>.
On 16-Apr-2002 Alexander Hartmaier wrote:
> I tried for one week to change apache settings and other things but the thing
> is damn slow! Almost 1 minute for the biggest table which has ~2100 lines
> with 16 fields per line.
> The httpd process on the "new" machine uses all available processor
> ressources available for the whole time!
It could be something in 2.0b7, but seriously look at refactoring the
code. Inside that eval block, the entire results of the query are being
loaded into memory. Instead of doing that, only put the $dbh->prepare
and $sth->execute in the eval. In the display code, process each row one at
a time, via something like this:
[$ while (@data = $sth->fetchrow) $]
... html to display table cells and links ...
[$ endwhile $]
Regards,
Wim Kerkhoff -|- www.nyetwork.org -|- wim@nyetwork.org
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org