Jump to content

Geocaching.com site update August 18th 2011


Recommended Posts

The www.geocaching.com site has been up and down (mostly down) for most of the morning so far. What's up with that?

 

Taken me 10 minutes to log on yet i was able to get onto forums pretty quick, seems the geocache site has a niggle somewhere as every other web page loads fine, geo it seems is on dial up trying to get on? anyone know why or whats up??

Link to comment

Looks like these silly challenges have ground the servers to a virtual (or should that be "challenge") halt. Ever since the challenge inception we have a "server too busy" message about half the time we want to log in. Now that makes geocaching a challenge.

Link to comment

The www.geocaching.com site has been up and down (mostly down) for most of the morning so far. What's up with that?

 

Taken me 10 minutes to log on yet i was able to get onto forums pretty quick, seems the geocache site has a niggle somewhere as every other web page loads fine, geo it seems is on dial up trying to get on? anyone know why or whats up??

 

The forum is on a seperate server from the main website, and it doesn't have as much traffic as the main website.

Link to comment

It would be nice if the geocaching.com staff would at least provide some official info when the server is basically down for a longer period of time as it is right now. But always when this happens there is only silence from the "officials" :(

Geocaching is no fun this way.

Edited by j-he
Link to comment

I don't know how well gc.com works in other countries, but back here in Holland, me and a lot of contacts and friends aren't able to visit gc.com anymore since this particular update last Thursday.

The site goes online and than offline, more off than on, and when the connection is there, the site is as slow as it can be. Pretty hard to do any caching if it isn't loaded onto your gps, pretty hard to find new caches because the site is down all te time. It is also more than undoable to log any of your visits, to edit a cache you own, or to participate to problems that occur. All we get are server errors. So much for geocaching, how long is this going to take to resolve this issue??

 

Btw, the challanges, what on earth has that got to do with geocaching? Bad idea, drop it. Leave the imagination to the participators, if you come up with ideas like this, there are plenty of challenging caches undiscoverd everywhere and it is still growing. That is what we want.

Edited by Simmie77
Link to comment

I don't know how well gc.com works in other countries, but back here in Holland, me and a lot of contacts and friends aren't able to visit gc.com anymore since this particular update last Thursday.

The site goes online and than offline, more off than on, and when the connection is there, the site is as slow as it can be. Pretty hard to do any caching if it isn't loaded onto your gps, pretty hard to find new caches because the site is down all te time. All we get are server errors. So much for geocaching, how long is this going to take to resolve this issue??

 

Btw, the challanges, what on earth has that got to do with geocaching? Bad idea, drop it.

 

Same in Germany - Site is online - Log On Ok - BUT IT TAKES AGES FOR IT TO LOAD!! Tried to find a couple of caches today - after 30 mins I had two (!!) printed out. They seem to have some major performance problems.

Link to comment
It would be nice if the geocaching.com staff would at least provide some official info when the server is basically down for a longer period of time as it is right now. But always when this happens there is only silence from the "officials" :(

Geocaching is no fun this way.

A number of Lackeys have given up their entire Sunday to work on fixing this issue. Given that they haven't yet fixed it, about the only thing they would be able to tell us here would be "sorry, the site is being very slow". I'm not sure exactly how that would help, or indeed how well such an announcement would be received.

 

Exactly the same happens when a lot of planes are delayed for some reason. TV news turns up at the airport and people say "we haven't been told what's happening". Actually, I don't think that many people care very much exactly what's happening. Most of them just want it fixed as soon as possible. And, amazing as this may sound to some people, I'm going to bet that Groundspeak also wants it to be fixed as soon as possible.

Edited by riviouveur
Link to comment

And, amazing as this may sound to some people, I'm going to bet that Groundspeak also wants it to be fixed as soon as possible.

I'm sure about that as well. What I'm not so sure about is why they apparently haven't made performance their top 1 priority by now. Instead they use their resources on developing "features" nobody asked for.

 

IMHO the priorities should be:

1. Performance and stability.

2. Performance and stability.

3. Performance and stability.

4. Fixing bugs in existing features.

5. Fixing bugs in existing feaures.

6. Improving existing features such as the beta maps.

7. Introducing new features that the community has actually requested.

 

Currently the priorities seem to be somewhat different.

 

btw: I'm sure a message on the main website (like the downtime announcements before upgrades) telling people hat the website is slow because of world geocaching day and resulting unusual server (over)load, asking them to come back another day would certainly be helpful.

Link to comment
IMHO the priorities should be:

1. Performance and stability.

2. Performance and stability.

3. Performance and stability.

4. Fixing bugs in existing features.

5. Fixing bugs in existing feaures.

6. Improving existing features such as the beta maps.

7. Introducing new features that the community has actually requested.

 

8. Introducing new features that the community has not requested, which is what they seem to be doing the most :lol:

Link to comment
A number of Lackeys have given up their entire Sunday to work on fixing this issue. Given that they haven't yet fixed it, about the only thing they would be able to tell us here would be "sorry, the site is being very slow". I'm not sure exactly how that would help, or indeed how well such an announcement would be received.

 

Exactly the same happens when a lot of planes are delayed for some reason. TV news turns up at the airport and people say "we haven't been told what's happening". Actually, I don't think that many people care very much exactly what's happening. Most of them just want it fixed as soon as possible. And, amazing as this may sound to some people, I'm going to bet that Groundspeak also wants it to be fixed as soon as possible.

 

This helps a lot if whe know what is happening, than we can participate to the problems as well and plan a family visit or a day at the beach instead of caching. If we, the members, are kept out of the loop, only frustrations arise. Geocaching is a hobby meant to be relaxing in the first place but in this matter it is far from relaxing. Problems may always occur, and that is no problem at all, but when you keep the members uninformed, discomfort and problems arise.

 

Thank you for this update, keep us informed please.

 

Greetings Simmie77.

Edited by Simmie77
Link to comment

Its a continuing story. We pay, Groundspeak makes a mess of things. We shout. Groundspeak refuses to do something. We pay.

 

Maybe munzee, repudo, terra and all the other caching sites are on to something.

 

It makes you wonder what would happen if ALL premium members decide to pay a week late...

Edited by novw
Link to comment

Major performance issues here too, for many hours now ... but suddenly, its responded quite ok again. And what do I see, the avatars in the logs in switched to just displaying the default "no-user-image" image. I know, as a programmer that looking up images like they done in the logs, is a potential performance-killer. Mabye they shouldn´t have done this change, espacially since onone asked for it.

 

Im sure there is alot more to do with the performance, but removing this avatars from the logs is one step in the right direction.

Link to comment

Major performance issues here too, for many hours now ... but suddenly, its responded quite ok again. And what do I see, the avatars in the logs in switched to just displaying the default "no-user-image" image. I know, as a programmer that looking up images like they done in the logs, is a potential performance-killer. Mabye they shouldn´t have done this change, espacially since onone asked for it.

 

Im sure there is alot more to do with the performance, but removing this avatars from the logs is one step in the right direction.

 

Problem appears to be aspx threads. Not image server. Image server fast. Database fast. Static (not aspx) files from IIS fast.

 

IIS and ASPX threads on same server. Doesn't seem to be a server capacity issue, per say.

 

ASPX thread issue could be lots of things: spinning code, too few threads allocated, back end data access by ASPX slow, spinning, etc. etc.

Edited by Cryptosporidium-623
Link to comment

Major performance issues here too, for many hours now ... but suddenly, its responded quite ok again. And what do I see, the avatars in the logs in switched to just displaying the default "no-user-image" image. I know, as a programmer that looking up images like they done in the logs, is a potential performance-killer. Mabye they shouldn´t have done this change, espacially since onone asked for it.

 

Im sure there is alot more to do with the performance, but removing this avatars from the logs is one step in the right direction.

 

They didn't only remove the avatars. They removed them a while ago, and it didn't help. Now they removed the find count from the logs. Seems like this helped. I'm gonna take a wild guess and say that the count of "challenges completed" was implemented by doing a full table scan, or at least an index count or something. Just a wild guess though, but if I'm right, then it's no surprise that it killed the performance. Beginner's mistake really.

Edited by dfx
Link to comment
It would be nice if the geocaching.com staff would at least provide some official info when the server is basically down for a longer period of time as it is right now. But always when this happens there is only silence from the "officials" :(

Geocaching is no fun this way.

A number of Lackeys have given up their entire Sunday to work on fixing this issue. Given that they haven't yet fixed it, about the only thing they would be able to tell us here would be "sorry, the site is being very slow". I'm not sure exactly how that would help, or indeed how well such an announcement would be received .

 

Exactly the same happens when a lot of planes are delayed for some reason. TV news turns up at the airport and people say "we haven't been told what's happening". Actually, I don't think that many people care very much exactly what's happening. Most of them just want it fixed as soon as possible. And, amazing as this may sound to some people, I'm going to bet that Groundspeak also wants it to be fixed as soon as possible.

 

1) I would hope (and expect) that they would work on Sunday to fix the problems created by the upgrade.

2) I would appreciate an update (beginning with "Groundspeak is aware of the problem and working on it"). Without this I get the feeling that those who created the problem are home having brats and beer without any concern for the gc.com users.

Link to comment

Major performance issues here too, for many hours now ... but suddenly, its responded quite ok again. And what do I see, the avatars in the logs in switched to just displaying the default "no-user-image" image. I know, as a programmer that looking up images like they done in the logs, is a potential performance-killer. Mabye they shouldn´t have done this change, espacially since onone asked for it.

 

Im sure there is alot more to do with the performance, but removing this avatars from the logs is one step in the right direction.

 

They didn't only remove the avatars. They removed them a while ago, and it didn't help. Now they removed the find count from the logs. Seems like this helped. I'm gonna take a wild guess and say that the count of "challenges completed" was implemented by doing a full table scan, or at least an index count or something. Just a wild guess though, but if I'm right, then it's no surprise that it killed the performance. Beginner's mistake really.

 

I was thinking bad execution plan in the DB as well, except wap.geocaching.com is fast and so are lookups from the mobile apps. I'm still sticking to the asp thread pool. :)

Edited by Cryptosporidium-623
Link to comment
I was thinking bad execution plan in the DB as well, except wap.geocaching.com is fast and so are lookups from the mobile apps. I'm still sticking to the asp thread pool. :)

 

I wasn't implying that the DB was clogged up. But if the ASP contained some bad SQL (or the DB had some bad design issues considering the SQL being used), then the ASP threads would be tied up waiting for the DB to come back with a result. Meanwhile, the DB would be free to serve requests from other sources.

Link to comment

Dates are back - a good thing.

Avitars are gone - another good thing.

Cache counters are gone - nothing missed here.

Now just get rid of the dadgum face from in the logs and all will be right with the world.

Edited by k1jy
Link to comment
I was thinking bad execution plan in the DB as well, except wap.geocaching.com is fast and so are lookups from the mobile apps. I'm still sticking to the asp thread pool. :)

 

I wasn't implying that the DB was clogged up. But if the ASP contained some bad SQL (or the DB had some bad design issues considering the SQL being used), then the ASP threads would be tied up waiting for the DB to come back with a result. Meanwhile, the DB would be free to serve requests from other sources.

 

Except the DB wouldn't be "free", it would be swamped with full table scans and the like. :)

 

Hey, anyone want to start a betting pool? :D When it'll be up AND what root cause will be? :D :D

 

Besides, in all honesty, I heard they went to some NoSQL / Name/Value pair DB. Can you even do a FTS in a name/value pair lookup? :blink:

Edited by Cryptosporidium-623
Link to comment
Except the DB wouldn't be "free", it would be swamped with full table scans and the like. :)

 

Hey, anyone want to start a betting pool? :D

 

Impossible to say without knowing the details of the DB setup. It's well possible to have hundreds of requests queued up, waiting for results from the "challenges" count, while other requests fly.

 

And don't hold your breath, you'll never know what was really causing the slowdown.

 

Also, I was wondering how you managed to complete a challenge that's around here without ever having been here. But I see that log is already gone, and it's also a different topic I guess... :rolleyes:

Link to comment
Except the DB wouldn't be "free", it would be swamped with full table scans and the like. :)

 

Hey, anyone want to start a betting pool? :D

 

Impossible to say without knowing the details of the DB setup. It's well possible to have hundreds of requests queued up, waiting for results from the "challenges" count, while other requests fly.

 

And don't hold your breath, you'll never know what was really causing the slowdown.

 

Also, I was wondering how you managed to complete a challenge that's around here without ever having been here. But I see that log is already gone, and it's also a different topic I guess... :rolleyes:

 

On #1 - Sure. Depends on disk layout, user resource management, blocking locks, etc. etc. etc. I agree. The only thing that's odd is, if some requests on the DB are hanging up while requests for cache info via WAP and mobile apps are running fine, then why is the entire site hanging up? The two access paths I mentioned pull both user and cache data. So what data does the "web site" access that these apps do not? Session data? Hrmmmm.

 

Ah who knows. They aren't paying me to dig into their problems and I need a beer.

 

On #2 - I was messing with my wife and sister-in-law. (It's their bricks). Once the joke was over, I deleted it. :)

Edited by Cryptosporidium-623
Link to comment

At approximately 4 PM Pacific Time (GMT -7), we released a site update which should have corrected the performance issues we experienced throughout the day. We'll continue to monitor the site closely this evening, but if you do notice anything not working correctly, please let us know.

 

-Elias

Link to comment

At approximately 4 PM Pacific Time (GMT -7), we released a site update which should have corrected the performance issues we experienced throughout the day. We'll continue to monitor the site closely this evening, but if you do notice anything not working correctly, please let us know.

 

-Elias

 

Thanks for the update

Link to comment

Avitars are gone - another good thing.

Cache counters are gone - nothing missed here.

Now just get rid of the dadgum face from in the logs and all will be right with the world.

 

What's that thingy doing there where the Avatar were put recently???

Oh, that's the 'dadgum' face, I see.

PLEASE REMOVE THAT!

 

And,

PLEASE PUT BACK THE COUNTER!

Link to comment

Another vote to drop the avatar, default or otherwise and put the counter back. Before the site up date on the logs seems things were fine. Update on the logs seemed to really bonked things up. Can't we have the old log listing back? I didn't hear anyone complaining about it.

Edited by jholly
Link to comment

At approximately 4 PM Pacific Time (GMT -7), we released a site update which should have corrected the performance issues we experienced throughout the day. We'll continue to monitor the site closely this evening, but if you do notice anything not working correctly, please let us know.

 

-Elias

Well I guess that update has a bad case of bit rot. Performance is worse than sucks, my world just spins. Performance problems started showing up on the last update. Logs? Hmmmmm. Challenges? Hmmmmm.

 

Edit: seems it is the benchmark side of the site that sucks big time.

Edited by jholly
Link to comment
Then, while writing this post, I discovered that

.minorDetails {font-weight:bold ! important; font-size:12px ! important; color:black ! important}

also works. It shouldn't be necessary to repeat the ! important for each element (I have other commands in Stylish which don't and still work)

Yes, !important applies to the attribute, not to the entire set. It means that the user setting should override the page setting. If the page doesn't set the attribute explicitly (allows the default to apply), then your setting will work without the !important. If it sets the attribute explicitly, then you need the !important.

 

Edward

Link to comment
For Chrome on MacOS, I can edit the file

 

Library/Application Support/Google/Chrome//Default/User StyleSheets/Custom.css

 

in my /Users/<myname> directory. I'm not sure about Chrome on other platforms, but it should be similar.

In Windows Vista, I found a file

 

C:\Users\Edward Reid\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\Custom.css

 

It's empty, so I assume it works the same as the file that niraD found. I can verify that pasting the CSS I posted earlier into this file worked. In fact, it was pretty impressive -- didn't have to reload the page or anything; Chrome just noticed that the custom CSS had changed and applied it before I could even bring Chrome back to the front.

 

Obviously this is custom CSS for all sites. However, the class names in this CSS are specific enough that it's unlikely to be applied anywhere else.

 

I found a discussion thread on the topic of site-specific CSS in Chrome. It said the feature does not exist -- the thread is a couple of years old, but I haven't found anything to say it's outdated. The thread includes a post about an extension which might enable site-specific CSS, though I didn't read the post closely enough to say for sure.

 

I agree with those who want to see the log date more clearly, so I've added CSS for that too. Here's the complete CSS with the log date code added. Oh, and also code to make the log type black ... I really get tired of web "designers" using non-black text just because it's fashionable even though there's no question that lower contrast makes reading harder, and we already read 30% slower on screen than on paper ... oh, you wanted the code instead of the rant.

 

/* Make avatars on logs just totally vanish.
I don't know whether this prevents the download. */

.logOwnerAvatar {display:none}

/* Tighten up the spacing in the log. Readability is not
reduced at all, due to the alternating background colors
and the bold log type. */

.LogDisplayRight .LogText
  {min-height: 0    !important;
   padding-top: 0   !important;
   margin-bottom: 0 !important}

/* Try to stop the View Log from taking up a whole line
all for itself. This occasionally (perhaps 1 log in 10)
causes the View Log to overlap a bit of the log text.
If this bothers you, remove this line. The only cost of
removing it is a bit of extra space at the bottom of
most logs. */

.LogText + .AlignRight {margin-top: -20px !important}

/* Make the log date display larger and bolder. */

.LogDate
  {font-weight: bold    !important;
   font-size:   100%    !important;
   color:       #000000 !important}

/* Well, now it's obvious that the log type is not black either. I'm a man,
I can fix that. http://emmanuelfonte.posterous.com/im-a-man-i-can-fix-that */

.LogType {color: #000000 !important}

/* and the log text too ... */

.LogText {color: black !important}

 

It's very likely possible to do other things like repositioning the log date and the View Log link, but for various reasons those are not as trivial as the above.

 

Incidentally, someone said the year is present in log dates when the log is more than a year old. I'm seeing "December 31, 2010" (can see it now that I've made the date easier to read), so the year is included when it's not the current year.

 

Edward

Edited by paleolith
Link to comment

Yes, !important applies to the attribute, not to the entire set. It means that the user setting should override the page setting. If the page doesn't set the attribute explicitly (allows the default to apply), then your setting will work without the !important. If it sets the attribute explicitly, then you need the !important.

 

Edward

That explains why some work and others don't. Many thanks for the education :).

Link to comment

Another vote to drop the avatar, default or otherwise and put the counter back. Before the site up date on the logs seems things were fine. Update on the logs seemed to really bonked things up. Can't we have the old log listing back? I didn't hear anyone complaining about it.

EXACTLY. This is another case of 'fixing' that which isn't broken. Anyone remember the Google images® debacle?

 

Please, please, PLEASE get rid of the avatars entirely and return find counts. The avatars clutter the page, and I use find counts to determine whether or not a DNF is a warning to avoid a cache (or fix it) and not just a newbie mistake.

Link to comment

Another vote to drop the avatar, default or otherwise and put the counter back.

And another. Removing the counter as a temporary workround to the performance problem is fine: removing it permanently is not as it provides important information.

 

It worked well before so it must be the addition of the challenge count that's causing the performance issue; in which case just display the cache count as it used to be. If I'm looking at a cache page I'm interested in how many caches a cacher has found, not how many challenges a challenger has found.

Link to comment

The performance problem isn't affecting only cache pages: it's also affecting login and managing PQs (but not their production). It's just taken ten minutes to log in, and my request to go to the PQ page is still sitting there after a further ten.

 

Edit: Finally got in and everything seems a little quicker now.

Edited by Alan White
Link to comment

At approximately 4 PM Pacific Time (GMT -7), we released a site update which should have corrected the performance issues we experienced throughout the day. We'll continue to monitor the site closely this evening, but if you do notice anything not working correctly, please let us know.

 

 

I noticed that the date issue occurs again, i.e. the date displayed when looking at the finds of someone is the date when the cache has been last found and not the date when that person has found the cache.

 

Cezanne

Link to comment

The avatars clutter the page, and I use find counts to determine whether or not a DNF is a warning to avoid a cache (or fix it) and not just a newbie mistake.

 

I agree, but what is interesting for that point of view is the number of caches found and not the overall count including challenges, and I fear that the process of splitting up the numbers is time consuming the way it is implemented.

 

Cezanne

Link to comment

Interesting observation. Non-Premium Members complaining about the site being slow. Perhaps a measly $30 a year would help with getting things working better.

 

Did not matter is was / is slow for everyone.

 

Another vote to drop the avatar, default or otherwise and put the counter back. Before the site up date on the logs seems things were fine. Update on the logs seemed to really bonked things up. Can't we have the old log listing back? I didn't hear anyone complaining about it.

EXACTLY. This is another case of 'fixing' that which isn't broken. Anyone remember the Google images® debacle?

 

Please, please, PLEASE get rid of the avatars entirely and return find counts. The avatars clutter the page, and I use find counts to determine whether or not a DNF is a warning to avoid a cache (or fix it) and not just a newbie mistake.

 

I agree the found counts are sometimes a worthy indicator. Not always though - as we all know a huge find count number is sometimes a detriment! So, yes ditch the avatars (even though the look grew on me (I kinda liked it - minus the generic one for blanks) and bring back count totals.

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