Thread size limit

[The Snide Sniper]

Recently, I did some stress tests on the site. I would take down the site to reduce noise, then use a script to make 2 requests per second to a random page of a particular thread. Doing this with Double Post (the largest thread on the forum with almost 700 pages) resulted in a database load of 287.8 MHz. Meanwhile, the FG first post thread (with only 4 pages) only had a database load of 30.9 MHz. This confirms my suspicion, that large threads have an outsized impact on site performance. Because the database has the most expenses associated with it, I will need to start limiting threads to around 100 pages or so.

With that in mind, I would like to ask how this should be implemented. Should OPs be moved to the new threads? Should they be left alone? What should be done with respect to the scorekeeper?

[ratammer]

Summoning chridd to this thread to answer about the scorekeeper.

I think OPs shouldn't be duplicated because it will mess with the count of threads like Count to a Million.

[Jplus]

Sorry for the somewhat off-topic question, but what does the unit MHz mean with respect to database load?

[The Snide Sniper]

Megahertz. Millions of CPU cycles per second.

[chridd]

I could probably make the scorekeepers work with multiple threads, but I have something else going on between now and Sunday so I might not have enough time until then. (There was a multi-thread game on the old forum, so in theory it shouldn't be too hard.) I'd likely treat the OP of the new thread as if it were the next post after the last post in the old thread.

For Count to a Million, I'm wondering if we should wait for the end of a page so that pagetoppers stay on the same numbers they otherwise would be on?

[LingEarth]

I'm wondering if you could actually split the current Count to a Million thread at the beginning of page 401, so it's divided at a nice round number?

[chridd]

this is a test

[chridd]

Whatever happens, I'm going to have to tell the program a new thread ID and page number to start on.

If someone just starts a new thread (without moving any posts), then that's not going to cause problems before I do that, and once I tell it the new thread ID it should just work, though if there are posts in the old thread after the new thread is started, I'll have to manually delete them. The OP of the new thread will get points as if they'd posted in the original thread.

If you split the thread such that earlier posts stay in the old thread and later posts move to the new thread, I think that will just mean that the program won't see any new posts until I fix it, and again it should just work once I do fix it. It'll be easier for me if the split is at a page boundary.

If you split the thread such that later posts stay in the old thread and earlier posts move to the new thread, I think what will happen is that things will appear to work at first but it'll start sometimes missing posts at the end of pages, giving incorrect scores.

Moving individual posts between threads is likely to cause problems.

The "Show scores from (start/end) of page" feature likely won't work correctly; that's something I'll need to fix at some point (maybe not immediately, since it's lower priority). There's a bookmarklet that will take you to the scores for the thread you're currently viewing. I'll have to fix that manually (would be similar to starting a new game).

This all assumes that we want to keep existing scores. I could also treat the new threads as if they were new forum games with the same rules (less likely to cause weird issues; probably a bit more work on my part assuming nothing would go wrong doing it the other way; also the way I have things set up if some threads start over multiple times there will be a lot of duplicated code).

[The Snide Sniper]

New rule has been added. Threads have been split.