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