well, here's a fun start. Google drupal performance problems and from
http://drupal.org/node/2601:
"Understanding LAMP performance. This LAMP performance study revealed
that Apache is bandwidth limited, PHP is CPU limited, and MySQL is
memory limited and disk I/O bound."
Have fun with that.
But seriously, this is both complex and simple. When you picture what's
going on it's simple.
These interpreter/compiler runtime engines such as PHP and the Java JVM
run well sitting in memory. So everyone says get more menory. duh!
Reminds me of the old days when hard drives were really slow, and
floppies slower. Solution. a Ramdrive. 1 Meg of memory turned into a
virtual drive and that ol' compile screams soundlessly.
Fast forward a few years (ok, more than a few) and the Future meets the
Past. You have honkin code that everyone wants theirs to sit in memory
to get good performance, and oh by the way IBM sells memory. Hardly a
disincentive there to make honkin code.
So you go through the alternatives. mod_php compiled into Apache versus
CGI php. In memory versus spawning jobs. And on and on down the line. In
memory versus honkin.
The point of Zend doing free stuff on the iseries was to sell stuff.
They sell high end performance stuff, which is more sitting in memory
instead of honkin alternatives.
Drupal like any big php packaga is a whole lot of php scripts. Picture a
whole bunch of interpreted Basic programs. Every time one of those
modules is called the php interpreter, sitting in Apache job space if
running in mid_php, interprets the script. Zend caches the results based
on the level of Zend power caching they provide so it doesn't have to be
reinterpreted again, but the more effective product was a for money
product was my understanding from the original product announcement.
Maybe they provide that on the iseries, maybe they have the real thing
for a bit more, maybe for a lot more, I don't know.
You should do baseline tests with minimal php, starting with the php
version page and working up from there to establish baseline throughput
time, then see how much the size and number of the php script code in
Drupal adds to it, if any. Who knows, it could take 4 seconds to get a
Not Found error from Apache, so you have to work your way up and see
where the honkin is for starters.
Assuming it's just a load to run Drupal, the highest end Zend will run
it efficiently, so check those cost tradeoffs. Throwing memory at doing
stupid things because memory helps may not be the most cost effective
way to go about it, but it's hard to beat a Ramdrive, so that's usually
the advice.
rd
plancor@xxxxxxxxxxxxxxx wrote:
We have Zend, MySQL and Drupal installed and running on our V5R4 520. Our
new web admin is a Drupal advocate and wants to start using Drupal to
manage some inhouse project sites. However, performance is really bad. At
best, 4 second response - at worst 15+ second response. We have 16GB of
memory, 78% disk utilization, and normally < 30% CPU Usage. I found a
document on Zend's site
(http://www.zend.com/en/support/knowledgebase.php?kbid=286&view_only=1)
that offers some suggestions to improve performance. Since some of these
recommendations involve changing system values or TCP attributes, I am
reluctant to change them without knowing beforehand that I will see an
improvement. Has anyone made any of these changes and realized an
improvement in performance? Has anyone made any other changes that
resulted in improved performance?
Any advice regarding improving performance of applications running in PACE
would be appreciated.
midrange.com
