bdcheung
04-21-08, 11:18 AM
again.
Forum Suggestions & User Assistance - Laggy
Bikeforums.net is a forum about nothing but bikes. Our community can help you find information about hard-to-find and localized information like bicycle tours, specialties like where in your area to have your recumbent bike serviced, or what are the best bicycle tires and seats for the activities you use your bike for.View Full Version : Laggy
AllenG
04-21-08, 02:30 PM
And the forum is all but unusable again.
Who cares if the search does not work when the forum itself won't?
Who cares if the search does not work when the forum itself won't?
chipcom
04-21-08, 02:48 PM
How often do I ever complain about performance - it's been pretty bad off-and-on for the last 4 days.
mrt10x
04-21-08, 03:06 PM
I guess I will be forced over to roadbikereview.com again.. for the 3rd week in a row.
chipcom
04-22-08, 01:55 PM
Here we go again, same bat time, same bat performance.
Brian
04-23-08, 08:14 PM
We're due for a hardware upgrade.
AllenG
04-23-08, 08:44 PM
We're due for a hardware upgrade.
Due for, means the site is actually getting new hardware?
Oh thank sweet sweet Kali.
Due for, means the site is actually getting new hardware?
Oh thank sweet sweet Kali.
Brian
04-23-08, 09:11 PM
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.
Oh thank sweet sweet Kali.
Well, we've been due for a long time now. But it's actually in the works, finally.
crtreedude
04-24-08, 05:18 AM
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.
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.