Ok, here's an update from me - I would've posted earlier but we had an incompatibility with our cart software that needed fixing from all of my tweaking ;-)

So, I found this little site on the internet that talked about performance gains when PHP, Apache and MySQL are compiled using the Intel C/C++ Compiler. I went and checked out Intel's site at this link and what do you know - they have a free development license a person can use if they register. Well, I figured this should at least be attempted - which of course can be really difficult when using a binary based distribution (as opposed to my home Linux system which runs Gentoo) and considering that both of our linux servers are running different Linux distros with completely different package management systems - well - I just figured that it wouldn't be that easy.

I was wrong!

I went through the install process on our Debian and CentOS machines with no problem, set a few environment variables and downloaded the source .deb(s) and .rpm(s) that I wanted to recompile. Made some edits to the SPEC files (RPM) and rules files (Deb) and recompiled PHP and Apache.

Ok, not EVERYTHING has gone as planned ;-) On the Debian machine I haven't actually installed the mysql binary yet because I'm still not sure I did things right and am waiting for one of my team members who is a debian developer to take a look at what I did. But on the CentOS machine (I'm much more familiar with RPM and working with RPMs) I recompiled php and apache and am using them right now. As you can see from the benchmarks above there is a big improvement. Not 50%, but almost 40%! That's a big deal considering all of the work I've done so far to just squeeze out some very small tweaks. This tweak has by far done the biggest amount of good for the smallest amount of time.

And I haven't even used the recompiled mysql daemon yet! So, I'll post some results after I've done that. I'm now going to go through the php.ini settings and start looking at what can be tweaked and will report my findings.

Anyways, pretty cool stuff!

- Marco

Here is the link I was talking about:

http://ez.no/layout/set/printarticle/de ... ez_publish

I updated the ethernet driver on the webserver (running an older 2.4.x kernel) and that increased throughput and latency. I noticed that the index.php page is now constructed about 5 ms slower. I know I know - but still - an increase in performance nonetheless.

:-)

- Marco

I haven't tweaked the php.ini file yet, but I finally installed the intel compiled version of mysql on the database machine. I'm really happy you guys - all this work has paid off. Check this out - I just ran this benchmark:

First off, 100% availability. But look at the longest and shortest transactions! .47 seconds and a max of 4.67. Not only did it serve all 100% of the test (this test everytime I run it takes 1/2 hour!) but it served it quickly and efficiently.

Compare that to some of the other runs where the longest transaction took up to to 30 seconds!!!!!!!

Anyways, still have other stuff to tweak and even though I'm probably the only one still reading this thread (haha!) I thought I'd post this addition to my experience so far.

- Marco

Quote by: tt0ne

Anyways, still have other stuff to tweak and even though I'm probably the only one still reading this thread (haha!) I thought I'd post this addition to my experience so far.

Ha, I'm reading it!!

I forget, are you using the caching template library? I know we mentioned it. I'm curious if, after all your tweaking, whether it still has an impact. So if you are using it, could run your suite again without it?

Joe,

Yes, I'm using your wonderful caching template but I'll run the test without it so we can see if it makes a difference for this particular benchmark. One question, though - is there an easy way to uninstall it without having to make all the changes to the files or should I just retrace the steps in the install instructions to disable it?

- Marco

You can disable it in config.php

Thanks, man - that was stupid - how did I forget? I'll now run the benchmark. See ya guys in 1/2 hour ;-)

- Marco

Ok, with the caching template turned off in config.php here are the results:

As you can plainly see - it is a contributor - how much is hard to say - because I would've needed to disable all the other tweaks in this thread - but it appears that it has its biggest effect on transaction rate - almost 1 whole page a second - which is a major deal if you've been following this thread.

- Marco

Very interesting!

Cool....

Have you guys seen this:

http://tools.pingdom.com/fpt

NOTE TO SELF: GOOD TOOL FOR A QUICK BIRDSEYE VIEW.

- Marco

I should elaborate....

Quote by: tt0ne

As you can plainly see - it is a contributor - how much is hard to say - because I would've needed to disable all the other tweaks in this thread

No, I wanted to see how much impact using a fast or slow template engine has. Whether the database is optimized or not shouldn't matter. In fact by squeezing out as much as you can from apache, mysql, and php, you've only got left the actual code to improve and all those regexes in the default template library are no match for raw PHP variable substitution.

Marco,

This is all very cool stuff, thank you for sharing the journey.

It is interesting to see that the Caching Template Library does provide a measurable difference, thanks for running that benchmark. From the tests I've run, focused specifically on code execution it does make a difference in site performance. Now we have some more real world data too.

I hope to find some time over the coming weeks to try some of the wonderful tweaks you've documented.

Thanks again!
Mark

Ah, I see what you mean, Joe. By using an optimized system we actually proved that the caching template is even more important. If you think about it, I started out with 3 transactions per second. I've improved it to almost 5 1/2 transactions per second. If the caching template, after it is all said and done with contributes 1 transaction per second (give or take some minuscule amount) to the overall "tweaked" amount then your caching template is almost responsible for 50% of that!

Wow, that's pretty cool. Once again, it's hard for me to imagine that after all this testing that your caching template isn't part of the GL 1.5 release. But, I won't contribute to disunity ;-)

- Marco

PS: Mark - thanks, bro - I've still got a few more things to do before I can say I've tried everything ;-) It has been very insightful to say the least! Gonna try X-cache next - see if it's faster then eaccelerator.