Yes, if your server is limited to something less than 25 connections. Someone will have to wait.
What TubaDiva was referring to isn’t a bandwidth problem, it’s the server handling all the connections. Remember, each connection to a server requires overhead on the servers part, whether transfering anything or not.
So how long does a connection last, when it’s not actively being used? Because it seems to me that after I have my windows opened and loaded, I have zero connections, which would be a very nice thing for the server.
True, when you send the server a request, it has to remember it somewhere until it can be worked off. When the server doesn’t work on it, it’s just an entry in the memory. Putting the data into that list, managing a now bigger list, and then getting it out again means a bit more overhead. Compared to the load on the server from creating the thread pages, I don’t think you could measure it if you tried. So the only restriction would come from the list getting full, because its size is limited.
Its size is limited because there isn’t a point in remembering more requests than the server is able to work off in the next few minutes (or any other time you consider a convenient time-out), not because limiting this list actually would adjust the load factor. When a server is full with 25 requests, it is full. The 25 first people still would have to wait the same amount of time until they get served, even if you would add a 26th. But this one would have to wait longer than the waiting time at which you consider the server being overcrowded, so there’s no point in adding it. The number of requests overflows because of the number of requested pages, not vice versa, and the statistics shows the number of pages wouldn’t change.
But, Ah!, now I understand where the 500 number comes from. Normally the length of that queue is a good measure for the server load because it directly corresponds to the number of users currently waiting for a page. But at some times people are requesting pages faster than the hamsters can work them off. By and by there accumulate more outstanding requests, and eventually the number of queue entries saturates at its maximum. Even if suddenly all requests would cease, the length of the queue would decrease only with the rate at which the hamsters are able to create thread pages. But users keep requesting pages, still adding a steady flow of new page requests, so it indeed can take “for hours on end” to get the size of the queue down again.
Okay, femtosecond, you appear to know what you’re talking about. I’ll trust you. Maybe you can be a little more explicit for those of us who aren’t good at abstract thinking:
What would you imagine the size of the SDMB queue to be? 25? 500?
When the queue is full, which method (many for short time, or ome for long time) would you imagine best facilitates everyone getting access more quickly? By how much of a margin?
When the queue is not full, same questions.
If the above answers are different, is there a simple way for me to distinguish the two situations, without causing more load on the server?
Yeah, I just open one page of topics & right click each one I want to read from there. Then I never
have to back page. I do this for several websites. Netscape 7 is supposed to let you open
several pages on one page.
Usually if I ‘back page’ a form page after its submitted it gives a
message that the post data has to be reloaded. This is Netscape 6
These days if its taking a while after ‘submit’ i copy the page url & open it in another window
& see if my message was posted or not. If so, then I just close the window thats waiting
to give me a ‘thank you’ message’. I don’t know if this is better or not.
Believe me, it wasn’t my intention. 
Maybe I’m just imagining it (but that’s exactly what you asked me to do :D), I think I vaguely remember reading a thread about increasing some server settings to 550. At least it would nicely agree with Tuba’s number, because it’s the same where the number of users currently waiting for a page would saturate.
When the queue is full, it hovers at its maximum because the hamsters can’t keep up with keeping it down. People already have to wait the maximum time to get served and some requests already have to be dropped.
If you pay for a dial up connection, and you really, really need to request a few threads at the time when the server is most busy, and it’s really, really impossible to move your requests to a time where it isn’t, it doesn’t change anybody’s (your’s included) waiting time or odds of having a page time out, if you request them all at once to keep your online time short.
But every requested page adds to the waiting time, so you want to request them when there is the least impact for others. If you don’t want stop reading the board, there’s only one advice that really can make a difference and helps distributing the load evenly:
Try to keep away from the server when it’s busy!
handy, In itself it wouldn’t change the statistics, you trade one page request for another. But it depends a bit on the rate the server load is changing at. If you know the server would be happier to deliver that page a few minutes later (or any other, for that matter), you can help it and have patience. Then again, if you know it will be getting slower, it indeed would help to skip the waiting time for the thank-you and directly load the page it would redirect you to.
However, depending on how your browser handles the cache, there’s the danger that the new thread page gets requested twice. The thank-you page might decide to appear and redirect to it again, after you have loaded the new thread manually, and before you did close the waiting window. Close it first if you open the other window, but like tapping a soda can it doesn’t really change anything, it just gives you something to do while you wait.
I should mention, having been the one to prod this particular hornet’s nest, that I only carry out the above mentioned behaviour when the server is noticeably fast (Being in the UK, most of my surfing is done while the board is not in huge demand). Typically, what happens is that I load a page in a new window and that page loads completely before I have even found another thread title that interests me, so don’t think I’d be tying up more than one server thread at a time anyway; the long delay while I pore over the threads and consider replying is a great big empty space in which I don’t burden the server at all.
Arnold is right though; I’d read less threads in total if I was forced to open only one at a time, but how much less (of my own) ignorance would I combat that way? (plus the idiosyncracies of browsers and the vB software means I would probably be unwittingly responsible for a fair deal more duplicate posts/threads than is currently the case (it hardly ever seems to happen to me at the moment)) there’s also the issue of cost; I am on dialup at the moment, so it makes sense for me to try to do as much as I can offline.
However, I try to respect the board regs as closely as humanly possible; if this manner of surfing is forbidden, I will be sure to comply.
Whoa.
What I’ve learned from this thread thus far:
No, I don’t have any idea how vBulletin and HTML work.
Yes, I am, in fact, even dumber than I thought.
Having said that, I think I should clarify my OP(at this late date). I did think it would be a bad idea to routinely have multiple windows open, so I was initially looking for a “single window” option.
I now realize that the appropriate response to my question would have been, “Stop whining, jerk.”
I would also like to thank everybody for trying to help, and to apologize for starting this mess.
Achernar - from the user point of view, the only way you can tell when you shouldn’t give the server a lot more work to do is when the server is already slow. If threads are being displayed instantly then switching back and forth between windows is not going to make a big difference; of course there is less reason to have a lot of windows open when the server is not slow. It’s almost a (dare I say it?) Catch-22 situation.
Well, the main reason I keep multiple windows open is to keep track of them, but I also want to try to help out the server however I can. I typically only browse the boards off-peak anyway, so I guess I’ll just take femtosecond’s suggestion and keep doing that. I never seem to experience board slowness, so I guess I have no way of knowing when it’s not at its max efficiency. Heh. Thanks!
Okay, I just quadruple-posted in MPSIMS, and I didn’t do it in the manner proposed in my OP.
I tried to post something useless in one of RueDeDay’s threads, and got a “server not responding, server may be busy, etc.” message. I never saw a “thank you for posting message,” and I had no way for knowing whether or not the board server “saw” anything or not. So, I just hit the “back” button, waited a while, and hit “submit post” again. I did this at least seven times.
Eventually, I saw my post in the thread. Four freaking times.
A second window wouldn’t have helped, unless I tried some sort of “end around” to see (with the second window) if the post actually showed up (in the thread, which is opened in the first window).
Did any of that make any sense?
I think I need some posting guidelines here, or at least a way to tell if a post that timed out went through anyway.
Otherwise, I’m going to go with “board’s busy, shut it off and do something else.”
Doesn’t break any hearts, I know.
I just don’t want to mess things up any more than I really have to.
If you click ‘preview post’ after going back to the (apparently) unposted reply, you should be able (in normal circumstances) to see whether your reply has been added.
Thinking again about it, of course it does reduce your waiting time. I’m not sure if a page that will be created so shortly after the post updates the database can be relied on to be current, though.
Exgineer, you already know it, don’t resubmit until you made sure the post really didn’t somehow make it through, clicking preview is the easiest way.
Yeah, I know. I knew when I did it.
I’m having weird connection problems anyway, and I wasn’t thinking when I hit an SDMB problem.
Sometimes it pays to shut the machine down and join your wife in bed.
Okay, recap time.
Stuff that unnecesarily ties up server time:
[ul]- Frivolous us of the “Search” function.
Stuff that might irritate the Mods and Admins:
[ul]- Idiots (like me) asking questions they ought to be able to figure out for themselves.
Anything else?
Trust me, it irritates them much more when folks either don’t ask, or use very… creative… ways to figure things out. The old adage about “no stupid questions” applies here.
I always open several threads at once and browse one thread while the others are loading. That way I only have to wait for the first thread. And there is only one hit to the board per thread. If you always return to the forum list (by using the back button, forum jump, or the link) you will have two hits to the board per thread (one to load the thread and a second to reload the forum list). The load per thread is lower if you open each thread in a new window.
I think that may be browser/settings-dependent DrM; If I post a reply in a thread then click the dropdown next to the ‘back’ button and go back to the thread list, I will (typically) not see my own reply listed in the ‘last post’ column, suggesting that the page I see is reloaded from local or proxy cache.
By golly, Mangetout is right! The back button does not result in a board hit, but reloads a saved copy of the forum page. The forum jump and clicking on the link at the top of the page do result in hits to the board. So, it depends on how you return to the forum list. I still think it’s better to open several threads at once.
It’s erratic, and may be browser-dependent. I know that using Netscape 4, going back to a page will often, though not always, reload it from the server. I’m not sure what the criterion is, though.