Optimising performance of Perl binary

[Neil Griffin]

Hi,
currently we are hosting a Perl 5.6.1 based Intranet application on a
Sun 6x750MHz v880/Solaris 8 (64bit) server. The application performs a lot
of CGI/DBI (Oracle DBD) interactions apart from the required 'business'
processing. To try and improve the perfomance of this application after a
recent upgrade, I am looking at recompiling Perl and associated modules with
more agressive optimising and targeting of the platform. The developers are
also attempting to squeeze more cycles out of the application.

Originally the Perl was compiled with gcc 2.95.3 on a Sun Ultra 1/Solaris 8
(32bit) with the default optimisation. I am recompiling with Sun Forte v7 on
an UltraSparc II/Solaris 8 (64bit) server

My questions are:

1. Am I going to gain any performance compiling as a 64bit app, or should I
stick with 32bit. The O/S and Oracle are 64bit.

2. Are there any performance advantages moving to Perl 5.8? I read mixed
reports on this.

3. I am looking at using the Sun compiler options of -fast -xtarget=ultra3.
Are there any others that I should consider (safe) with Perl? The
appropriate spec.org reports indicate a number of other switches.

4. Are there any advantages using third party (malloc) libraries like
SmartHeap?

5. Are there any other compilation/configuration issues I should consider?

TIA

[Neil Griffin]

Hi,
currently we are hosting a Perl 5.6.1 based Intranet application on a
Sun 6x750MHz v880/Solaris 8 (64bit) server. The application performs a lot
of CGI/DBI (Oracle DBD) interactions apart from the required 'business'
processing. To try and improve the perfomance of this application after a
recent upgrade, I am looking at recompiling Perl and associated modules with
more agressive optimising and targeting of the platform. The developers are
also attempting to squeeze more cycles out of the application.

Originally the Perl was compiled with gcc 2.95.3 on a Sun Ultra 1/Solaris 8
(32bit) with the default optimisation. I am recompiling with Sun Forte v7 on
an UltraSparc II/Solaris 8 (64bit) server

My questions are:

1. Am I going to gain any performance compiling as a 64bit app, or should I
stick with 32bit. The O/S and Oracle are 64bit.

2. Are there any performance advantages moving to Perl 5.8? I read mixed
reports on this.

3. I am looking at using the Sun compiler options of -fast -xtarget=ultra3.
Are there any others that I should consider (safe) with Perl? The
appropriate spec.org reports indicate a number of other switches.

4. Are there any advantages using third party (malloc) libraries like
SmartHeap?

5. Are there any other compilation/configuration issues I should consider?

TIA

[Ron Reidy]

On my servers, I have Perl compiled for max optimization. I have had
not problems with Perl running in this matter.

On the Oracle side, you should have your developers ensure all preapre()
calls are using '{ora_check_sql => 0}'. Without this, each SQL
statement will be described and then parsed (double parsing) which will
eat up a lot of CPU on an active server.

Neil Griffin wrote:

> Hi,
> currently we are hosting a Perl 5.6.1 based Intranet application on a
> Sun 6x750MHz v880/Solaris 8 (64bit) server. The application performs a lot
> of CGI/DBI (Oracle DBD) interactions apart from the required 'business'
> processing. To try and improve the perfomance of this application after a
> recent upgrade, I am looking at recompiling Perl and associated modules with
> more agressive optimising and targeting of the platform. The developers are
> also attempting to squeeze more cycles out of the application.
>
> Originally the Perl was compiled with gcc 2.95.3 on a Sun Ultra 1/Solaris 8
> (32bit) with the default optimisation. I am recompiling with Sun Forte v7 on
> an UltraSparc II/Solaris 8 (64bit) server
>
> My questions are:
>
> 1. Am I going to gain any performance compiling as a 64bit app, or should I
> stick with 32bit. The O/S and Oracle are 64bit.
>
> 2. Are there any performance advantages moving to Perl 5.8? I read mixed
> reports on this.
>
> 3. I am looking at using the Sun compiler options of -fast -xtarget=ultra3.
> Are there any others that I should consider (safe) with Perl? The
> appropriate spec.org reports indicate a number of other switches.
>
> 4. Are there any advantages using third party (malloc) libraries like
> SmartHeap?
>
> 5. Are there any other compilation/configuration issues I should consider?
>
> TIA
>
>

--
Ron Reidy
Oracle DBA

[Bob Walton]

Neil Griffin wrote:

> Hi,
> currently we are hosting a Perl 5.6.1 based Intranet application on a
> Sun 6x750MHz v880/Solaris 8 (64bit) server. The application performs a lot
> of CGI/DBI (Oracle DBD) interactions apart from the required 'business'
> processing. To try and improve the perfomance of this application after a
> recent upgrade, I am looking at recompiling Perl and associated modules with
> more agressive optimising and targeting of the platform. The developers are
> also attempting to squeeze more cycles out of the application.
>
> Originally the Perl was compiled with gcc 2.95.3 on a Sun Ultra 1/Solaris 8
> (32bit) with the default optimisation. I am recompiling with Sun Forte v7 on
> an UltraSparc II/Solaris 8 (64bit) server
>
> My questions are:
>
> 1. Am I going to gain any performance compiling as a 64bit app, or should I
> stick with 32bit. The O/S and Oracle are 64bit.
>
> 2. Are there any performance advantages moving to Perl 5.8? I read mixed
> reports on this.
>
> 3. I am looking at using the Sun compiler options of -fast -xtarget=ultra3.
> Are there any others that I should consider (safe) with Perl? The
> appropriate spec.org reports indicate a number of other switches.
>
> 4. Are there any advantages using third party (malloc) libraries like
> SmartHeap?
>
> 5. Are there any other compilation/configuration issues I should consider?
>

....


I would be amazed if you gain enough from compiler optimizations and the
like to make it worth the time and effort involved (and the time spent
fighting potential compiler bugs in the fancier optimizations). You
don't mention the use of mod_perl. If you are not using mod_perl or
something equivalent, you could gain speed by orders of magnitude by
using it. You would need to move to the Apache web server.
Well-written Perl CGI scripts need no modification. This basically
functions by holding a Perl interpreter and a compiled Perl process
ready-to-go for new CGI requests, with no need to start a process, load
the Perl interpreter and script, and compile the script each time. It
just goes right to running the script. Also, a connection to your
database is held open so that doesn't need to be established each time
either. The result is a truly dramatic improvement in performance.

--
Bob Walton

[Neil Griffin]

The developers are indeed moving to Mod-Perl, but aren't quite there yet.
The re-architecting of application to support Mod-Perl and other changes is
part of the reason why the performance has gone backwards :-(

I'm just trying to wring the most out of the platform that I can... 5-10%
here or there would be useful.

Thanks for the feedback.

Bob Walton wrote in message <3F64C4A6.6010602@rochester.rr.com>...

>Neil Griffin wrote:
>

>> Hi,
>> currently we are hosting a Perl 5.6.1 based Intranet application on a
>> Sun 6x750MHz v880/Solaris 8 (64bit) server. The application performs a

lot

>> of CGI/DBI (Oracle DBD) interactions apart from the required 'business'
>> processing. To try and improve the perfomance of this application after a
>> recent upgrade, I am looking at recompiling Perl and associated modules

with

>> more agressive optimising and targeting of the platform. The developers

are

>> also attempting to squeeze more cycles out of the application.
>>
>> Originally the Perl was compiled with gcc 2.95.3 on a Sun Ultra 1/Solaris

8

>> (32bit) with the default optimisation. I am recompiling with Sun Forte v7

on

>> an UltraSparc II/Solaris 8 (64bit) server
>>
>> My questions are:
>>
>> 1. Am I going to gain any performance compiling as a 64bit app, or should

I

>> stick with 32bit. The O/S and Oracle are 64bit.
>>
>> 2. Are there any performance advantages moving to Perl 5.8? I read mixed
>> reports on this.
>>
>> 3. I am looking at using the Sun compiler options

of -fast -xtarget=ultra3.

>> Are there any others that I should consider (safe) with Perl? The
>> appropriate spec.org reports indicate a number of other switches.
>>
>> 4. Are there any advantages using third party (malloc) libraries like
>> SmartHeap?
>>
>> 5. Are there any other compilation/configuration issues I should

consider?

>>

>...
>
>
>I would be amazed if you gain enough from compiler optimizations and the
>like to make it worth the time and effort involved (and the time spent
>fighting potential compiler bugs in the fancier optimizations). You
>don't mention the use of mod_perl. If you are not using mod_perl or
>something equivalent, you could gain speed by orders of magnitude by
>using it. You would need to move to the Apache web server.
>Well-written Perl CGI scripts need no modification. This basically
>functions by holding a Perl interpreter and a compiled Perl process
>ready-to-go for new CGI requests, with no need to start a process, load
>the Perl interpreter and script, and compile the script each time. It
>just goes right to running the script. Also, a connection to your
>database is held open so that doesn't need to be established each time
>either. The result is a truly dramatic improvement in performance.
>
>--
>Bob Walton
>