[imp] Re: [horde] IMP & PHP Speed Improvements

Nate Mollring nmollring@cennecs.org
Sat Oct 26 17:16:41 2002



Quoting Ryan Gallagher <ryan@studiesabroad.com>:

> Quoting Jon Parise <jon@horde.org>:
> 
> > On Fri, Oct 25, 2002 at 09:31:19PM -0400, Luis Hernandez wrote:
> > 
> > > We are using IMP at our institution under Solaris 8 and Apache 1.3.9.
> What
> > can
> > > be done to improve the speed of PHP and IMP? We are not experiencing any
> > > problems in speed right now, but since IMP is written in PHP
> (interpreted
> > > language), we do notice the difference in speed than with a simple HTML
> web
> > page.
> 
> Zend may be an option.  But there are usually some more straight-forward
> improvements that can be made first.  Also, for reference, you are almost
> NEVER
> going to match the speed of pure HTML static pages.  This is what you want to
> be
> serving, say... if Slashdot links to you. ;)
> 

http://www.php-accelerator.co.uk/  helped both my Horde installs.  Pages are 
served quicker and server load is much less.  I have a 150+ users on the 
production server.  From the site:

"Every time a PHP script is accessed, the PHP engine must open the script file 
and read, parse, and compile the file contents into a compiled form. Only then 
can the compiled code be executed. With scripts often including other scripts, 
this work can become a significant part of the overall time to deliver a page. 
It can also impact I/O performance, and require much dynamic memory allocation 
that in itself can be time consuming. 

The reality, however, is that most PHP scripts never change from one access to 
the next; indeed they may never change for weeks, months, or even years. The 
Accelerator works to eliminate the penalty of processing scripts that never 
change, and by caching the compiled scripts in shared memory, delivers 
significant performance gains as a result. Note that this is very different to 
caching script output. PHPA doesn't do this, scripts remain fully dynamic, and 
if they do change then PHPA caches a new version - they just run faster! 

So by caching, the Accelerator eliminates:


reading of source code 
parsing of source code 
compiled code generation 
many memory allocation and copying operations 
disk related operations 
Once script execution has completed, compiled versions of any new or modified 
scripts are immediately cached on disk for later reuse. This guarantees good 
acceleration, but scripts are then cached in shared memory, and offering the 
maximum performance gains. 
The Accelerator has one other performance enhancing feature - a built-in code 
optimiser. Although in it's early stages, the optimiser reduces the size of 
compiled code and improves the code by removing unnecessary operations. 

So in summary, by aggressively removing operations causing performance 
overhead, the Accelerator is able to deliver performance rivalling the very 
best alternatives, and for free! "

Hope this helps, 
Nate