[bdcheung]

again.

[The BikeForums Team]

This is an archived thread, you can find the full version of this thread, with images, links and more content here.

Ready to buy? Check out these two online bike stores:
- http://www.nashbar.com (you can find the latest bike nashbar coupons in this thread)
- http://www.performancebike.com (you can find the latest performance bike coupons in this thread)

Cya on the forums,
- The BikeForums Team
- http://www.bikeforums.net

[AllenG]

And the forum is all but unusable again.
Who cares if the search does not work when the forum itself won't?

[chipcom]

How often do I ever complain about performance - it's been pretty bad off-and-on for the last 4 days.

[mrt10x]

I guess I will be forced over to roadbikereview.com again.. for the 3rd week in a row.

[chipcom]

Here we go again, same bat time, same bat performance.

[Brian]

We're due for a hardware upgrade.

[AllenG]

We're due for a hardware upgrade.

Due for, means the site is actually getting new hardware?
Oh thank sweet sweet Kali.

[Brian]

Due for, means the site is actually getting new hardware?
Oh thank sweet sweet Kali.

Well, we've been due for a long time now. But it's actually in the works, finally.

[crtreedude]

Brian - I might have a decent guess of what the issue is. First, just so you know, I was a DBA of databases for 25 years before I started growing trees - and did consulting until about 6 months ago - so I am probably over qualified.

Anyway - there is a correlation between sending out email notifications of thread changes and the system being laggy that I have noticed. Have your database people check to see how long the automatic notifications are taking - I suspect way too long. (they should be under 1 second)

Fixing this with hardware is one way of doing it (perhaps) - especially if you are memory starved. But the other possibility is to change the routine to only do part of the list (i.e. all users that start with A, then B, etc) at a time. This way, the update query isn't tying up the database. Also, since sending out messages is not atomic (i.e. nearly instanteanous) - creating a temp table that is then used to process emails is not a bad idea - that way, processing email can be decoupled from the query.

Yes, hardware might help - but really, it seems to me that you are hitting the wall on a design of the system - and you need to have your background processes looked at.

As I said, I used to do this for a living.