in reply to [untitled node, ID 195604]

Is mod_perl available on your host?

If not, every time your page is accessed a new perl process is started, services the request, then dies. That's a pretty heavy hit for the poor webserver to take.

I think you'd have to adapt your approach to work under mod_perl, though, but I'm not sure. Check out the mod_perl site.

I'm sure a lot of the other monks can give you more detailed advice.

How much code are we talking about, though? If it's not too bad, don't be totally opposed to the php idea. It could be a good educational exercise, if nothing else.
--
Mike

  • Comment on Re: General questions on optimizing Perl performance

Replies are listed 'Best First'.
195614
by Samn (Monk) on Sep 06, 2002 at 11:51 UTC
    		[reply]
        You can do a lot of damage in 92 lines. For example, even a very small database query is usually heavier than anything else in a Perl script, and opening a database connection takes time. Using a persistent environment like mod_perl takes care of the connection problem, and some caching could help with general performance.

        If you don't have access to mod_perl, you could try to convince your web host to let you run some other things. Options include FastCGI, CGI::SpeedyCGI, and PPerl. You should also learn to use Devel::DProf, which will tell you where your script is spending its time.

    		[reply]
        Hi,

        as Mike said, main problem is the launch of the Perl Binary itself. Moving over to mod_perl can save _lots_ of CPU ("System") time. Beside that, Parsing only one time will save CPU ("User") time too, of course.

        lg,
        daniel
    		[reply]

    In Section Seekers of Perl Wisdom