That makes sense. I was only thinking about knowing titles weeks or months in advance. Then they have the potential of being more spoilery.

Personally, I voted to close Spoilers Lite because we were in the middle of the crisis. That was the only reason I voted for it. Now I wish I hadn't.

This is a good point. I'm thinking we should've waited to see what the effect of closing the quote generator before we culled the threads. Because while a lot of them were cut painlessly, this one cannot be absorbed into any other thread on the boards. Also, the net effect on board resources of losing that thread will be nugatory.

Oh well - lesson learned to Not Panic while balancing the need to take Quick Action.

Even after we had the lovely reduction from shutting of the RQG, Kristen encouraged us to close what we could. Our biggest real problem is probably the number of users who use the board. We can't do anything about that, but fewer open threads is still better.

We can't do anything about that, but fewer open threads is still better.

I really don't agree. I haven't seen any proof that the number of threads contributes to excess concurrent connections, and what I learned from digging around in all the code doesn't support it.

Concurrent connections is what the issue, so I think the first Angel Watch'n'Post will be our next stress test. But just last night I figured out why we need to have explicit closes of connections (even though the PHP doc claims one doesn't) and why the ones ita put in weren't working. I think there's a good chance this won't be an issue in the future.

I really don't agree.

We don't get to make that choice -- we've been explicitly recommended to minimise table space.

It also seems to me that the shorter a query runs, the less time the connection is open for, so the fewer concurrent connections there'll be.

But I could be off on that.

edit: Could you explain again why PHP wasn't implicitly closing the connections? I don't have your e-mail with me, and I forget.

I really don't agree. I haven't seen any proof that the number of threads contributes to excess concurrent connections, and what I learned from digging around in all the code doesn't support it.

It only does in the context of more threads offering more opportunities to post, i.e., the more threads there are the more likely the posting and reading volume will go up, leading to more concurrent connections.

ita is right about query length increasing the number of concurrent connections, but I have to ask how much per thread. For example, how much does Spoiler's Lite cost compared to Natter. We don't have any way of measuring that, but I think the value of a few of these low volume threads has to outweigh their cost in increased query times.

edit: Could you explain again why PHP wasn't implicitly closing the connections? I don't have your e-mail with me, and I forget.

My theory is that when PHP is running as a module compiled into Apache, it defers cleaning up resources (like unclosed MySQL links) until the module is unloaded. That's only going to happen when the child process Apache spawns to handle connections goes away, which might never happen, depending on how they've configured Apache.

When PHP runs via CGI, everything is cleaned up after each script is run. But that's much less efficient, so I doubt that's the way it's set up on our host.

I have to ask how much per thread.

The per-threadness affects searches of the threads table only -- front page, message center, probably no big.

But trimming the posts table is a bigger deal -- and once threads are closed a) posting diminishes some, probably and b) they definitely can be archived and removed entirely from the table.

I'd rather we do that before any Angel-rush, rather than after or during.

Hw about if we make spoilage lite a thread with a price on it's head?

Keep it open, but if a time comes when we have to drop something because of rising conections, it's closed.

Was there some sort of consensus as to location of archived threads? I remember discussion as to their being moved offsite.

Too bad we can't set up a duplicate site somewhere with just our archives, no posting.

Buffista Retro: The words that were. with downloadable zip files (Oh, I do miss bbs qwk packets) of threadsucks.

Buffista Retro: The words that were. with downloadable zip files (Oh, I do miss bbs qwk packets) of threadsucks.

Daniel, you do know that everything that's been archived *is* downloadable, right?