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?

yes, ita, but I also know we can still read some.

I was imder the impression that reading the archives has the same effect on our simultanious connections that reading an open thread does. If this is so, moving them to somewhere else might alleviate some server hits.

Yeah, if we're trying to decrease table space, it seems to me the *first* thing to do is get all the closed threads off the board. And possibly figure out if there's some way to automate the process, since we go through Natter threads hella fast.

We ARE getting the closed threads off the board. But as DX has pointed out, there are some niggly not-automated time-consuming details that slow this process down a bit. But he and others are working that task.