Includes: PHP vs. SSI vs. iFrame vs. Static. Benchmarking techniques?

[Makosuke]

I'm looking to add what's basically a small chunk of rotated content ("this week's feature" sort of thing) to the sidebar of a site of mine that currently consists of static pages built out by a somewhat custom backend. I've been debating whether to do this as an iFrame, via an SSI include, or a PHP include. Or, maybe just rebuild the whole set of pages every week if I really need to.

What's weird is that I can't seem to find any sort of benchmark past unfounded generalizations as to which is faster, which has the lowest CPU overhead, and (possibly most importantly) what the relative speed difference is between them.

That is, it's not clear to me whether an SSI parser is going to take longer and more CPU overhead to process a, say, 50KB page vs using a PHP include on the same file, and if the relative increase in CPU hit vs. a "bare" HTTP request is large enough with either to care about. I mean, if feeding the page to PHP and doing a couple of small includes with no database access or other logic is only going to add 20% of the CPU seconds over a bare Apache request, it wouldn't really matter, but if it's a factor of 5, then that's more significant.

Similarly, while I know the user-end time to do another HTTP request for iFrame content is significant, I don't know what the associated Apache overhead for another request is.

Does anybody have any suggested reading with some concrete numbers on this stuff? Or, alternately, any suggestions as to a decent benchmarking technique so that I could run a few hundred requests and see what the reality is?

 

[angelwatt]

Well iframe would be the slowest as the browser has to make the additional request. With SSI and PHP includes the files are handled server-side and so only result in one request from the browser. An iframe can also have some accessibility issues.

I'd suggest PHP over SSI simply on the basis that PHP is more powerful and flexible. Any speed differences are going to be minuscule. Specific differences are going to depend on Apache version and PHP version.

 

[Makosuke]

I kind of figured PHP was going to have the edge over SSI in that it's more powerful and probably doesn't have significantly more overhead. And I also know that from an end-user perspective iframes are going to be drastically slower in most cases.

But I guess I mis-phrased my question; what I'm really wondering is what kind of real-world numbers these things are going to produce on a shared server. That is, if I'm looking at, say, 100K pageviews, and comparing: 100K PHP pages with 2 includes each to 100K static files with two iframes each (which is thus equal to 300K HTTP requests for static HTML), what is the CPU seconds consumed going to be?

How efficient is a very simple PHP parse going to be versus a static HTTP request? I really have no point of reference whatsoever, and I'm curious for both pure geekery and practical reasons whether we're talking about, say, 10 CPU-seconds for 100K static HTTP requests and 1000 CPU-seconds for 100K simple PHP pages parsed, or 10 and 20 seconds, respectively.

I'm trying to get a feel for if going from 100K to 300K HTTP requests is relatively trivial where going from 100K static HTTP requests to 100K PHP requests is huge, or if the relative overhead from some simple PHP includes is so small it's not worth worrying about in all but the most extreme cases. If doing PHP is going to kill my site on the shared server, I'll just work with static pages however I need to.

I'm willing to benchmark this myself, except I don't even know where to start...

 

[SrWebDeveloper]

Using PHP is more efficient than using SSI because SSI is still forking a separate CGI process where PHP is not, assuming PHP is integrated as a module on the web server, not run as a CGI.

You'll have to run benchmarks to confirm as each platform has its own performance issues but those are the facts and logic dictates that's the right answer for most setups (Apache/PHP with SSI enabled for .shtml only so it doesn't parse all your files when some do not have SSI directives).

-jim

 

[Makosuke]

Ahh, that's a good tip about SSI forking new processes, though I'm not sure how the fact that my host runs PHP as CGI affects that.

I did, however, discover the ab benchmarking tool, which I have used to run some tests and answer my own question.

Using the stock 10.5 install of Apache with PHP enabled, on localhost to minimize latency issues, running 1000 requests sequentially (no concurrent requests, since that's sort of a different test), I got the following results:

Bare HTML page of about 30K: ~0.5ms per request
Same page run through the PHP parser with no logic: ~1.8ms
Same page with one PHP include: ~2ms
Same page with two PHP includes: ~2.2ms

So the speed penalty would appear to be about a factor of 4 versus bare Apache, plus about 0.2ms of additional work for the extra filesystem hit to do the include. These numbers were pretty repeatable, and based on the CPU use graph Apache was taking all of a single CPU to do it, so those probably translate pretty well into CPU-seconds.

Now, figuring out what that's going to mean on a live host running PHP as CGI, and with mod_gzip doing whatever sort of caching it does is the next step (if I'm understanding the documentation right, which I'm probably not, it tries to do some automatic caching on PHP requests).

I've tried some remote queries on a live shared server, but I'm not sure if I'm reading which part of the time breakdown maps to the processing and which is just latency correctly. Going to have to see if I can figure out how to run ab on the server and have it request the correct domain's files from localhost--I'm assuming it's going to require manually feeding it an HTTP request...

 

[haravikk]

If efficiency is your target, why not write a PHP script that generates the page, then stores it as static HTML? So you'd use the PHP script to update the site, but end-users would view static HTML files.

I mean it would obviously depend where you really intend to take the site, as there's a lot of neat stuff you can do with dynamic content, but if you don't need any of it then I'd steer clear of using it except as an admin interface for generating static content.

 

[Makosuke]

Interestingly, I asked support at my host, and they said that SSI is going to be a little faster (presumably due to it not being called as an external process). They didn't have any hard numbers on relative speed, but said it was more like a factor of 2 than 10, which is good to know and something of a relief.

haravikk--that was of course one of the options on my list, but with probably a couple thousand pages a regular rebuild wasn't at the top of my list of things I wanted to do on a shared server. There's also the fact that this particular site's CMS is an older Perl module that builds static files; I don't believe I'd be able to run it server-side, so I'd either be rebuilding the entire site offline and reuploading every x days or having some weird hybrid of built static files run through a second build server side.

Were I more adept I could probably build some kind of on-demand caching system that used .htaccess files to redirect as needed, but if it's just a 2x penalty do do some simple includes, doesn't really seem worth it.

Incidentally, in testing, the client-side slowdown on a live page for switching from static to dynamic was about 20ms out of maybe 200-250ms for the total request, which is quite reasonable.