ita, Tom, I know this may be the worst possible time to bring any side things up, but I've been very concerned lately with our lack of a filter, especially given the number of resignations we've had.

I know Paul was working on one for us, and then got hella busy with work -- did you ever get anything from him, be it design notes or partial code or anything in between?

Now that you're talking about fundamental code changes, I don't want to just seem to be agitating for what may only be my pet issue. But if there's anything to work with that won't be totally Jossed next week and won't get in your way, I'm willing to do whatever it takes to get a filter going.

I won't even whine any more about how I hate stupid acronymic names like MARCIE. I promise.

It had never occurred to me that filters and resignations might be related.

However, if we agree that changing the underlying mechanism of how the pages are presented is important, I'd like us to scope it before writing new changes. Just so we don't make more work for ourselves.

Filtering is good, and demanded by many people, but I think board health is more important.

Absolutely on both board health and more work. That's why I wanted to check with you and Tom rather than just demanding a filter yesterday. Let me know if/when I can help.

MySQL was originally designed as a database with -very- (compared to something like PostgreSQL or Oracle) lightweight connections. Let's try hard to quantify the difference here before we talk about re-writing whole sections of code.

On the test board, I made a copy of giles.php, and changed a few lines so that one mysql connection is made at the beginning of the session, rather than with each connectAndQuery call. I then ran some benchmarks.

Without the change, index.php took an average of 0.1032 seconds to load. With the change it averaged 0.0813 seconds. (index.php makes 6 connectAndQuery calls).

A slightly heavier page, showthread.php averaged 0.2287 seconds before the change, and 0.1863 seconds after. (it makes 25 connectAndQuery calls).

A threadsuck of a 10,000 post thread took 57.75 seconds, during which the load average on the system went from 0.40 and peaked at 1.78. With the change, the threadsuck took 46.54 seconds, and the load average went from 0.40 and peaked at 1.20.

Not as big of an improvement as I was expecting, but still significant.

It's the fractions that add up when no one is looking (See Office Space ).

Can I just mention now how much Tom Scola rocks the house?

Because he most definitely does.

Right on, Karl.

Not as big of an improvement as I was expecting, but still significant.

And we should be realising them now -- I made those changes here: ita "Buffistas Building a Better Board" Jan 8, 2004 5:14:19 pm PST.

The fun bit will be modifying the queries to return line by line, not multi-record recordsets.

Unless I'm missing someting, I think the changes I made are different than yours, ita. There's only one db_connect per session in my version.

Take a look at gilesSCOLA.php on the test board. The changes I made are surrounded with rows of "@"s.

There's only one db_connect per session in my version.

By session you mean a larger scope than page load?

runs off to check code

Interesting. From the docs ("If a second call is made to mysql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned") the code shouldn't make another connection, just because the command is called again once it's open, and it'll be open in the current code because it's not closed until the implicit close at the end of any page.

Which shouldn't be any different in terms of MySQL load from you opening it at the top of the page.

Perhaps the time saving is because it doesn't do the "check and return nothing different"?