Jump to content

Slower, Slower, Slower


ventura_kids

Recommended Posts

I only run this query twice per week but I'll probably add to the server burden by requesting it more often just so I know I'll have a recent one to load and research before heading out Saturday morning.

You may not do yourself much of a service with that technique, either. I found it is a lot more reliable to simply make a new PQ. Even copies of PQs which haven't run for weeks seem to be handled much slower than fresh un-run PQs (which appear to run almost instantly - begging the question of whether any of these problems with server load have anything at all to do with PQs). I know they are handled in separate batches, but it seems kind of odd to me.

Link to comment
Even copies of PQs which haven't run for weeks seem to be handled much slower than fresh un-run PQs.

I disagree. I enabled an old PQ to run on Friday mid-day. The PQ had last run 19 days previous. It was in my inbox within 5 minutes. Another PQ that had last run 4 days before and I enabled at the same time, took over 2 hours to run.

 

begging the question of whether any of these problems with server load have anything at all to do with PQs).  I know they are handled in separate batches, but it seems kind of odd to me.

Based on the equipment list, I don't think PQs have much to do with the slowdown. The PQs run on a separate box and probably query against the read-only copy of the database. Querying a db is pretty cheap and fast. The slowdown would be with transactions that change the database, like logging caches. Unfortunately those writes also lock up part of the db for a moment, thereby affecting reads, too.

 

I'm sure Jeremy and his lackeys are busy plugging away at a solution, and that's why he hasn't posted here. Either that or he took all our membership fees and left for Tahiti. :(

Edited by Hemlock
Link to comment
Even copies of PQs which haven't run for weeks seem to be handled much slower than fresh un-run PQs.

I disagree. I enabled an old PQ to run on Friday mid-day. The PQ had last run 19 days previous. It was in my inbox within 5 minutes. Another PQ that had last run 4 days before and I enabled at the same time, took over 2 hours to run.

Yep, it seems to vary greatly. I had one which came two hours later and hadn't been run in nearly a week. Which would seem to indicate that a weekly run is not going to come at a consistent time. The poster's intentions of running it daily instead of twice weekly - while making it more likely he'll have one not more than a day old, isn't as good as just using really old copies or virgin PQs on demand.

 

My point being that you can re-use queries which haven't run in a long time, but you are better off not scheduling them at all and using copies which haven't run in well over a week (since the largest scheduled range is a week - and even that doesn't reliably seem to come within minutes which a virgin PQ does).

Link to comment

I agree. The problem with running your PQ daily, in hopes of having a fresh one when the urge strikes you to go out caching, is that many days when you DON'T go caching, your PQ still runs, eating up resources. It's better to not schedule them at all, then when you want to go, enable it for that day only, and disable it after it runs. Most days when I do this, the PQ runs in under 10 minutes. It's only on Fridays that it takes a bit longer, as my post above explained.

 

Plus, as others have suggested, keep 2 or 3 queries set up for your home area. When the urge strikes, enable the oldest one (that hasn't run in the longest time). This will put your PQ higher up in the queue.

 

I think if more people did it this way, the overall performance of the PQs would increase for everyone :lol:

Link to comment

Hemlock, I generally agree with your sentiment. If the system actually worked reliably, that would be peachy.

 

Unfortunately, since you stand a substantial chance of either not getting a PQ or not getting a PQ in a timely manner, the performance and reliability problems lead to a model of gluttony which almost surely makes the underlying problem even worse. You might want the freshest possible data for the weekend, but you're better off with thursday's (or wednesday's) than risk not getting friday's.

Link to comment

I vote for not being able to have PQ's run automatically. Build them and save them but when you actually need one you would have to go in and hit the "run" button. That should cut down on the delivery times. I know that I am guilty of having PQ's run automatically but sometimes don't use them. :lol:

Link to comment
Hemlock, I generally agree with your sentiment.  If the system actually worked reliably, that would be peachy.

 

Unfortunately, since you stand a substantial chance of either not getting a PQ or not getting a PQ in a timely manner, the performance and reliability problems lead to a model of gluttony which almost surely makes the underlying problem even worse.  You might want the freshest possible data for the weekend, but you're better off with thursday's (or wednesday's) than risk not getting friday's.

This is exactly the way that I feel - the current perceived system performance behavior is leading to pathological use of the system instead of using it the way it was intended.

 

Scheduling (in the intent of the original design) is now pointless (because the maximum interval of a week is often too delayed to be reliable, and longer schedules are not possible).

 

And as the previous poster put it, perhaps scheduling shouldn't be allowed at all - just the "triggering" which we are all manually doing.

Link to comment

I used to keep gsak up to date with my weekly pq's. I thought this would help reduce the load on the site and speed things up. I would use gsak as my alternate geocaching.com site and draw my lists of caches to find from there.

But... I kept hunting archived caches. It seems that if a cache went straight to archived status between my pq's, then gsak doesn't get any indication from the pq of that changed status, and it looks like the cache is fine.

oops... maybe this belongs over in the gsak forum. :blink:

These forums are so complicated.

 

Well, back on subject.... When will this website ever be fast enough? B)

Link to comment

Well it's Friday night in the UK. We've found 3 caches today and a DNF. Can't log any of them as we keep getting the 'document contains no data' error. We also wanted to remove the members only from 2 of our caches, and guess what we can't save them either. If it's this bad now, what's it going to be like on Saturday and Sunday?

 

T

Link to comment
Well it's Friday night in the UK. We've found 3 caches today and a DNF. Can't log any of them as we keep getting the 'document contains no data' error. We also wanted to remove the members only from 2 of our caches, and guess what we can't save them either. If it's this bad now, what's it going to be like on Saturday and Sunday?

This isn't due to busy servers, there's something else going on. Can you post a link to one of these caches so I can take a look?

 

B) Elias

Link to comment

Y'all are just running up your find counts? B)

 

Seriously, I am curious if you feel like sharing any statistics on site performance since the upgrade earlier in the week. It sure seems to be running very nicely for me, and I've accessed the site via dialup, home cable modem and a large office network. Hope it stays that way through the weekend!

Link to comment

We really won't know until Sunday. We can do all the testing we want but the true test is a good real-world logging session.

 

However, the weekly cache notifications completed 9 hours earlier than normal, so the database has definitely improved. We still need to bring the second read-only database online so there's more help on the way.

Link to comment
We really won't know until Sunday. We can do all the testing we want but the true test is a good real-world logging session.

 

However, the weekly cache notifications completed 9 hours earlier than normal, so the database has definitely improved. We still need to bring the second read-only database online so there's more help on the way.

Ah, so my newly reported rumor about the second server being solely for the Conejo Valley Cachers could be true! B)

Link to comment

Site has been deadly slow for weeks now. I paid for a premium membership based on the plea for $$$ for servers. I realize this is a busy time, but the site owners would have anticipated that...

 

What is confusing me tonight, though, is that I am not able to look at local caches, newest inmy area, or nearby caches. I am being sent to a search page instead. Perhaps I did not read enough of the logs to discover if this is happening to others as well, but it is very frustrating!

 

Are others running into the same roadblocks?

Link to comment

I've had that happen often too.

It seems to be between a server busy error, and an actual find of what you wanted (timewise) ;) . It sorta times out and goes to the search screen with a quick buffer look of the coords you asked for (even though you actually clicked on a cache name or other item).

Yep

Link to comment

Now its suddenly stoped working again, I am getting the message that states:

 

Server Error in '/' Application.

--------------------------------------------------------------------------------

 

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

 

Source Error:

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

 

[sqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.]

System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream) +742

System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) +45

System.Data.SqlClient.SqlCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) +5

System.Data.Common.DbDataAdapter.FillFromCommand(Object data, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +304

System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +77

System.Data.Common.DbDataAdapter.Fill(DataSet dataSet) +38

Groundspeak.Web.SqlData.SqlConnectionManager.FillDataSet(String sql, Database database, Int32 Timeout) +208

Groundspeak.Web.SqlData.SqlGeocacheController.GetCacheDataByArray(String CacheList, Int64 UserID, Int64 AltUserID) +258

Groundspeak.Web.CustomWpt.Geocache.GetCacheDataByArray(ArrayList CacheList, Int64 UserID, Int64 AltUserID) +345

Geocaching.UI.geocaching_nearest.ProcessResults(OriginWpt OriginWpt) +1174

Geocaching.UI.geocaching_nearest.LoadTaxonomyData(Int64 TaxonomyID) +385

Geocaching.UI.geocaching_nearest.Page_Load(Object sender, EventArgs e) +1145

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +750

Link to comment

Over in the reviewers' forum we are comparing notes, and *none* of us can get to the new cache review queue. Soooo... I am going caching! Hopefully everyone will have some patience as there will be a backlog of caches to review once everything's working again.

Link to comment
Over in the reviewers' forum we are comparing notes, and *none* of us can get to the new cache review queue. Soooo... I am going caching! Hopefully everyone will have some patience as there will be a backlog of caches to review once everything's working again.

Hey! B) That's a great idea! :D

I'm going caching too. :D

 

Have fun, and relax. After all, No one gets out of here alive. :D

Link to comment

I could not bring up my standard start page - all caches not found within 25 miles - all morning. Other basic searches - like by state also timed out. The 'My Account' page worked without prob all morning though.

 

All of a sudden - a switch seems to have been flipped - all is well.

 

This message left as info only and not left as a complaint cause I know things have changed recently.

 

Anyway, thanks for flipping the switch - if that's what it was Things better as of right now.

 

***************************************************************

Oh well, as quickly at things cleared they reverted back to their old ways. Ten minutes later - things seem to be not OK again. FYI again .

Edited by maleki
Link to comment

I have been researching the issues today. It seems somehow the index in the database was corrupted which was causing the problems with slowdowns. I have done some reindexing on the tables and it seemed to clear up. I'll continue to monitor it off and on over the weekend.

Link to comment

Sunday morning.. normally no problem, but it is worse than it has ever been. I can't get my "Filter out finds" link off the "My account" page to work at all. After a while it just gives me the general search page with the drop down for By Postal Code, By Coordinate, By State/Country etc. etc. Choosing any option at all from this page returns a timeout (eventually).

Link to comment

OK, all of you who have been complaining about performance, feel free to join in on the new thread that praises the brisk response time on Sunday. It's amazing how people love to complain, but nobody wants to say "thanks for listening to our whining."

 

I've never complained about the Sunday performance, but want to say that I was thrilled by the way things worked last night. So to those responsible, I say THANK YOU!!!

Link to comment

I'm really peaved about the condition of the site. When logging multiple caches, I normally like to think about my next log while waiting for the page to load. A speady site is going to result in more TFTCs. Slow it down for quality's sake!

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...