http://www.webpagetest.org/result/111121_02_289QT/
http://www.webpagetest.org/result/111121_AQ_289QX/
I run vBSEO, see this thread: First byte slowed with vbseo big time. | vBSEO
Now when I turn off vbseo the time improves to A/B.
I’ve had my web host working with me for about a month to try to fix slow queries but no help.
Could you guys please advise me what else I can do to improve this?
My website link: www.47r-squad.com
I also run cPanel Varnish, EdgeCast CDN, xcache.
Also can I have my CDN added to known list?
cdn.47r-squad.com
edge.47r-squad.com
Your CDN servers should be correctly identified since they are on MaxCDN/NetDNA. Looking at the test results it looks like all of your content is served from www.47r-squad.com though which is why you are failing the CDN check: http://www.webpagetest.org/result/111121_02_289QT/1/performance_optimization/#use_of_cdn
Out of the technologies you list, only xcache could possibly help your first byte times for the base page (dynamic content).
There are a couple of posts about optimizing for vBulletin (I believe Marvin has done a lot of work on it) but it essentially comes down to turning off everything that isn’t critical for your site in the options. Beyond that you just need screaming fast database access.
Something like New Relic can give you some great insight into where the time is being spent (I expect it is a LOT of database queries, each of which completes reasonably fast but they probably add up).
Hi there, thanks for replying.
edge.47r-squad.com is on edgecast cdn, could that be added so it detects it?
Would you go with MyISAM or InnoDB for database?
I’ll take a look at New Relic, but it seems to be a very expensive piece of software.
New Relic has a 14-day free trial for the pro version and steps all the way down to a fully free (with less detail and data retention level). Hopefully you would be able to find a lot of issues to address in the trial period.
Edgecast should also be detected. All of the resources that were detected as not being served from a CDN were coming directly off of your www domain.
For a smaller database with not much concurrency you probably won’t notice much difference between MyISAM and InnoDB but if you have a lot of concurrent reads and writes you probably want InnoDB for it’s row-level locking (where last I checked MyISAM has to lock to full table for writes).
Hmmm, I signed up but didn’t get a free 14 day trial…
I was finally about to set this up and here is what it came up with:
http://img141.imageshack.us/img141/8469/slowqueries.png
Any suggestions on how I can tune up DB? or anything I can tell my web host to improve those times?
Hard to say without knowing the database architecture. It looks like a lot of the long operations were write operations so if you are using MyISAM you could be bumping into concurrency issues and could get a boost from a switch to innodb.
I hope that the user table already has an index on uid but if not you might need to add one there.
Those are just the traces from specific queries that took a long time, what do the graphs look like under app server->overview? Is database the main contributor to time or is it something else? What is the reported average response time?
Looks like it might be vBSEO mainly, but that’s tied into the database.
Here is a screenshot of overview: http://img221.imageshack.us/img221/2002/overviewm.png
Hi IcEWoLF,
I’ve been following your thread here and at vBSEO forum with great interest. I don’t have anything helpful to add as far as troubleshooting or optimization, but your issue has prompted me to perform a test of my site, which is similar to yours in the add-ons used (vBSEO, vBadvanced, but I run the old vB3.8.x instead of the new vB4.x).
I did 10 tests with vBSEO enabled, and 10 tests with vBSEO disabled. When comparing the results of the 2 median runs, the TTFB was only just over 10 milliseconds slower with vBSEO enabled.
I’m also on a VPS.
The good news is that new relic is seeing average times in line with what WPT was seeing (400ms) so it’s somewhere inside of the application and not in the web server (number of clients, etc).
I wouldn’t make too many assumptions based on just the overview page about where the performance issues are coming from. The slow diagnostic reports are all for vbseo.php but that may be called asynchronously and not in the end user path (and may be called infrequently).
If you click on the overview chart it will take you to a breakdown of what entry points (php files) are contributing the most to the average times and if you click on one of those you will get more details (select the performance breakdown after you click on one of them). It should give you some visibility into where the time is going. You can get even more visibility if you’re willing to instrument the code (new relic lets you time individual functions as well but doesn’t natively know about the internals of v-bulletin).
It’s a great dev tool but it does start to get into the inner workings of the application itself.
All of that said, it doesn’t look like the bulk of your time is coming from database interactions or external web service calls so you may be able to improve things just by tuning PHP itself. Are you already running APC or some form of opcode cache? If not, you should. That alone should help pretty significantly.
I currently run xcache.
So that’s good that is not in the database.
I will ask my host to see if there is any tuning they can do on php.
Isn’t xcache better For vbulletin than apc?
Sounds like you have that part under control. I don’t have any experience tuning vbulletin so I’m not sure which works best. I tend to use APC as my first choice just because it is being rolled into PHP itself at some point but xcache, eaccelerator or APC all do roughly the same thing.
Hi Marvin, I’ll keep everyone updated.
I am having few things looked in new relic, next step is to give APC or other opcodes a try other than xcache and see if they play nice.
I am also forward a request to see if there is any optimizations we can do on php.
I also checked few tests on my old web host (wiredtree) and same configs/plugins but with WT it ran 400 m/s lower than the current host.
I’ve just looked briefly through the test history, too, and I’ve noticed that on and before Oct 17 you were using LiteSpeed web server, while on and after Oct 19 the test results show you using web acceleration by Varnish. Are you still running LiteSpeed at this time, or not any more?
That’s an old test.
I haven’t used litespeed since the first week of October I believe.
I no longer host my website @ wiredtree. I currently use Unixy.net
I am being recommended to move to nginx from apache, not sure if this is really going to improve my first byte time…
If your bottleneck is in the apache processing then it will though I didn’t think that was included in the New Relic times. If vbulletin is expecting Apache though it might be a painful move (.htaccess files don’t work in nginx, they have their own rules structure).
I will say that if it’s an option, Nginx is WAY easier to scale than Apache and is freakishly fast (particularly if you are running php in php-fpm mode and not cgi).
Vbulletin and vbseo are now compatible with nginx from what I’ve heard.
Friend of mine runs satelliteguys.us and he is on nginx.
He runs vbseo+vb4 like me. His site is really fast.
Well crap, looks like I may not be able to go Nginx, the reason is because I won’t be able to run cPanel with it…
Also:
“We’ve optimized the server well but it seems like vbseo is pure PHP code that needs to optimized or perhaps rewritten. Looking at the vbseo.php code it does seem a bit sloppy and has a lot of room for improvement.”
