global.php extremly slow

[Exeter]

require_once('global.php');

The execution of this one line takes 380ms on dedicated recent-gen hardware.

global.php is required for session management. I include it on all my pages. Rewriting it is probably not a good idea.

With a ~380ms delay from the start, it is impossible to get into Google's "faster sites". This is a P0 issue for me, which, I think, affects all of us.

What are the best practices for speeding up execution of this one line of code?

[kh99]

I'm not any kind of expert on this but: There's a Server Configuration forum over on vbulletin.com, I believe they can help make sure you have optimal database, php, etc settings. If you have mods you could temporarily disable them and see if that makes any difference, and if it does you might want to rethink which ones you're using.

You probably realize that the "one line of code" hides a lot of work that's needed for each page, and I imagine that a lot of the time is taken up by db queries (if you put your site in debug mode you can see all the queries and how long they take). And there's the possibility of using some non-db caching to speed things up (although I'm not familiar enough with the options to suggest anything).

[Exeter]

I am just wondering what the best practices are. gobal.php does the same thing for every one of us. What takes the time.

I profiled my server with xdebug.

1) It appears the call to php_curl in the facebook connect feature adds 200ms, best case. Every now and then FB is slow, and it takes 1000ms (which sucks).

It's important to have the correct FB certs installed. Otherwise VB will make two calls. Everyone who has facebook enabled should install the certs.

2) construct_navbits adds another 40ms, maybe because it loads the whole vb template system. This could be faster, with some work.

The non vb part of the page gets generated in less than 50ms (from memory).

Let's see what else we can find.

[setishock]

20, 40 , 50, 200 380, 1000 milliseconds? That's thousandths of 1 second. That's incredibly fast for any software/hardware package. You have to take in to consideration your server box setup.
FSB > The bottle neck of all computer systems. If it's a slow buss then that will slow down data transfer.
Hard drive > Larger HD's have an inherantly longer seek time. More platters, more data, longer seek times. Bust a large drive into smaller drives and dedicate each one to a specific job.
Memory > Too fast combined with a slow FSB can cause congestion on the buss.
Check your northbridge specs. If it's too slow for the rest of the hardware it's time to find another motherboard.
Finally VB4 is clunky. It's pretty quick all things considered but it could be better. The next gen of VB hopefully will take the clunky out of the way it operates.

[Exeter]

Sorry, I do not agree at all with the comment about 40ms not being a long time. Every ms second counts. Wasted cycles are the difference between being able to serve high-loads, or failing.

Also, Google has research out that measures the user's attention in fractions of a second. There's a reason the green zone on the Google Webmaster control panel starts at ~1 second.

I run my instance on recent gen dedicated server class hardware. That does not really matter to my original question. I am looking for best practices to be able to get the best out of my particular set of hardware.

Since this is the VB forum, I don't want to get into discussing network, web server, ... issues.

Fixing the FB cert issue happened to buy me 100ms, which is an eternity. Let's see what else we can find.

[nhawk]

Just because you are running recent gen dedicated hardware does not mean that the operating system and associated server level mods are optimized for the job. Dedicated servers are rarely fully configured by the provider to run at their best speeds. They are almost always configured for generic use. This is especially true of MySQL. I have never seen a MySQL installation that didn't need to be re-done properly.

If you're running a server that you installed the operating system on, and are running the stock configuration then you definitely need to go through optimization. Out of the box configuration is not good for any site.

I run an old dual single core server for my site and page generation time is always between 0.09 and 0.10 seconds. Plus an average page load time (data transfer time) of 264ms.

Take KH99's advice and head over to the support forums on vBulletin.com and ask for server optimization there. Once that's done, then you can look to see if there's any coding problems to be taken care of. But I don't think there are any.

EDIT: I just did a check on the global.php load time on my server. It is 17ms or 0.01723 seconds on an old slow server. So, that definitely points to your server configuration needing optimization.

[Exeter]

Care to share what you did to reach 17ms?

[nhawk]

Originally Posted by Exeter

Care to share what you did to reach 17ms?

Each server is unique. That's why vBulletin.com has someone that helps with server optimization.

But in general, this is what I do on every server I manage. Everything described helps with speed in one way or another.

1) Make the server PCI compliant. While this is for sites that process credit cards, it is good practice for any server.

2) Install and configure mod_evasive for apache - this will stop people and bots from sitting there with the F5 (refresh) key held down.

3) Close all ports that aren't needed on the server via the server's firewall. If no firewall is installed, install one.

4) Install and configure fail2ban on the server. With some log monitoring it will become obvious what rules to enable or add to the system.

5) Enable KeepAlive on your server.

6) Enable CSS and Javascript compression on your server.

7) Configure the server to use anywhere between 25% and 50% of your memory for MySQL. This is VERY system dependent. Use caution if you don't know what you're doing.

8) Install and configure xCache (or some other PHP caching system if you have a preference).

9) Move all graphics and CSS stylesheets to the file system. This is a preference of mine only because I don't like huge databases stuffed with graphics and other items that are technically static items.

10) Get to know how the server runs. Watch for spikes in page generation time and server load and then investigate what caused them. Then take action to stop it from happening again. Even if it means banning IP addresses or adding a new rule to fail2ban.

That's the best advice I can give without being 'hands on' with the server to see what's going on. I hope that helps.

Again, take KH99's advice and visit the server configuration forum on vBulletin.com and ask for a server optimization..
https://www.vbulletin.com/forum/foru...-Configuration

[Exeter]

Thanks for the detailed answer. Between this post and the server form I have a couple of things to try.

I still think there are perf gains to be had in global.php.