I collected some data I thought would help, and I’m glad it won’t be needed now, but I thought I’d better mention it in case things ever get slow again.
Please pass it to whoever does tech stuff. Thanks.
When things got so slow last week, there was erroneous conjecture that went something like this: Even though posting was very slow, it was just because a lot of people were viewing things.
Since I was having an impossible time just viewing things I knew that probably wasn’t true, so I ran a simple test.
I had two browser windows open. One was a simple view of the MPSIMS list. The other was a duplicate (cntrl-N). After one hour I refreshed the duplicate.
This showed 2 things:
the number of posts during the hour was less than a dozen.
the number of views during the hour was just over a hundred.
In other words, people were not able to view either.
The bottleneck was not too many views clogging the system, it had to be something else. Presumably whatever the recent IP switch fixed.
Since we now have that “something else”, I just want to be sure we can lay the “too many views” conjecture to rest. And the next time (knock wood that there won’t be a next time) we’re tempted to blame too many views, the tech guys can use the quick method above to test for that.
I wrote a mondo-sarcastic response to this, but I’ll just keep it to myself for now.
Instead, I’ll simply correct you. The problem is not too many simultaneous views, but rather too many attempted simultaneous views. That wouldn’t show up on the counter, of course.
I assure you that the site administration is not making this shit up as it goes along, nor is it lying to you.
The problem is what we said the problem is. The number of database inquiries overwhelms the combination of software/hardware/tweaks that we have available.
Querying any database requires cycles, memory, and recovery of data. That is, the three things that define how quickly data is returned by the server are processor type and speed, RAM type, quantity, and speed, and disk speed. When polling is done remotely, the width of the pipe (data passthrough rate) is a fourth factor in determining the overall speed of the server.
Improving any one of the four will decrease response time. Jerry and the boys are working on the pipe, so that might help–the faster the server can receive and return data through the network, the more resources it will be able to dedicate to processing queries.
But the weakest links will determine speed, ultimately. The fact remains that the more queries the server receives, the harder the server has to work, even if those queries are simply views and not writing any data to the database. And when it works harder, it works slower.
I tried to explain this to my coworkers. But they have trouble understanding that the more tasks they shove into my inbox, the slower I get anything done.
I think you failed in attempting to skip being mond-sarcastic. If you want to offend me, you certainly have done so. In the future, I won’t try to help, and I dare say a few others may be scared away as well.
Please note, I was not saying the problem was too many views. Check the thread title if you doubt this. The person who said that was Codfire “Well, people may not be posting, but they may be viewing the threads. That causes a server load as well - apparently enough to slow things down this much.” That sentiment was echoed by voguevixen and TubaDiva.
I’m not a programmer. I just saw that what appeared to be a common explanation could be proved false.
I am trying to help here. I did not say anything was shit. I did not say anyone was lying.
I also think that if you look at attempted views, if indeed there is a way to tell that, that attempted views will also not be the culprit. When we had too many attempted view in the past, we would get error pages stating exactly that. Has everyone forgotten that?
So I think it’s something else. When techs find enormous changes on one of our machines, the problem is something that people weren’t looking at.
They will find that some new aide is using the server to sort mailing labels or download photos of the company picnic. Or they will find that the new virus filter is in Debug mode and logging ten messages for every one it processes. Or they will find they ran out of virtual memory and are memory thrashing. Or they have run out of disk space and are disk thrashing. Or they have a dying disk that is putting out more errors than data (which coincidently is what just completely killed the Fathom board for 3 days last week). Or they will say they didn’t think the new modem was set right, or backing up gave it an old set of parameters. Or the processor is too hot when we close the closet door.
Or a lot of other things I can’t recall. It’s always something they hadn’t been looking at. But they can’t see that, won’t even look for it, until they can let go of the last theory.
Then, like the moment of epiphany in “The French Connection”, when the mechanics say “We can’t find any drugs in this car, and we’ve removed everything but the rocker panels.” And some non-mechanic has to say, “What are rocker panels?” Only then do they find the answer.
I’ll try to type this slowly.
[ul][li]We know what causes response times to drop.[/li][li]Attempted views that go unnoticed by the ultimate view counters are part of the problem.[/li][li]The page errors in the past occured under a different software system. The ones that occur under vB are caused by something other than a speed/capacity issue.[/li][li]There. Is. No. Conspiracy. This. Is. The. Truth.[/ul][/li]Manhattan didn’t offend you with his post. He merely said he could have. And I’ll echo his sentiments: I don’t understand why the earlier explanation would be so unbelievable.
The new aide using the server for downloading pictures of the company picnic? Sheesh. Now that’s unbelievable.
Thanks for your help, but to be frank, it wasn’t particularly helpful.