The Lotus Cars Community banner

1 - 15 of 15 Posts

·
Registered
Joined
·
12,193 Posts
Discussion Starter #1
Randy,

I hate to make this complaint, but I just can't bear it anymore... I love EliseTalk, and this is an unnecessary blemish, so here goes:

PLEASE get a new web host. Whoever you're with has the SLOWEST database server IN THE WORLD !!!

Ok, so maybe I'm over-dramatizing it, but the database seems to be a bottleneck. You can sit there and manually count posts as they load from the db.

If it's too much headache to go to a new host, maybe complain to your current host to improve your db performance?
 

·
insert clever title here
Joined
·
7,702 Posts
I havn't noticed any speed issues; pages load pretty fast for the amount of info on them. There ARE a couple options that can be tweaked - the number of threads per page, and when viewing a thread, the number of posts per page (you can set this under the User Control Panel, Edit Options, Default Posts Per Thread). Both of those could be decreased to speed page loads.

Transio, what speed are you connected to the internet at?
 

·
Forum Founder
Joined
·
29,083 Posts
Yes, it's pretty fast from my end. I see occasional slow downs, but it's when one of my other sites is being slammed. Perhaps it's an issue between you and the server?

Can you do a tracert to elisetalk.com and copy/paste it?
 

·
Registered
Joined
·
143 Posts
I'm seeing the similar sorts of slowdowns on busy days -- the posts kind of load 1 by 1, maybe about 3 or 4 per second. I don't think its my DSL downlink, as I get pretty consistent speeds to everywhere else. I assumed it was your outbound connection maxing out.

Here's my traceroute:

1 adsl-64-168-158-73.dsl.snfc21.pacbell.net (64.168.158.73) 9.832 ms 10.119 ms 10.809 ms
2 dist1-vlan60.snfc21.pbi.net (216.102.187.130) 9.859 ms 10.473 ms 10.249 ms
3 bb1-g1-3-0.snfc21.pbi.net (209.232.130.28) 9.560 ms bb1-g1-1-0.snfc21.pbi.net (64.161.124.225) 10.912 ms bb1-g8-1.snfc21.pbi.net (216.102.176.193) 9.716 ms
4 bb2-p4-0.snfcca.sbcglobal.net (151.164.190.190) 132.454 ms 10.187 ms 11.074 ms
5 ex1-p12-0.pxpaca.sbcglobal.net (216.102.176.234) 11.271 ms 11.131 ms 11.838 ms
6 as2828-xo.pxpaca.sbcglobal.net (151.164.89.62) 12.429 ms 11.486 ms 11.994 ms
7 p5-2-0.RAR2.SanJose-CA.us.xo.net (65.106.5.177) 11.849 ms 11.118 ms 12.104 ms
8 p6-0-0.RAR1.LA-CA.us.xo.net (65.106.0.17) 24.768 ms 22.675 ms 23.611 ms
9 p0-0-0.MAR1.LA-CA.us.xo.net (65.106.5.6) 29.951 ms 22.261 ms 24.355 ms
10 p1-0.CHR1.LA-CA.us.xo.net (207.88.81.166) 29.778 ms 22.290 ms 22.875 ms
11 206.111.14.122.ptr.us.xo.net (206.111.14.122) 35.945 ms 22.730 ms 38.145 ms
12 64.3.104.26.ptr.us.xo.net (64.3.104.26) 25.360 ms 24.157 ms 23.122 ms
13 GI50-Bess-GLC.ibsinc.com (66.113.92.132) 28.522 ms 23.569 ms 22.873 ms
14 pcbstandards.com (66.113.66.66) 196.087 ms 186.900 ms 197.549 ms

I also did this:

# time wget "http://www.elisetalk.com/forums/forumdisplay.php?s=&forumid=3"
--10:17:21-- http://www.elisetalk.com/forums/forumdisplay.php?s=&forumid=3
=> `forumdisplay.php?s=&forumid=3.1'
Resolving www.elisetalk.com... done.
Connecting to www.elisetalk.com[66.113.66.66]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 189,462 [text/html]

100%[=========================================================>] 189,462 28.17K/s ETA 00:00

10:17:28 (28.17 KB/s) - `forumdisplay.php?s=&forumid=3.1' saved [189462/189462]

real 0m7.743s
user 0m0.010s
sys 0m0.010s

Those sorts of results are very predictable. Seems like that KB/s number is limited by your outbound connection, because my inbound connection is ~150KB/s.

Did you give any thought to that zlib.output_compression idea? Its a great way to trade off CPU for bandwidth (it uses CPU, and gives you increased bandwidth) so it may or may not work for your configuration.

Steve
 

·
Forum Founder
Joined
·
29,083 Posts
I know it is inevitable that I get ANOTHER dedicated server. :) Perhaps I will do it sooner then. There are some things in work that will create more traffic for the server this site is on, and it's near it's limit in terms of bandwidth.

I will look into it.

The site uses mod_qzip now. I will look into that too.
 

·
Registered
Joined
·
143 Posts
sometimes mod_gzip and mod_php don't play nice together, and you won't be getting compressed output (because there are two competing output filters)

The easy way to tell if you're getting compressed output is to do this:

- Get a "modern" browser like Mozilla. (just double checking. :)
- Request a page, and save it to disk.
- Compare the size of the file you just saved with the size parameter in the HTTP logs.

If you're running compressed, you'll see that the size the logs report is much smaller than the actual file you just saved to disk.

Steve
 

·
Registered
Joined
·
12,193 Posts
Discussion Starter #7 (Edited)
At work I'm on a T1. At home, DSL. I have the same issue from both locations. Here's my traceroute from work:

Code:
  1    <1 ms    <1 ms    <1 ms  10.1.1.1
  2     2 ms     2 ms     1 ms  192.168.254.1
  3     6 ms     5 ms     5 ms  192.168.254.33
  4     5 ms     6 ms     5 ms  miamfllr1m6-ge-0-0-0-141.ip.epik.net [216.22.64.205]
  5    12 ms    14 ms    12 ms  jcvlflnj2m6-so-4-0-0.ip.epik.net [216.22.67.230]
  6    18 ms    17 ms    36 ms  atlngamq1m6-so-3-0-0.ip.epik.net [216.22.67.254]
  7    17 ms    17 ms    17 ms  atl-bb1-geth0-2-0.telia.net [213.248.80.157]
  8    47 ms    35 ms    36 ms  dls-bb1-pos0-1-0.telia.net [213.248.80.70]
  9    56 ms    57 ms    57 ms  chi-bb1-pos2-0-0.telia.net [213.248.80.25]
 10    72 ms    93 ms    99 ms  xo-peering-02031-chi-bb1.telia.net [213.248.84.26]
 11    75 ms    71 ms    83 ms  p5-0-0.rar2.chicago-il.us.xo.net [65.106.6.137]
 12    66 ms   266 ms   255 ms  p1-0-0.rar1.dallas-tx.us.xo.net [65.106.0.34]
 13   102 ms   114 ms    91 ms  p6-0-0.rar2.la-ca.us.xo.net [65.106.0.14]
 14    91 ms    91 ms    92 ms  p0-0-0.mar2.la-ca.us.xo.net [65.106.5.10]
 15    91 ms    91 ms    91 ms  p14-0.chr1.la-ca.us.xo.net [207.88.81.170]
 16    91 ms    91 ms    90 ms  206.111.14.122.ptr.us.xo.net [206.111.14.122]
 17    91 ms   109 ms    99 ms  64.3.104.26.ptr.us.xo.net [64.3.104.26]
 18    92 ms    92 ms    92 ms  gi50-bess-glc.ibsinc.com [66.113.92.132]
 19   168 ms    95 ms    99 ms  pcbstandards.com [66.113.66.66]
EDIT: Incidentally, I know for a fact that the issue is not the connection speed. I'm connecting fine and the header loads immediately, but the posts load one at a time: POST - pause - POST - pause - POST - etc. That is indicative of a database issue in vBulletin, because each post is displayed in its own table as a direct child of the body element, so they will display to the user as soon as they are retrieved by the web server from the databse... it's easy to notice with vB.
 

·
Registered
Joined
·
1,579 Posts
The speed looks pretty good to me now. I got really poor performance a few weeks ago, but it's much better now. I'm not sure when it improved, I only really think about response times when they're bad.
 

·
Registered
Joined
·
143 Posts
transio said:
EDIT: Incidentally, I know for a fact that the issue is not the connection speed. I'm connecting fine and the header loads immediately, but the posts load one at a time: POST - pause - POST - pause - POST - etc. That is indicative of a database issue in vBulletin, because each post is displayed in its own table as a direct child of the body element, so they will display to the user as soon as they are retrieved by the web server from the databse... it's easy to notice with vB. [/B]
This is not necessarily true, when the HTML is formatted in tables. Many/most browsers are smart enough to display entire table *rows* as they arrive (partially) but not to display entire *cells*. Thus, if the outbound data rate were very low, you would see exactly what you're seeing, because that your browser is displaying them in a "smart" way.

Thats not to say you're not right, its just that its not as conclusive a diagnosis as you describe.

Steve
 

·
Registered
Joined
·
12,193 Posts
Discussion Starter #10
slacy said:
This is not necessarily true, when the HTML is formatted in tables. Many/most browsers are smart enough to display entire table *rows* as they arrive (partially) but not to display entire *cells*. Thus, if the outbound data rate were very low, you would see exactly what you're seeing, because that your browser is displaying them in a "smart" way.

Thats not to say you're not right, its just that its not as conclusive a diagnosis as you describe.

Steve
Let me expand upon this. Browsers can display entire rows if there are no cells with a colspan attribute set. vBulletin displays each post in a <table> element as a direct child of the <body> element. That will ALWAYS display each table as it loads, regardless of the browser. That has nothing to do with my point, though.

My point is that because the banner (static content) loads instantaneously follow by delayed loads of text-only posts (which are dynamic databased content), one can with high certainty determine that the database is the bottleneck. If the connection speed were the bottleneck, then there would be a couple seconds of "white space" before the banner loads on reload of a page, while the HTML for the banner is being loaded.
 

·
Forum Founder
Joined
·
29,083 Posts
That also might lend itself to the idea it's not a bandwidth issue, but a server hardware one. Like an old server with a slow CPU and not enough ram. Hmmmmm
 

·
Registered
Joined
·
220 Posts
Or a memory leak in your PHP interpreter or SQL implementation. I was getting "out of memory" errors when clicking on thread links the other night. Allocation sizes looked large, but not unreasonable, and the number of users on the board was low (unless you were getting slammed on another forum the server hosts).
 

·
Forum Founder
Joined
·
29,083 Posts
I know about the memory leak, it's a function of the kernel now loaded. I need to upgrade, which is on my quite-long to-do list. :)
 

·
Registered
Joined
·
220 Posts
I'll be sure not to whine until after the LA Auto Show, then. :D
 

·
Registered
Joined
·
12,193 Posts
Discussion Starter #15
Randy Chase said:
I know about the memory leak, it's a function of the kernel now loaded. I need to upgrade, which is on my quite-long to-do list. :)
You sound overloaded. You should have a partner ;)
 
1 - 15 of 15 Posts
Top