Right -- I love the ep titles for their speculation value, but don't think that they're really that spoilery.

Not like discussing a plot point that you've been spoiled for or the advent of a recurring character.

The only thing I can see wrong with knowing ep titles way in advance is that they might give away casting spoilers. An example is the first season Angel ep - Five by Five (gee... could Faith possibly be in that episode?)

This might also be a problem for the upcoming season of Angel if Buffy cast members guest star (pure speculation). If a title was "Xanderiffic", that would be spoiling a guest star.

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.

Anyway, I'd like to see titles allowed, but white fonted in the NAFDA thread.

This might also be a problem for the upcoming season of Angel if Buffy cast members guest star (pure speculation). If a title was "Xanderiffic", that would be spoiling a guest star.

OTOH, the WB's never been keen on keeping guest stars like that under wraps. (Harmony was in the Disharmony promos, Willow was in the Orpheus promos, IWRY was "A Crossover Event," etc.)

I think the fairest idea so far has been to allow ep titles after the promo has aired.

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.