Each thread is identified in the mudcat database somewhat like a "folder" on your computer.

This thread is:
http://www.mudcat.org/thread.cfm?threadid=153958&messages=19

Each time a new post is added, the "message count" is updated, hence the "&messages=19" on the end of the identification.

Each post is more like a "file" (in a folder) on your computer, identified by the thread id and also by the individual post number. The post in which Q asks if the "big threads" affect operation is:

http://www.mudcat.org/thread.cfm?threadid=153958&messages=19#3609703

Site identity: http://www.mudcat.org/
Thread identity: thread.cfm?threadid=15395
Number of posts currently in the thread: &messages=19
Identity of the individual post: #3609703

Individual threads are assigned their "thread number" sequentially, and the posts are also are assigned their "post number" sequentially without regard to what thread they're in, so it doesn't really matter if they're in a short thread or a long one.

Using the "Filter" you can select "All" for how far to go back, but mudcat limits the number of "hits" (threads) reported to approximately 100, so you can't actually go "back to the beginning" that way.

You can search for a thread "too far back" using the form (in your browser address box):

http://www.mudcat.org/thread.cfm?threadid=1

Unfortunately, thread #1 was numbered during setup of the site, and doesn't survive.

The first thread that existed here the last time I looked was ?threadid=4.

Oldest Surviving Thread at Mudcat

There are now at least 15,395 threads, and only the highest numbered 100 (15,295 and later) will be returned if you just use the filter without modifiers, so if you want to "find" a thread with a lower number you have to enter the indvidual thread number. For the next thread, increment the number by 1, etc.

The total size of the database (mainly the number of posts) probably does affect server response.

The total size of the "index" (number of threads) probably does affect server response.

The main factor affecting response probably is the "front end load" on the queue due to the number of requests lined up for the 'cat to reply to at any given time. In the distant past, requests in the queue could time out if traffic was more than could be handled, and the "timed out" hits never got a reply.

Additionally, the server didn't do a perfect job of deleting the dropped requests and the queue got "stuffed" and stopped responding, or responded very slowly, to new requests. The solution then was to "reboot" the server, which cleared the "trash" and restored prompt response.

The ability of the mudcat server to handle higher traffic densities has greatly improved, but it still seems that it's possible to "outrun" the front end if a lot of requests arrive in a very short time. It "looks like" Max has improved things so that fewer "dead requests" clutter up the server and most overloads are automatically resolved and are temporary. It is still possible that the server isn't quite big/fast enough to handle all of the worst-case traffic.

The answer to Q's question is that the size of a thread has no significant effect unless someone tries to load it all at once. I don't check MOABS very often, since there's nothing to tell me whether someone has added something of interest or if it's just the usual babble, and when the subject changes it's very difficult to identify prior posts on the newest subject (how far back do you look) so really believing your latest comment is meaningful is sort of a hallucination. I don't like making "out of context" comments, when I don't at least think I know what I'm commenting on,but others are welcome to use it as they wish.

John