so, except for a few random post county things (which seem to happen everywhere) we seem to be moved in all well and good and things are going smoothly.

you know what's coming....

So, when should we (and by we I mean programmers) take a gander at the wishlist. Programmer requests for cakes, cookies or art projects can be directed to me. Care packages will be forthcoming.

There's also the issue of addressing the performance problems that caused us to move in the first place.

I've been monitoring the system, and looking at the code, and have some information to report on the issue.

Cool beans, Tom!

Also, way back when, I volunteered in a "don't really know all that much about this stuff, but I want to learn" kind of way, and as I've since gone back to school in CS, I could possibly be a little more useful now.

I do have a small request re: the bookmarks list. Is there a way we can do like they do at PF, and add a note indicating why something is bookmarked? Cause I look at my bookmarks list in utter bafflement half the time...

Consuela, that's already on the list.

I've been monitoring the system, and looking at the code, and have some information to report on the issue.

Please share.

Has the board been running a little slow for anyone else today?

A little, Sean, but not bad.

Sorry for the redundancy, then, and thanks!

OK, first of all, I was supposed to set up the mailing lists, but I've been slacking. I apologize for that.

Here's the short summary about the performance:

• The good news is that as far as I can see, the performance problem is strictly a matter of fixing the code. Given our current usage patterns, there's no reason why we can't go back to a cheaper shared hosting solution at the end of the year. Nobody needs to change their behavior.

• The bad news is that because of the way the code is structured, much of it will have to be thrown out and rewritten from scratch to get the most benefit.

Basically, every time the code queries the database, it uses a "connectAndQuery" function. This gets called around 3 or 4 times per page view. The first problem is that database connects are extremely expensive. Every time we connect to the database, mysqld forks a copy of itself, which then goes away when the connection is closed. The second problem is that for every query, the entire table gets loaded into memory, and then the table gets written out as HTML. This is especially bad with threadsucks, where the size of a httpd process can grow to over 40 megabytes. A far better approach is to fetch the result one row at a time, print out a line of HTML, and then fetch the next row.

Unfortunately, the connectAndQuery idiom is used everywhere in the code.