There's another thing we could do that might help, which is enable page caching again. We tried this back in December, but there were complaints that the Message Center wasn't updating. The conversation runs from here:

DXMachina "Buffistas Building a Better Board" Dec 7, 2002 8:37:23 pm PST

to here:

ita "Buffistas Building a Better Board" Dec 7, 2002 9:28:23 pm PST

Right now, if you're paging through a thread, then hit the back button, rather than just showing you a cached version of the last page you looked at (as it did at WX), the system goes back to the database and requeries the database. This is another potential drain if you hit the back button (or the forward button) a lot.

DX, that breaks the refresh key. That's why I disabled it before. I really, really, want to work out the right way to do it, because ... that's a big key.

Also breaks the message centre, which I'd rather do explicitly.

Go have a look at the test site and see.

I went to the test site, and it works perfectly for me in Mozilla. It caches the pages unless I explicitly hit the reload button, and then they reload. I see your point about the refresh button in IE. Which is a shame, because otherwise it does exactly what we want it to. There has to be a setting somewhere in IE. Bother.

that breaks the refresh key.

I can confirm that. Damn.

t edit I was testing with IE.

I see your point about the refresh button in IE.

And it's not just the refresh button.

There HAS to be (and I still can't find, despite having looked and asked for months) something that makes the PHP code behave normally. If I click on "Home", I want an updated page. If I hit "back", I want to see the exact same page I just left.

The change breaks re-clicking on home, and breaks refresh in IE.

That's a shitty user experience, and I know there's a way around it. Many PHP sites behave the way phoenix currently does, but not all. I haven't been able to work out what's being done in those.

I have a question -- are we trying to cut down on connections to the database, or queries?

[Because if I'm reading the SQL correctly, then, currently, each query is currently a separate connection, which means than every time someone posts, they're connecting to the database 5 times. I'm not sure if it would be more or less efficient to replace "connectAndQuery" with just "Query" and connect and disconnect only once. It would be a longer connection, but it would be only one.]

they're connecting to the database 5 times

Is there a disconnect before the next connect, or are there five simultaneous connections with each post?

Is there a disconnect before the next connect

Yes. They're not simultaneous.

There is a disconnect after each connect (see code quoted somewhere above -- except when a post is made). That is the change that was made in response to our exceeding concurrent connections.

The previous functionality was the default -- keep one connection per page (since the mysql_connect function only opens a connection if there isn't already one), closed implicitly when the page processing completed.

Now it's closed explicitly after each query, and Kristen reports this has made a difference, though not as much of one as I had hoped.

That is the change that was made in response to our exceeding concurrent connections.

That's what I suspected. Oh well.

The previous functionality was the default -- keep one connection per page (since the mysql_connect function only opens a connection if there isn't already one), closed implicitly when the page processing completed.

Would it improve performance at all to make the end-of-page close explicit, but not open more than one connection per page?

(It feels terribly inefficient to me, to use 5 connections where one would suffice, but, I'm not a server.)