SEO

#1 (**permalink**) 01-12-2008, 05:31 AM

"Neil Griffin" <neil.griffin@nospam.com> writes:

> 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.

32 bits will give you better performance, all else equal. The reason is
that 32bit pointers in data structures are more compact, so they use the
data cache more efficiently.

> 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.

I'd be amazed if you got more than (or even close to) 10% speedup.

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

Not sure, but I'd be surprised if it achieved more than 5% better throughput.

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

If you you are using perl via straight CGI with Apapche,
then you can probably achieve very impressive speedup using
mod_perl to run your perl CGIs. See http://perl.apache.org/
for more info.

-SEan

#2 (**permalink**) 01-12-2008, 05:31 AM

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.

Sean Burke wrote in message ...
>
>"Neil Griffin" <neil.griffin@nospam.com> writes:
>
>> 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.
>
>32 bits will give you better performance, all else equal. The reason is
>that 32bit pointers in data structures are more compact, so they use the
>data cache more efficiently.
>
>> 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.
>
>I'd be amazed if you got more than (or even close to) 10% speedup.
>
>> 4. Are there any advantages using third party (malloc) libraries like
>> SmartHeap?
>
>Not sure, but I'd be surprised if it achieved more than 5% better
throughput.
>
>> 5. Are there any other compilation/configuration issues I should
consider?
>
>If you you are using perl via straight CGI with Apapche,
>then you can probably achieve very impressive speedup using
>mod_perl to run your perl CGIs. See http://perl.apache.org/
>for more info.
>
>-SEan

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: Optimising performance of Perl binary on Solaris