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
|
Similar Threads
