Site Performance Discussion

[bikehikeskifish]

The sporadic performance problems are due, most-likely, to sharing our servers with other tenants. Getting our own servers would cost 3-5X as much per year and burn through your generous donations much more quickly. Performance has been very reasonable for the last 6-8 weeks. During the last 6-8 weeks, I have not received any e-mails about database connection timeouts, which I was getting several per week (usually a search engine was the cause) before that - might have been the Tim Thumb virus was at-fault for those timeouts and it definitely did not help performance.

Tim

 

[Tim Seaver]

still slooooooooooooooow

I am still getting a minimum of 45 seconds to over a minute to get any response from clicks on VFTT, so I have to think there is some kind of issue. I notice that the two ADK forums that run on vBulletin don't seem to have any speed issues, so I have to wonder what is going on. Again, not meant as a complaint, just that right now it's that's it's unusably slow ( at least from where I am, with about 7MB/sec broadband).

 

[bikehikeskifish]

"What's new" currently (for me)

16:19:25.181 [595ms] [total 595ms] Status: 302[Found] GET http://www.vftt.org/forums/search.php?do=getnew&contenttype=vBForum_Post
16:19:25.776 [723ms] [total 1198ms] Status: 200[OK] GET http://www.vftt.org/forums/search.php?searchid=357700

Total time is 1793ms, or 1.8 seconds.

Just because 5 boards use vBulletin does not mean they will all perform at the same speed. There are numerous factors involved. Just because you have 7mbps (rated), doesn't guarantee you 7mbps from your computer to the remote resource, and back. Try www.speedtest.net to see your actual performance. That (again) doesn't guarantee you will see similar performance to DreamHost (Irvine, CA) where VFTT is currently hosted.

Feedback, as always, is welcome. I am keeping track. And I do notice that I am not getting any database connection time-outs any longer, It's clearly not a snappy as some other vBulletin sites (that I know are on VPS plans), but it is cheaper too.

Tim

 

[Neil]

This thread is actually now two threads in one. An economy of bandwidth for those having speed issues. I have no delays at all on my end and I'm using dial-up (US robotics 14.4 kbs modem) with Dos 5.0 (just made the big move from DOS 3) as my OS and Netscape 1.0 as my browser.

 

[Tim Seaver]

I get about 7MB through speedtest, but yeah, it doesn't mean much. The difference is seconds versus minutes - I don't expect the sites to be the same, but the gap is pretty huge. It would be interesting to see what others are paying for their plans and who they are using.

 

[bikehikeskifish]

Do you have any way to trace the requests and the timing? If you use Firefox, I recommend TamperData. That will give me some information on what you are doing and how long it is taking. Performance has been a second or two at most for me today, and I received additional feedback with similar numbers in a PM.

I have plenty of information about other sites, how much things cost, etc. Keep in mind that when we signed up for the plan, Dave, Alan & I were willing to fund VFTT for a year while we decided on the on-going costs. The amount each of us was willing to contribute added up to enough to pay for the new vBulletin software, a new license, purchase a new domain, and cover one year of shared hosting. The Virtual Private Server plans will jump the annual hosting bill by at least 3X, more if we get one big one or two little ones (vBulletin essentially is partitioned into a web application written in PHP and a database (MySQL)). Right now, we share both the web server (Apache) and the MySQL server with many other tenants.

Darren was paying $600+ / year for the old site and over 17 years had dropped over $10K into it.

Tim

 

[Neil]

I was JK about my OS etc. but I have no issues with lagging, timeouts, or generalized slowness on VFTT.

 

[psmart]

I've found posting and even opening threads is slowed down once in a while, perhaps inherent in my antivirus etc., so that reduces the effort I'll make to post.

Every click is now taking 30-60 seconds. That definitely takes a toll on site activity.

(No, it's not my connection or PC. I'm experiencing the same problem from multiple computers and locations. Other sites are normal.)

 

[DSettahr]

I haven't had a problem at all with this site. Strange that it would only be affecting some users.

Have you guys tried doing a traceroute on the site?

On a windows machine:

1. Press the windows key and the r key at the same time to bring up the run dialogue.
2. Type in "cmd" (without the quotes) to bring up the command console.
3. Type in "tracert vftt.org" (without the quotes) to initiate a trace of the path information takes between views from the top and your computer.

The traceroute pings each stop along the way to check the connection speed. If you notice a significant increase in the ping speed before it gets to vftt.org, the problem lies somewhere along the path that the information is traveling, and not on the website itself.

 

[Ed'n Lauky]

Every click is now taking 30-60 seconds. That definitely takes a toll on site activity.

(No, it's not my connection or PC. I'm experiencing the same problem from multiple computers and locations. Other sites are normal.)

Each click is about 2 seconds for me.

 

[Kevin Rooney]

Each click is about 2 seconds for me.

Same here, which is the similar response time as always.

 

[Tim Seaver]

Pretty much what psmart said - I have had the same issue when using a mobile devices and hotspots to try and access the site, from quite a few different locations. Odd that not everyone is affected.

 

[Neil]

I haven't had a problem at all with this site. Strange that it would only be affecting some users.

Have you guys tried doing a traceroute on the site?

On a windows machine:

1. Press the windows key and the r key at the same time to bring up the run dialogue.
2. Type in "cmd" (without the quotes) to bring up the command console.
3. Type in "tracert vftt.org" (without the quotes) to initiate a trace of the path information takes between views from the top and your computer.

The traceroute pings each stop along the way to check the connection speed. If you notice a significant increase in the ping speed before it gets to vftt.org, the problem lies somewhere along the path that the information is traveling, and not on the website itself.

I did this and there were 21 hops. Total time was roughly a half a second. Two of the jumps were a lot longer than the others (instead of 3 mS something like 250mS) Makes you wonder how the heck it works at all.

 

[bikehikeskifish]

I have 24 hours of "performance monitoring" data. From my house near Manchester, NH, over Comcast 15mbps cable service, I get:

"New Posts" - 320 req, avg 2.190, median 1.666, 90% 2.565, min,max=1.490,45.658
"Q&A NE" - 320 req, avg 3.401, median 3.192, 90% 3.894, min,max=2.871,11.585

These times include downloading all javascript, images, background images, etc. Your browser may cache these items and not actually download them each time. I sampled the above two requests, on a 2-minute interval, 1 minute apart. Any more and I'd be considered a DoS attack.

If there is network latency, changing hosts may or may not help. If the hosting server is the problem, then a VPS solution will improve things. The results above are consistent with a shared server. the 45 second searches are a result of the max connections reached/exceeded at the SQL server.

As mentioned earlier, a tracert would help identify where the bottleneck is.

Aggregate

Requests

Tim

 

[bikehikeskifish]

I'm splitting the "2 quiet" thread. Performance discussion here, health and vitality there.

Tim

 

[RollingRock]

Quick response from this end. I have Windows XP and no problems. There is only so much one can do to make EVERYONE happy!

 

[Tim Seaver]

FWIW, here is what a trace route gave me:

Tracing route to vftt.org [208.113.225.149]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.0.0.1
2 1 ms <1 ms <1 ms dslrouter.westell.com [192.168.1.1]
3 10 ms 9 ms 9 ms d-burl-bng2-64-223-110-1.ngn.east.myfairpoint.ne
t [64.223.110.1]
4 9 ms 10 ms 9 ms burl-lnk-70-109-168-21.ngn.east.myfairpoint.net
[70.109.168.21]
5 10 ms 10 ms 10 ms burl-lnk-70-109-168-134.ngn.east.myfairpoint.net
[70.109.168.134]
6 16 ms 16 ms 16 ms xe-0-2-0.mpr3.bos2.us.above.net [64.124.202.25]

7 18 ms 18 ms 18 ms xe-1-0-0.mpr4.bos2.us.above.net [64.125.25.66]
8 30 ms 30 ms 31 ms xe-5-3-0.cr2.dca2.us.above.net [64.125.24.118]
9 70 ms 116 ms 65 ms xe-2-2-0.cr2.iah1.us.above.net [64.125.30.53]
10 89 ms 89 ms 101 ms xe-2-0-0.cr2.lax112.us.above.net [64.125.25.18]

11 89 ms 89 ms 88 ms xe-8-0-0.mpr1.lax12.us.above.net [64.125.30.30]

12 90 ms 89 ms 89 ms xe-0-1-0.mpr1.lax103.us.above.net [64.125.30.45]

13 89 ms 89 ms 89 ms 64.125.187.174
14 90 ms 95 ms 102 ms 66.33.201.122
15 89 ms 89 ms 89 ms apache2-bongo.caesar.dreamhost.com [208.113.225.
149]

Trace complete.

 

[Lost Dad]

I have found a big difference in the browser that I use. Typically, I use Google Chrome. When I am having speed issues, I switch to IE and the problem disappears.

 

[Kevin Rooney]

I have found a big difference in the browser that I use. Typically, I use Google Chrome. When I am having speed issues, I switch to IE and the problem disappears.

That's interesting. I'd come to avoid to IE like the plague due to speed issues - I'll have to give it another chance.

I use Chrome, and switch it to IE mode if I've have problems seeing a page formatted correctly.

 

[bikehikeskifish]

If you use Firefox, the network connect time is shown with the tab icon as a dark gray circle turning anti-clockwise. Once connected and downloading, it turns green and spins clockwise. I know from work when things are slow, it is often the corporate firewall, and the wait time is all network latency (gray, anti-clockwise). Chrome has a similar scheme.

There is very little chance the browser choice is responsible for 30-60 second latencies.

Tim