Server response time?

[NaterGator]

Woody,
Is something up with the host in Reno or the HTTP server or something? I'm getting response times of ~1-1.5s from the server, but the PHP code execution takes less than 0.2 seconds most of the time. See below:

It looks like the server is queuing up requests and then holding them for a while before it sends out the response? Heck, I'm not even sure, it's definitely funky behavior. J/W if anything was showing up in the error logs or if the Apache configuration got changed/reset or anything
(Or perhaps, better yet, Mud has grown so much that you are saturating your upstream line )
-----Nate

 

[NaterGator]

Woody,
Here is a fairly painless way to cut down on at least one of the uncacheable server requests: the rotating title image. (No, I'm not saying don't rotate it!) I've seen the source of the rotate.php script that serves the images up, but to be honest it in itself is overkill, and in this case it is not the best approach at all. Why? Because the browser can't ever cache those same images (since, to it, they all originate from rotate.php and Apache doesn't allow it to be cached anyways) so every time the user visits a different page on Mud their browser sends a separate request to the webserver for the contents of rotate.php (which, obviously, change every time it asks for them)

But why have rotate.php in the first place? You're already serving a page from a server side scripting engine which can conjure up dynamic content. Instead, actually insert the relative URI to one of the real image itself. The browser won't care that it changes from page to page; once it's loaded each of them once it will just use them from cache. Doesn't seem like a whole lot from the get-go, but in 100 page views it's approaching a megabyte of unsent data!

So, without further adieu here what you do

Login to your admin cp and go down to "Plugins and Products". Select "Add new plugin". For the product select vBulletin. For the hook (this is really important) select parse_templates. Name it whatever you want, something like "Cacheable banner rotation". Set the execution order to 0. For the code, just copy and paste what's below. Leave everything (even the rotate.php script and the setting in vBulleting about the banner image path) alone. If at any time this code fails, it will fall back to that old method. (K.I.S.S.)

function hasExt( $file, $ext = '.jpg' ) {
     if( strrev( substr( strrev( $file ), 0, strlen( $ext ) ) ) == $ext )
          return true;
     else
          return false;
}
$images = array_filter( scandir( 'titleimage' ), 'hasExt' );
$stylevar['titleimage'] = 'titleimage/' . $images[array_rand( $images )];

There is a callback function which is used by array_filter() to select only files with a .jpg extension. The array is populated with the contents of the titleimage folder, and then cleaned by the callback function. Then, the style variable is overwritten (it is set to 'titleimage/rotate.php' when it is overwritten) to a random jpg image from the titleimage folder (it operates on the same principle as the rotate.php script so that saving a jpg in that folder instantly adds it into the rotation).

All you gotta do then is select "Yes" to make the plugin active and hit Save. Viola, people will start caching the random images and if Firebug is to be believed a average of a 540ms will be cut from the page load time This should persist through future forum upgrades too.

 

[woody]

done

thanks for the suggestion, now to see if it makes a difference!

(I'm on the SLOWEST connection ever right now.....so, a bit tuff for me to notice much...lol)

 

[NaterGator]

It does seem to have helped.

Here's another tree I'd like to bark up

The 'Mud servers are in Reno and I'm in Gainesville, so the latency for connections is like 110ms on average. Mud also doesn't use KeepAlive connections, so I have to re-establish a new connection for every request (I'd say I average 30 per page view)

I understand why you're running the server this way; it's understandable because mud has ~1000 active users right now for example. Currently apache2.2 on Mud is using the prefork MPM. The prefork MPM is fine, but it spawns and kills an entire httpd process for each request. Given the number of requests per second the server must get, it means at any given time the server is using huge amounts of ram just to load enough httpd processes to handle the queue of requests. However, the server is running on a SMP x86_64 based kernel and has multiple cores on which it can execute code, and apache2 has a better threaded MPM called worker which is optimized for servers with high loads and multiple cores. It spawns a a few httpd processes (as many as needed, again) but with a listener thread and multiple server threads. This means that a single httpd process can handle multiple requests from different hosts, yet they all share the same memory inside the process. The savings in memory are enormous, and this allows a server that was bottlenecked by memory to begin to balance out and load the processors more. I've seen people who switch to the worker MPM who find that the memory cost-per-request is 10% or less of what it was with the prefork model. That is huge memory savings.

Using the worker MPM would free up the server to handle more requests per second and allow you to use conservative KeepAlive connections which will speed up page loads. All of which is going to mean a faster browsing experience for the user and a more efficient server.

There is a catch though (there always is). Although PHP itself can be compiled to operate in a threaded environment (I run the PHP5 apache2 module and apache2 with the worker MPM, so both operate threaded) various PHP modules are not necessarily thread-safe. This means that running php as an apache module with the worker MPM can lead to segfaults or memory corruption inside the process. The solution is to run PHP via FastCGI, which executes it in it's own process and keeps it out of the threaded environment. FastCGI is roughly as fast as the PHP apache module.




The end result would mean getting/installing the mod_fcgid package for apache (its in the fedora repos) and using the worker MPM httpd (set it in /etc/sysconfig/httpd, the httpd.worker comes with the fedora httpd package and exists at /usr/bin/httpd.worker), as well as compiling PHP5 with FastCGI support instead of the apache module and configuring Apache to invoke PHP via FastCGI rather than the apache php module.
It would be a good time to build the newest stable version of PHP anyways; building should be easy because PHP will tell you it's configure flags (just run phpinfo()). This would also be a good time to add the flag --enable-inline-optimization when configuring php to build.

It would also be a good time to clean the unused modules out of the apache httpd.conf, which will further cut down on the size of each httpd process.

Once switched over to the worker MPM it would be prudent to double check a few configuration settings in httpd.conf (MaxClients, StartServers, etc) and enable KeepAlive with a 1s or 2s timeout and play around with MaxKeepAliveRequests in the unlikely even that the server can't keep up with the # of requests.



I have a hunch that the aforementioned changes will decrease the memory load on the web-server quite a bit, and by using KeepAlive connections the browsing experience should pick up a notch or two too. Yes Claudia, these are the server upgrades designed to make things faster.

 

[Mendocino]

Could this be one of the resons that I regularly get "page not found" messages in IE7 when accessing MUD? I realize there is a huge amount of traffic here, but I get page not found about 35% of the time I request a link. I also get images that are "shifted" have color issues or are generally unreadable. Its very frustrating.

 

[woody]

I've NEVER had that issue....it's possible that it's something with your router settings (you aren't using a Netgear, are you?) or with your firewall....

 

[Mendocino]

Could be the router, I'll have a look at the settings. As another data point, I have never had this issue on any other forums (although their traffic is less than MUD's). I also notice that the page loads occasionaly come through as the php (I assume) scripting, and then a couple of seconds later "switch" to the appropriate view. ...now I am really scratching my head.

 

[woody]

if it's a netgear, they are notorious for issues on various forums....there are many threads here on the problems, with some possible solutions....

 

[Mendocino]

Thanks. It is a netgear, I'll go search...

 

[Mendocino]

OK, I added a Linksys router upstream from the Netgear, use the linksys for Wirespeed to the house, and the Netgear for the wireless (I have had continual problems with Linksys wireless reliability). All is working well!

 

[NaterGator]

I believe the netgear routers have a weak clock generator and begin to get out-of-sync when repetitive data like 'mud is xferred (nulls seem to do it too)

Bottom line; netgear = teh suck.;

And woody, I've noticed about a 700ms improvement since the banner-loader change Maybe it will cut down slightly on bandwidth usage (which should... what, hold it steady for a week before it grows again? )