[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