I have like no idea what exactly makes the loading time so long und thus let the SQL Server "go away".
Probably the overall resource usage, so when there are too many requests -which still are only a few- at once, SEN says "no".
The search appears to be a factor, yet by far not the only one. By far.
A shame.

Ideas?

I've noticed that when I go to the SCP while loading other pages on SEN in other tabs, all the other tabs end up in mysql errors. Supposing that helps at all. I haven't really seen any other direct cause other than search.

Doesn't viewing all of a user's posts or topics also do this? Or is that just technically a part of "search."

That's part of "Search".

Or, well, put the boxes on the left side of the PMs. Their current position is awkward and prone to misclicks.

I get that even when I open a few topics at once. The first request loads, then the rest error.

Ah I haven't had that issue without going to the SCP directly first (or clicking on forum reports). I normally open a few topics simultaneously without any issues.

I still can't edit. It sucks.

I would assume that, for example, if devlin opens the scp at the same time as farty opens a topic-tab, farty receives an error due to the server being too busy with devlin's request.
But I also doubt that.
One request won't (or at least shouldn't) eat up that many resources.

However, I do not really know.

Servers are able to handle thousands of simultaneous requests before refusing service (see DoS/DDoS attacks).
If anything this behavior would be triggered by bad code, but not by lack of resources.

That's why I've doubted that, Nude.

Are there any looping functions in the codes? Might be worth watching for.

If you hit the search button in the shoutbox with a shout selected to be saved, it saves the shout and does not perform the search. Found out after the third unwanted save in a row by me

Yea or that. I was also going to suggest making certain fields collapsible but I have a feeling moving the check box might be easier to code.

Would it be possible to get a /squelch command in the shoutbox, or would that be too much work? I know as moderators and shitake you higher-ups wouldn't be able to ethically use it in most scenarios, or would have to turn it off occasionally for reports and whatnot, but yeah. Would be pretty badass for us lowbies to have. Maybe a store item, or a regular+ feature, if it turns out to be too much or something.

It's an idea I've had lurking around for a while, and I'm buzzed enough now to ask but not so drunk I forget to ask/can't make sense while typing. Thoughts?

On the topic of fixing the horribly broken stuff in the shoutbox, I think that /a should be fixed to function as a "last whisper" rather than "last shout", as its current functionality is retarded.

Really retarded.

On another note, could we get "/w [name]" to have an alternate as "/m [name]"? I find that most users on battle.net do not use /w and prefer /m as their means of messaging a user, so having this mirrored on a starcraft site only makes sense.

... I was just about to reply to poison's post with both of these glaring issues.

Well then, what he just said.

Studied different form submits and the data they send, using Firebug.

Looks like if any of the shoutbox checkboxes are checked -- any forms submitted whose names are of the form save_shout[id] -- then the form assumes that you're saving a shout. What it should do instead is check to see if the POST data includes a field called save, whose value is "Save shouts". (When you click a submit button in a form, the button itself is sent as a form field. Only the submit button that you clicked is sent, so the server-side code that handles forms with multiple such buttons -- like the Global Shoutbox -- can check the POST data and see which button was used to submit the form.)

Use /r.

/r is actually extremely bad. Someone can whisper you during a conversation and intercept your confidential shout to somebody else. Raccoon does this shit all the time, sending random whispers to try and intercept /r.