New Hosting - Init. Connect. & Download faster, but TTFB slower. Why?

I just moved from a VPS to another VPS at different hosting company in the hope to improve what was already good. However, at the moment the over all load time of a page is pretty much identical to what it used to be. What puzzles me a bit is why my TTFB is now slower when the Initial Connection, and also the Content Download, are both noticeably faster?

Any ideas as to why this is, and suggestions on how to address this, would be greatly appreciated.

[FONT=Arial Narrow][COLOR=Navy][COLOR=DarkOrange]||[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=DarkOrange]||||||||||||[COLOR=DarkGreen]|[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=DarkGreen]|||||||||||||||||||||||||||||||||||||||||||||[COLOR=Black]|[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=Navy][COLOR=Blue]|||||||||||||||||||||||||||||||||||||||||||||||||||||[/COLOR] - URLJET
[/COLOR][/FONT][FONT=Arial Narrow][COLOR=Navy][COLOR=DarkOrange]||[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=DarkOrange]|||||||[COLOR=DarkGreen]||||||[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=DarkGreen]|||||||||||||||||||||||||||||||||||||||||||||[COLOR=Navy]|[/COLOR][/COLOR][/FONT][FONT=Arial Narrow][COLOR=Navy][COLOR=DarkGreen]||||||||||||||||||||||||||[/COLOR][COLOR=Blue]|||||||||||||||||||||||||||[/COLOR] - SERVINT[/COLOR][/FONT]

Orange - Initial Connection (Now Faster)
Green - TTFB (Now Slower)
Blue - Content Download (Now Faster)[hr]
P.S. Gzip compression on both servers is likely identical as the compressed files have the same sizes.

What platform does the code run on (Apache/PHP)? What you are seeing is likely a difference in the tuning of the application layer serving (if it is PHP then the PHP/Apache integration). Since it is a VPS, do you have full control over that part?

If it is PHP, make sure php-apc is installed, also check to see if they are both integrated with php the same way (mod_php, cgi or fcgi). For dedicated/VPS I usually like to run apache with mod_php because I don’t have to worry about multiple different user accounts like you do in a shared environment and it can be somewhat faster than cgi (particularly with apc running).

Pat, thanks for pointing me in the right direction (as always).

The site is a vBulletin-based forum , so yes, it is PHP. The server runs Apache. The old server used LiteSpeed plugin, which I’m not certain is needed, but I will test the site with and w/out it on the new server, too.

The VPS has just one site on it, so I can chose any configuration that suits the site best, w/out worrying about negatively affecting another site.

I’m now comparing the Apache options enabled in the old vs new VPS. The following is a brief list of the options that are enabled on one, but not on the other VPS:

EAccelerator for PHP
IonCube Loader for PHP
Mod Security
Zend Optimizer/Guard Loader for PHP


Should I disable the Mod SuPHP and CGI on the new server, and enable some (or all) of the options of the OLD server listed above?

I wouldn’t blindly enable all of the modules unless you know you need them (IonCube looks like it’s for loading obfuscated code for example).

Is PHP running as a CGI or mod_php? I expect the bulk of the difference is coming from EAccelerator and you can choose to continue using that or switch to APC instead (from looking around EAccelerator may be a touch faster but APC is more standard and is being integrated into PHP itself).

Most of the others are only needed if parts of your site actually need them (well, except for mod security which is usually a good idea to have installed).

Pat, how can I determine that?

php_sapi_name - is probably the most reliable way to tell since it is coming from the actual executed code.

Pat, I’m not sure how to use that information. But when I go to WHM > EasyApache (Apache Update) > Exhaustive Options List, in the new server I do see check-marks in front of Mod SuPHP, and CGI, but in the old server these two options did not have check-marks.

Should I disable those two in the new server?

Yep, My guess is that those are used to run PHP as a CGI script (and changing the user account that runs it).

For using php_sapi_name you’d just need to create a small php file on your server and hit it from a browser. For example, create myinfo.php with the contents:

echo php_sapi_name();

Drop it somewhere on your server that you can reach it from a browser and then visit in a browser and you should get a page that tells you what mode PHP is running in.

Pat, the returned value is: apache2handler

Sounds like it is running as a module. Enabling EAccelerator (or APC) should improve the base page times (make sure to hit it a couple of times to let the server-side cache populate).


In the mean time, I removed check-marks from in front of Mod SuPHP and CGI. I’m now at the end of creating a new build, which option should I choose?

I’m not clear of about the Apache suEXEC option. The default value is ON. Should I leave it as is, or should I change it to OFF?

You should be able to turn it off since PHP isn’t running as a CGI.

Sorry, what is the list of options you have available? The PHP version should be the latest that is supported by v-bulletin (I would imagine the latest 5.x that you can pick).

Thanks Pat very much for your help and time.

I didn’t install eAccelerator, I just disabled the two above mentioned options, Mod SuPHP and CGI, which were not enabled on my old VPS anyway.

The reason I didn’t install eAccelerator was because I just noticed that while it was installed on my old VPS, it wasn’t being used, at leased I didn’t see it being enabled in one of my control panels (VBSEO control panel).

In the above mentioned control panel, I see 4 options:

  • none
  • memcached (Supported)
  • APC Cache (Supported)
  • XCache (Unsupported)
  • eAccelerator (Unsupported)

The option that was being used, was “memcached”. I switched it to APC for testing, but I saw no difference.

XCache and eAccelerator are marked as unsupported, which I believe simply means that at the moment those are not installed on the VPS. However, I’m not even sure if enabling/disabling these cache-type options within this (vBSEO) control panel has any effect on anything. I just tried to set it to “none”, and webpagetest still showed me that files were being cached just fine.

I don’t know what to try to improve to bring the TTFB to the speed it was at the old VPS. I may submit a ticket to see if the new host can do something about it.

memcached and APC cache are different beasts. APC should automatically improve the performance of your PHP code which should most directly impact the TTFB (and you should enable it).

Memcache can be used by various components to cache data but each component needs to know about it and how to use it. If v-bulletin supports caching to memcache then it would be a good idea to enable it and configure it in v-bulletin.

The other variable at play is going to be your database. Did you migrate the database when you switched VPS as well? I know a lot less about tuning those but for something like v-bulletin it is going to be important as it usually has to run a bunch of queries to generate the pages (and those will also go against the first byte times).

Derek M, ServInt tech support, went out of his way to install and properly configure LiteSpeed on my new VPS, and that did the trick! Now it’s working as expected. I’m a happy camper :slight_smile:

Pat I appreciate your feedback, suggestions, and your taking the time to help. I’ve learned several things in the process.

[color=#FF0000]BEFORE: TTFB 266 milliseconds[/color]

[color=#FF0000]AFTER: TTFB 175 milliseconds[/color]

Just for illustration of the huge impact the LiteSpeed web server had, please compare the TTFB of the base file on the above Before & After screen shots. The other files are static content being served via CDN, so disregard those.

Pretty impressive - looks like it was god for a full 100ms (> 30% faster).

Yes, very impressive how LiteSpeed improved it. I used LiteSpeed on my old server, too, so the 100ms is not an improvement of the new VPS versus the old VPS, but there does seem to be some improvement. It’s hard to tell exactly how much, but every little bit helps. :slight_smile: