Zend Optimizer Slower!!

Anon

I am running PHP4.04pl1 with Apache 1.3.19 with a Pentium III 800MHz and 256MB of RAM.

I recently optimized my code to become more efficient and can get my homepage (static, template based) to complete 160 transactions per second (tps) when using Torture to stress the system. I am pleased with this number.

I installed the Zend Optimizer to see if I can get better performance, but I actually got worse!! Not by a huge number, but I actually was getting only 151 tps with Zend.

Isn't Zend Optimizer supposed to make ALL code faster? Can anyone explain this or offer any input?

Also, since most of my pages use a template system calling function libraries, is there anyway to cache those libraries (included files) so PHP does not have to load them on every single interpretation?

I would appreciate any and all help.

[deleted]

Zend is an optimizer, which means it is an extra step in the compilation process.
Zend too must be loaded, the code must be send to the optimizer, the optimizer must do it's business and send the optimized code back.
This all takes time.

Wether it's faster depends on how long it takes to run the Zend optimizer in relation to the speed increase you get fro the optimized code.

But the my first thought would be: did you correctly install the optimizer?
Is it possible that you installed the wrong version and now PHP is starting up a useless optimizer wich doesnt optimize the code, and instead just takes time to load?

Anon

Well, I followed the exact instructions found at
http://www.zend.com/store/products/optimizer-faq.php

And I downloaded the first one on the list {Linux glibc2.1 (for PHP 4.0.4)} since I am running Red Hat 7.1. After install and editing of my php.ini file, I checked my php_info() screen and the 3 optimizations showed up. So I think I installed it correctly.

Does anything above sound incorrect?

You would think the optimizer would optimize everything, even a file as simple as <?php php_info() ?>. Maybe I should try testing the previous sentence.

[deleted]

It sounds like you installed it correctly.

But obviously the optimizer can't optimize everything.
If it could, then the default PHP compiler would be crap wouldn't it? 🙂

The optimizer does try to optimize everything, but there
are some things that simply run at top-speed already, such as phpinfo().

The optimizer is particularly usefull for iterative code.

Try it out with a looped function, like:

$r=0;
for ($t=0;$t<100000;$t++)
{
$r++;
};

Try that with and without the optimizer.

Anon

Thanks for the suggestion.

Does the optimizer "help" poorly written code, i.e. code that is not truly efficient? Or does it primarily just help out with iterative processes?

Also, I feel my code is pretty efficient. I do feel that I could get better performance if I could somehow cache the common included and required files needed by my pages. I am aware of Zend Cache, but I am cheap, so I need another alternative. My entire web site (to be disclosed later) is only 800K, with about 400K of that being images. Do you think a RAM disk or something might help me cache my files? Or is there a way to configure what Apache caches?

I appreciate any suggestions.

[deleted]

No, the optimizer does not make your program a better program.

Think of it this way:
When you run a script, your lines of code have to be translated into machine code that the CPU can understand.
PHP and the CPU speak two different languages.
As with all languages, you can say the same thing in many different ways.
The problem is in finding the most efficient translation.
The optimizer helps here by applying some algorithms and other smart things that quickly find the fastest translation.

But sometimes what you want to say in PHP is so simple that there is only one translation. In that case, trying to find a better translation is just a waste of time.

There are several ways of caching PHP's output, but the question is: do you really need to?
Did you do some proper becnhmarking/stresstesting to find out just how much the server can take?

And more importantly, do you really expect to get such a high load that PHP won't be fast enough to cope?

Anon

I am basically trying to get the most output possible. I have 3 identical webservers as described in previous threads. These 3 webservers are going to need to serve out a customer base of approximately 30 million people. So, I'm wondering if the 480 (160 x 3) tps that my servers can handle will be enough.

To help explain, I took the exact html that php spit out for my homepage and stuck in an html document. I hit that html document the same way I hit the PHP page that produced the same output. I was able to get 240 tps on the static html vs the 160 on the php page. Now, I know the overhead for the html is much less than php, but I'm wondering how close can I get my php code to that 240 number.

I'm not doubting php's abilities, I just want to get as close to the peak (240 tps) as possible.

I guess I'm hoping for the best of both worlds - compiling the common stuff and interpreting the unique stuff.

Do you know of any ways I can get closer to my goal of 240 tps?

[deleted]

Comparing PHP with plain HTML is comparing apples with cucumbers. :-)

In such a comparison PHP looks dead-slow, but remember that PHP offers a sh*tload of functionality that plain HTML doesn't.

you say you have 30 million customers. (that's one hell of a lot of people btw)
and 'only' 480 tps.
You have to keep a few things in mind.
a) not all 30 million will be online at the same time
b) people only click once every X seconds

I take it you are using PHP as a module (either compiled into the webserver or linked) and NOT the CGI version?
Did you read the apache-webserver docs about optimizing for speed?
Did you read the PHP docs about optimizing PHP for speed?

Anon

Dude, 160 page views a second is hauling ass. Figure you can handle about 10 to 100 times that in people, because folks pause anywhere from 1 to 20 seconds between page views typically.

What I found amazing was you were only able to get 240 page views a second on static html. Do you have your box set to parse .html pages with php? If it is try turning that off and try again. You should be able to see 10x that (i.e. 1000 page views a second or so) with static html.

The real issue isn't how many page views a second you can give linearly (i.e. one simo connection viewing 200 pages a second) but how many people can request the page at the same time and still get it. Does your torture program support testing under high parallel load? If not, the try ab, the Apache aBuse program that comes with the package to load up the server with a lot of parallel requests for a few minutes or hours and see how the system behaves. Stability under high parallel load is the real bugaboo of web design, and your system sounds like it could easily hand hundreds of simo connections with a resonse time <3 seconds.

Anon

Well, my site has not been launched yet, but it will be advertised to about 30 million people real soon. This is not counting the X million people that will stumble across our web site either on their own or via a search engine.

The architecture of our system is horizontal - we can add as many webservers as needed, each giving 160 tps.

I was not trying to compare html to php, I was trying to say that the speed at which I get an html document is the absolute fastest. So getting as close to that speed as I can is the goal.

I am linking php as a module.

Which docs are you speaking of for apache and php? Can you maybe provide some links?

Thanks.

Anon

The place to configure whether I want my box to parse .html files with php is in my httpd.conf file - right? Below is what I have:

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Is this wrong?

The page I'm only getting 240 tps is 6.5K of html. Does that make any difference? What else could be slowing down from 1000 tps to 240 tps?

The torture program was actually opening up 100 children (simulated users) and was asking for the page 15 times in a row. This is the configuration I was using to get my 160 tps.

I will try ab to see if I get similar results - thanks.

kparker

I do feel that I could get better performance if I could somehow cache the
common included and required files

For starters, your filesystem already does this, so any additional caching will be of secondary benefit. Remember, caching the include-files before they are included is a completely different matter than caching a made-up page.

Anon

But since my whole site is about 800K, can't I somehow cache the entire site so I don't have to read from the hard disk every time?

If not, is there a way to configure the caching of my filesystem?

kparker

If you think it would help, you could always create a ram disk and copy the entire contents of the directory there before apache starts. Somehow, though, if your contents really are that small, and your server has enough ram, it's close to happening already without you making the slightest effort. Indeed, the main beauty of a most-recently-used caching system is that small, frequently-used files (such as a 20k include-file used by every php script) will indeed live in RAM (and the hard-disk updates for things like last-access-time will happen in the background.)

Anon

I figure out why I was only getting 240 tps on static html; that is the max numbe rof connections my client running torture could make. When I ram ab, I was getting about 1200 tps on static html pages.

Thanks for pointing this out.

I also noticed that my 160 tps on my php pages was dramatically reduced when I hit my sessioned member pages. My tps went to a max of 38 tps per machine on sessioned pages. I am using my own session handlers and MySQL over a network to handle my sessions. I am also using '-enable-trans-sid' in my configuration so every link is automatically given a session id.

I'm wondering which, if not both, are causing me to go from 160 to 38 tps - slow session server and/or parsing time to add session IDs onto the ends of links???

Any ideas?

[deleted]

I think you can safely say that MySQL is slowing you down dramatically. :-)

A database is much (if not insanely much) slower than the filesystem.
I've done a simple test a while back and decided to stick with storing sessions on disk, because a simple 'SELECT sessionid FROM table' took 20 times as long as getting the same data from the filesystem. (yes that was using persistant connections)

I don't think the trans-id parsing will slow you down much, but you'll have to benchmark that using microtime().

Anon

Vincent is right. If you're gonna handle a lot of simo connects on a database, with reads and writes, mysql is NOT a good choice. Look at postgresql for that kinda thing.

[deleted]

Is Postgres that much faster at creating a database connection? never really benchmarked it...

Anon

It's not that it's that much faster at the connection speed, it's so much better at responding to hundreds of simultaneous requests at once.

The interesting thing is that postgresql becomes faster as the first 20 or 40 simos come online, since it can share all the accessed data in a large common cache while running.

Note that individual performance is of course dropping, but aggregate performance is increasing in that range. After 40 or 60 simos, aggregate performance slowly drops til memory starvation, I/O starvation, or kernel handle / resource starvation.

Due to it's multi-process design, it is much more robust should a backend fail, since only that backend is killed, then all buffers flushed. I.e. only that one page has an issue, not the whole server.

This design makes postgresql pretty fast and incredible robust on Linux, but is runs pretty slowly on slowalrus and other multi-thread oriented OSes.

If you have your db server and web servers setup properly you can use persistant connections to get about 100k to 1M connects a second. Use regular connections and that drops to 1k to 10k connections a second.

Neither are a real bottleneck, and I find that NOT using persistant connects results in fewer backends running, and postgresql therefore responding faster because there are fewer backends to keep track of. I think that if I had more memory on my big box at work persistant connects might work better, but haven't had a chance to test that theory.

I'm building 7.1.2 right now to do some synthetic benchmarks, and I'll post the numbers when it's built.

Note that we found a problem in 7.1.2 that when indexing words, it's dog slow compared to 7.0.x Gotta make a bug report this week...

Anon

Here is my setup: 3 webservers talking to one session server. All boxes are Red Hat 7.1.

I originally had my session server samba mounted on each webserver, but when a particular webserver got hit hard, it actually crashed!

What is a better alternative if I use a filesystem - NFS? Any other ideas?