I like to read STRAIGHT DOPE but I find access to be uncertain and slow.
I have a fast PC and NTL Broadband.
I’m not very compute savvy so it may be my fault.
If it is my fault what can I do to improve speed of access or do other Straight Dopers have similar problems?
Yes, it’s one of the slower message boards on the net. It must be the server because vbulletin is good software and the board, although large, is far from the biggest I’ve seen. If I was Cecil’s webmaster, I’d be checking out other hosts.
(I wouldn’t put up with it if the content wasn’t so godawful good.)
This’ll be moved to ATMB.
Don’t worry about it, we all suffer from the speed (or the lack of) of the server. There’s just too many of us now and the hamsters can’t keep up.
toscar, it’s not just you. But you can find a lot of company in the ATMB forum.
Yes, I find this board is S…L…O…W.
(You are not the only ones).
This board must be so popular that the “traffic” here slows things down considerably.
[George Burns]
Ever try to shoot pool with a rope?
[/George Burns]
Can you hear the hamsters (lambs) screaming?
Tain’t anyone’s fault but your own if your worrying about it.
if YOU’RE worrying about it …
This message board is hosted “in-house,” by the Chicago Reader, owners of the SDMB and Cecil’s column. We had a major upgrade to the server (meaning a brand spankin’ new, fresh-outta-the-box machine installed) less than a year ago. And just as we expected, demand quickly mushroomed to meet supply—in less than 3 months, we were right back where we started. The same thing happened here that happens whenever desirable goods/services are priced below market value. We’re a victim of simple economics.
Tip: It has been mentioned several times that using the Search function puts a big load on the server.
The courteous thing to do is don’t play with Search just for the fun of it. If you really need to search, OK. Otherwise, browse around or do your searches at odd times when the board is not so busy.
I’m fairly new to the board, so I have no point of comparison, yet I have a feeling that maybe the problem isn’t the CPU power on the server, but rather a connectivity problem - either between the server and the outside world OR between the server and a back-end DB machine (if they are separate) - or a DB performance issue, perhaps accessing remote-mounted disks. Has anyone on the Chi. Reader tech staff looked at this, looking for communication/DB bottlenecks?
Then again, I could be way wrong…
It will work faster if you open your PC’s box and put butter in the hard drive. But it has to be the BEST butter!
The Chicago Reader has multiple T1’s. I doubt it’s a connectivity problem. And the database is maintained on a harddrive physically installed on the server.
When we initially installed the new server, download speeds were frighteningly fast - pages would load in little longer than it took you to blink. Over time - a few months - as people returned to the boards (many had left because the boards got too slow and unreliable) and the database began to grow again, speeds gradually declined and then flattened out to what you see now. Which is still better than it was before the server was installed in November of 2002. Everything says server to me.
But I could be wrong, too.
As I understand from UncleBeer’s post, the Web Server and DB Server are on the same physical machine? If so, the culprit may be Context Switching - every time the web server calls for data from the DB, the web server process/thread (depends on if your a *NIX or windows shop) must be swapped OUT of CPU, and the DB server process/thread must be swapped IN. This can be quite “expensive” - especially on *NIX boxes (and absolutely horrible on Solaris!).
And of course, as soon as the DB starts getting the tiniest bit slower, the Web Server threads have to wait for them, gobbling resources and possibly locking out users waiting for another WS thread.
It may be worth it to see what happens if you put the Web Server software on a separate machine - possibly even a relatively low-powered one. It should free the DB to provide much better performance, which in turn may allow the Web Server software to provide good performance on hardware inferior to what you currently have. Like an old household PC anyone on the staff is about to throw out because it’s only a 1.7 GigaHz box…
Try putting this forward to your tech experts. They may (likely) have thought of and discarded these ideas before, but maybe it can be of help…
Dan Abarbanel
Hey, thanks. I’ll pass this up the line. What you say here “. . . as soon as the DB starts getting the tiniest bit slower, the Web Server threads have to wait for them, gobbling resources and possibly locking out users waiting for another WS thread” sounds like what we often see. And Jerry has said before that he sometimes sees wild swings in resource usage over short periods of time.
BUMP
One week later…
Just wondering, what, if anything, did the techs have to say about my suggestion*?
*Other than “Yes, I KNOW this already!!! God-D&^*it know-it-all newbies!!!”, of course 
Dan Abarbanel
Nothing. To me anyway. I dunno of they’ve had a chance to look at it. The boards, frankly, are pretty low on their priority list.
Wait a minute, Noone Special. You’re saying that if they’re on separate machines, we might speed things up by putting them on the same machine, but if they’re on the same machine, we might speed things up by putting them on separate machines? That sounds like a rather shotgun approach, to me. And while shotgun troubleshooting usually works eventually, it can take a whole lot of time in the meanwhile.
Not at all, Chronos. It was said earlier that web server and DB are on the same machine.
I said (and continue to say) that separating them may do a lot of good, for a variety of reasons that I can go into in excruciating detail if everyone promises not to snore while I pontificate…
Dan Abarbanel