Zend Optimizer - eAccelerator alone outweighs it

Hey everyone,

I've been testing my production server (dynamic, heavy database driven -- but no benchmarking was done) within the last week due to it being slower than normal. Now, don't get me wrong this slowness hasn't just turned up, but I never noticed it until it was brought to my attention.

So, anyway, I've been doing a lot of testing with eAccelerator, Zend Optimizer and PHP's APC.

When it was going slow all I had on was Zend Optimizer. This obviously did what it said on the tin. Sped up the time to serve PHP pages. There was just one slight glitch. Connection. Somehow it was still slow waiting for a connection. At first, I thought it had to be something to do with the DNS or the few routers you connect through to get there; but in the end, it wasn't either of them.

I decided to increase the KeepAliveTimeout variable to 60 in the httpd.conf as it was set to something low, like 5 -- to keep processes from spawning. Once I did that everything returned to normal and it was faster than before. However, there was one draw back. Those processes spawning. It eventually brought my server to a halt. So for me I had to find something different or return back to having a fast server ('cause I wanted a faster server).

I came across PHP's APC and installed it right away. Turned off Zend Opti., installed APC and right away it made my server faster overall. No waiting for connections!

After about 50 minutes of it running it had cached 108MB or around 2,000 files with about 20MB left. It ate another 10MB from my memory and no one could connect to my server any more (just through HTTPD). I wasn't impressed.. at all.

I find eAccelerator and installed this instead. eAccelerator is the only thing currently running on my server as a Zend extension, without Zend Opti (I've ran them both alongside each other with terrible consequences too).

eAccelerator caches the pages to the server, not memory. So now I have on average 50-70MB of memory freed.

It's faster too. With KeepAliveTimeout set to the original 5 it still connects to the server like it should when it was set to 60.

I'm quite surprised, but it's been going for 24 hours already and there's been no crashes or anything else. It's used 154M on the server.

I would suggest people to try it out just by itself. I obviously don't want to guarantee any advantages, but I have had tremendous ones; and since it's simple to install and 'switch' Zend Opti. off and eAccelerator on it's worth a shot!

If anyone does this, please reply back here. I've been running Zend Opti. for over 2 years (and I've tried everything, putting them together with eAccelerator -- but I never thought to just have one running and not the others). I guess the hype of everyone wanting Zend Opti. installed and the reviews it got, just made me put it on. Especially when I saw that it did speed up my server.

Zend optimizer is pure crap...(forgive me zend lovers). There's ioncube if you want to run encoded scripts...most providers offer ioncube encoded versions too these days.

I've been running xcache and quite impressed with it.

you can load zend optimiser for zend binaries but disable the optimisation part of it.

Yeh, a quite viable solution too.

Ste said:

Hey everyone,
eAccelerator caches the pages to the server, not memory. So now I have on average 50-70MB of memory freed. It's faster too. With KeepAliveTimeout set to the original 5 it still connects to the server like it should when it was set to 60. I'm quite surprised, but it's been going for 24 hours already and there's been no crashes or anything else. It's used 154M on the server.

Click to expand...

We serve 10,000 to 15,000 pages per minute. Pages have approximately 200 small graphics on them, but of course the browsers cache most of them after the first page. We generate and serve about a 8 -12 pngs per page as well. Having a site like this to test OSes, and software combinations is both a blessing and a curse. I can tell you that you are right on the money. APC can be pretty fast too. It's what ships with PHP and it's logical that coming out with the release PHP 6, it would have the upper hand. You will hear a lot about XCache as well. Here are how things worked out for us.
1. XCache - Is not nearly as fast as APC and eAccelerator.
2. APC & eAccelerator run about the same speed.
3. The errors is something else that not many of us get to see because they don't happen every time. Thus you don't see the errors your customers experience. We have web crawlers that spawn hundreds of threads. We need this to pull XML data for 112,000 different sources to see where data is messed up or missing. As a side benefit, it reports server errors. XCache has lots of errors under any load, and APC does under higher loads. eAccelerator has none under any load. By load I'm talking up to 167.
4. eAccelerator is the only cache that will allow you to work with Zend optimizer and ionCube together. That's an advantage for hosters who have no idea what customers are going to bring along with them.
5. Zend optimizer has no FreeBSD 7.x release even though FreeBSD 7 has been out for more than a year. Thus you will need to run the Compat6x libraries to use it. I'm not excited about a company that cannot do a recompile.

With eAccelerator you will forget how you installed it. The other two caches will make you an expert in computer mysteries.

So are you recommending a specific configuration? Please clarify a bit more.

Thanks!

Jeff

jlasman said:

So are you recommending a specific configuration? Please clarify a bit more.
Thanks!
Jeff

Click to expand...

I wasn't thinking that way, I was agreeing that our test show eAccelerator over XCache and APC. But, I can paste what I have in that server now. It's really too bad that I didn't save the big config for all of them. They were all in one an you could comment at will, but the file was also huge. The parameters for the cache configs are 100 lines long. I can paste what is left and what contains the salient information. You can see in the head some notes/reminders about the tests, However, what is most important iis the order. It is not not necessarily what you will read it other places, but it is the only order that worked to get Zend, ionCube, and eAccelerator to play together and be rock solid. Another note is the unlike the others, eAcclerator has its own byte order optimizer. It may not be as good as Zend's, but when you're caching, byte ordering makes a tiny, but measurable difference.(barely) Thus, when you set up your eAccelerator cache parameters, if you use the Zend optimizer byte ordering, then turn off eaccelerator.optimizer and vice versa. I'm not holding back by not pasting in another 100 lines of boredom with the eAccellerator parameters. They are simple with explanations and it's nothing like tweaking Apache or MySQL for instance.

At first I thought how could a cache benefit work with dynamic pages? (Oh duh!) The only time the page needs to be recompiled is if the page code changes. It has nothing to do with the content changing. The performance and server load difference is astounding. The only time it doesn't work is if you have some process writing the php on the fly. That's a pretty special case.

;************************************************************************
; PHP Cache and Decoders
;************************************************************************
; You load a cache here as a a PHP extension, or below as a Zend extension
; You should load only one PHP cache
; These rules control your options:
; 1. APC will not work with Zend Optimizer nor ionCube
; 2. Xcache will work with ionCube, but not Zend Optimizer
; 3. eAccelerator will work with both at the same time
; When you select a cache, you must comment out incompatible modlues

; *** PHP Caches; Uncomment not more than one
;extension="eaccelerator.so" ;Works with Zend & ionCube

;************************************************************************
; Zend & Extensions
;************************************************************************
[Zend]
; *** PHP Accelerators loaded as Zend Extension: Uncomment not more than one
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20060613/eaccelerator.so

; *** ionCube Loader
zend_extension=/usr/local/Zend/lib/ioncube_loader_fre_5.2.so

; *** Zend Optimizer
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3
zend_optimizer.version=3.3.3

zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

Click to expand...

i'm running XCache & Zend Optimizer without any problems

php -v
PHP 5.2.9 (cli) (built: Mar 8 2009 14:57:38)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with XCache v1.2.2, Copyright (c) 2005-2007, by mOo
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

Click to expand...

php -m
[PHP Modules]
bcmath
calendar
ctype
curl
date
dom
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mcrypt
memcache
mhash
mysql
mysqli
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
posix
Reflection
session
SimpleXML
sockets
SPL
SQLite
standard
tokenizer
XCache
xml
xmlreader
xmlwriter
Zend Optimizer
zip
zlib

[Zend Modules]
XCache
Zend Extension Manager
Zend Optimizer

Click to expand...

BestBoard said:

i'm running XCache & Zend Optimizer without any problems

Click to expand...

Well you've got me on that one. I could not get it to work no matter what combination I tried. They added on the last release, but that was 2006 and it was the middle of 2008 that I tried to get it to work, so we would be working with the same release. Without the optimizer we had plenty of server errors when we ran the bots on it.

Thanks for posting that.