Jump to content

Pocket Query Generation Problems


Elias

Recommended Posts

A number of people are reporting that their PQs aren't generating, especially around the weekend timeframe. I'd like to document what's happening as well as explain the "why" for some of the workarounds that have been offered in these forums.

 

The truth is, there are more PQs scheduled for Thursday and Friday than can be physically run in 24 hours. PQs also don't roll over to the next day, so for example, queries that didn't run by midnight Friday night, won't be scheduled to run on Saturday - they're essentially abandoned until the next week.

 

Groundspeak considers this situation a major problem that must be fixed. Unfortunately, its a very difficult problem for which there are no quick and easy solutions. It will take a considerable amount of time to come up with a scalable solution that solves the problem and minimizes the chances of it reoccurring in the future. We certainly don't consider the workarounds given in the forums as solutions; however, they are good suggestions, and they do work if need to get your query on a given day.

 

The key to the workarounds is understanding how the PQ queue works. This is also documented on the "My Pocket Queries" page, but essentially, the order in which PQs are run is based on the "Last Generated" date, with the oldest queries running first. Its almost a guarantee that a query scheduled for every day of the week won't run on Thursday or Friday, ever. However, a query scheduled for just Thursday, or just Friday should run reliably each week.

 

Another suggestion is to create new queries when you need them. New queries have never been run before, so their last generated date is essentially infinite, so they jump to the very front of the queue. There's still no guarantee when they'll run, but most people report that they get them in about 15 minutes.

 

Again, we do not consider these workarounds as solutions. We know you rely on PQs to plan your caching activities, so these tips are offered to help make sure you get your queries when you need them.

 

Please let me know if you have any questions.

 

:D Elias

Link to comment

I have a suggestion that is totally voluntary.

 

I used to run my PQ,s every day. I found out I wasn't using them all so I shifted to twice a week. In my case thats still probably more than I need. I get them Thursday and Sunday. I am going to move my Thursday to Wednesday and stop my Sunday one. This may lower the load a teeny-tiny bit.

 

I am suggesting that if you don't need to run a PQ on Thursday or Friday then maybe you can not run them on Thursday aond or Friday.

 

This is NOT a permanent solution. It's a little bit that those of us that don't need them can do to help. I understand that as a Premium member you have the right to run a PQ when every you want. I'm only saying that if you don't need them on Thursday and Friday cancel them both or at least one.

 

If you don't want to do this that's fine. This is only a suggestion till things get worked out.

 

Please don't flame the idea. If you don't want to do this or you feel you need the PQs on those days then by all means do so.

Link to comment

Good to see that the problem has been identified and a solution is being worked on. Thanks for identifing the problem for us, so we can adapt. I normally didn't have a problem with my "Thursday only" PQ, but since it just runs on Thursday because that was a day that was convenient for me when I set it up, I'll follow Lapaglia's lead, and I'm going to change it to run on Tuesdays. I need the data, but what day of the week I get that particular one isn't critical.

 

Yes, just Lapaglia and I doing this isn't a solution, but if we all evaluate our needs and move what ones aren't critical for a Thursday-Saturday run to a different day, it'll lighten the load a little, and may help "bandaid" things, making it easier for everyone until the full solution is determined and implemented.

Link to comment
Thank you! I am going to go now and delete the queries I only need occasionally and make room for others. But I'm keeping my local one!

No need to delete them, just uncheck all the days so they don't run until you need them.

Link to comment

I too will make some adjustments. I had already learned the old-fashioned way to stay away from Fridays. It is indeed helpful to know what is going on.

 

But, at the same time...: I have been reading the forums off and on for a year and a half. In that time several suggestions have been made that would make PQs more efficient. None of these ideas have been implemented. Just two ideas implemented would cut my team's PQ traffic in half.

Link to comment

Way back when concerns about Friday bog-downs was only a concern I moved to being a thursday PQ user. Since then I have NEVER missed a PQ when the server was running, I think i missed one when the machine took a crap.

 

I run 2 pq's a week, ill move my found one to Wed. I put it late in the week so that I could take my time logging when sundays were an issue.

 

I kick a PQ through on Fri or Sat every so often. Almost never have to wait more than a few minutes.

 

For me it has never really been broken.

Link to comment

I create my PQ's on an "as needed" basis.

 

When I decide to go caching, I create a PQ for the area im headed and it's usually in my email less than 5 minutes after submitting it. I personally don't see the need to run PQ's every single day.

Link to comment

My guess is the number of PQs being generated is huge. Not that it will hurt, but I don't know what impact, if any, the subset of members that view the forums and that even read the thread would have on helping the issue. I think it needs to quickly have some automated process done to minimize the issue.

 

Any way to somehow identify PQs being generated for inactive members? As a hypothetical example, is there a PQ being generated for a premium customer which hasn't visited the site in 1+ months? If so, maybe email the member and disable the PQ. The member could immediately come back to the site to re-enable the PQ of they need it.

 

Also something to consider is each PQ having an "active period" of say 2 months, and it's automatically unchecked after 2 months, again with an email going to notify the member who could immediately re-active it if they still want it. I think that's how searches within eBay work - you can set them up to notify you for 2 months (or whatever period) and then they no longer generate an email, but remain to run adhoc or be re-enabled.

 

I'm sure the developers and others here could think of some automated scenarios to address the situation.

Edited by Team DEMP
Link to comment
Any way to somehow identify PQs being generated for inactive members? As a hypothetical example, is there a PQ being generated for a premium customer which hasn't visited the site in 1+ months? If so, maybe email the member and disable the cache. The member could immediately come back to the site to re-enable the cache of they need it.

Of course you mean "disable the PQ" not "disable the cache". At first I thought this would be a good idea but you need to remember if someone is *paying* for the PQ's they need not log in to GC.com to use them. So stopping their PQ's is probably not a good idea.

 

I will be moving all of my Thur/Fri/Sat PQs to Tues/Wed.

 

Also, I like WH's idea of only running PQ's when needed.

Edited by Tharagleb
Link to comment

I'll shift my Thursday/Friday PQs to other days unless I NEED them on those days.

 

This is another example where more information would be helpful. If we could see "now processing PQ last run on hh:mm:ss mm/dd/yy on some status page, we could judge whether it is appropriate to modify our requests...and also stop asking "why hasn't my PQ generated yet".

Link to comment
Any way to somehow identify PQs being generated for inactive members?

We do suspect this is happening. My guess is that people have queries they scheduled a long time ago that get filtered into a folder in Outlook or go to a free webmail service that they've either forgotten about, or only check when they need a recent one. We are considering an audit mechanism to try to find these and disable them.

 

As a hypothetical example, is there a PQ being generated for a premium customer which hasn't visited the site in 1+ months?
Also something to consider is each PQ having an "active period" of say 2 months, and it's automatically unchecked after 2 months, again with an email going to notify the member who could immediately re-active it if they still want it.

These are a couple of the audit mechanisms we're thinking about. The key is finding a way to minimize the inconvenience to active users while eliminating as many of the inactive or forgotten queries as possible.

 

This is probably something we'll end up implementing in the near short term. Even if we didn't have the load issues we have now, its probably something we should be doing anyway.

 

:) Elias

Link to comment
What day has the lowest load currently. I only need my PQ's once a week but would like them three times. I am willing to schedule them for just once until the issue is resolved.

Tuesday is by far the lowest day. The order from lowest to highest looks like this:

 

1. Tuesday

2. Sunday

3. Saturday

4. Wednesday

5. Monday

6. Thursday

7. Friday

 

Tuesday, Saturday, and Sunday are all pretty close. Wednesday is only slightly higher. After that, the numbers get really big in a hurry.

 

:) Elias

Link to comment
Also something to consider is each PQ having an "active period" of say 2 months, and it's automatically unchecked after 2 months, again with an email going to notify the member who could immediately re-active it if they still want it.

These are a couple of the audit mechanisms we're thinking about. The key is finding a way to minimize the inconvenience to active users while eliminating as many of the inactive or forgotten queries as possible.

How about a one time unchecking of all PQs for members that haven't logged on in over 3 months, instead of it being an automatic thing that will continue?

 

Or at least see how much it helps clear up the problems before making it constant.

 

That might help reduce the threads we'll be reading every other day from people asking why their PQ was turned off.

Link to comment

Dropped down to running my queries just on Tuesday.

 

Couple of ideas for helping out.

 

Most of the folks I know use Watcher or GSAK for planning caching trips. Both applications keep a separate file to keep track of finds. If you were to make pocket queries that centered 100 miles around major cities and allowed each premium member to select one major city per day that include all caches within 100 miles they wouldn't need to run custom PQ's.

 

Secondly could you set a switch based on last visit. Any PQ for a member that hasn't visited the website in 1 month wouldn't have the query run.

Link to comment
If you were to make pocket queries that centered 100 miles around major cities and allowed each premium member to select one major city per day that include all caches within 100 miles they wouldn't need to run custom PQ's.

I don't live in an urban area and I can't get close to a 100 mile radius without hitting the 500 limit. The closest 1000 that I haven't found only goes out 61 miles.

Link to comment
Any way to somehow identify PQs being generated for inactive members? As a hypothetical example, is there a PQ being generated for a premium customer which hasn't visited the site in 1+ months? If so, maybe email the member and disable the cache. The member could immediately come back to the site to re-enable the cache of they need it.

Of course you mean "disable the PQ" not "disable the cache". At first I thought this would be a good idea but you need to remember if someone is *paying* for the PQ's they need not log in to GC.com to use them. So stopping their PQ's is probably not a good idea.

Yes, I meant PQ's. I went back and corrected it - thanks.

 

Elias has already posted that they are looking into it, but I think as long as there's a notification sent with some time for the individual to respond to, it shouldn't be a problem for a "paying" member. Of course, only "paying" members can generate PQs so that goes without saying :)

Link to comment
Most of the folks I know use Watcher or GSAK for planning caching trips. Both applications keep a separate file to keep track of finds. If you were to make pocket queries that centered 100 miles around major cities and allowed each premium member to select one major city per day that include all caches within 100 miles they wouldn't need to run custom PQ's.

This idea was tossed around a few weeks/months back. Like you mentioned, for me, a PQ of NJ and NY would be fine for me to load into GSAK and deal with. This solution would allow for 50 GPX files (only speaking about the US here) generated nightly one time for any premium member to download or have zipped/emailed. I would completely eliminate any need for individual user PQs for me. At least, I can't think why I would need one.

 

The concern I imagine is that someone could get the 50 PQs and have all the caches for the US. I think if someone wanted to do it, they could do it now without static state PQs, just not as easily, so I'm not sure how much I buy this reason as the main deal breaker.

Link to comment
Most of the folks I know use Watcher or GSAK for planning caching trips. Both applications keep a separate file to keep track of finds. If you were to make pocket queries that centered 100 miles around major cities and allowed each premium member to select one major city per day that include all caches within 100 miles they wouldn't need to run custom PQ's.

This idea was tossed around a few weeks/months back. Like you mentioned, for me, a PQ of NJ and NY would be fine for me to load into GSAK and deal with. This solution would allow for 50 GPX files (only speaking about the US here) generated nightly one time for any premium member to download or have zipped/emailed. I would completely eliminate any need for individual user PQs for me. At least, I can't think why I would need one.

 

The concern I imagine is that someone could get the 50 PQs and have all the caches for the US. I think if someone wanted to do it, they could do it now without static state PQs, just not as easily, so I'm not sure how much I buy this reason as the main deal breaker.

That is why I suggested a PQ around a city. You would need more that 50 queries to get the whole US which would make it harder go get everything. Also having PQ's around the major cities would cover most cachers. Those that can't get there area covered could still run there own PQ's.

Link to comment
This idea was tossed around a few weeks/months back. Like you mentioned, for me, a PQ of NJ and NY would be fine for me to load into GSAK and deal with. This solution would allow for 50 GPX files (only speaking about the US here) generated nightly one time for any premium member to download or have zipped/emailed. I would completely eliminate any need for individual user PQs for me. At least, I can't think why I would need one.

 

The concern I imagine is that someone could get the 50 PQs and have all the caches for the US. I think if someone wanted to do it, they could do it now without static state PQs, just not as easily, so I'm not sure how much I buy this reason as the main deal breaker.

Well, you could probably do it currently, but it'd take a lot more than 50 PQ's to do using the current system. I think Pennsylvania alone would take like 8 and I'm sure California and some others would take more. By the time you got it all figured out and ran them all, the data in the original ones would be stale..........

Link to comment
This idea was tossed around a few weeks/months back. Like you mentioned, for me, a PQ of NJ and NY would be fine for me to load into GSAK and deal with. This solution would allow for 50 GPX files (only speaking about the US here) generated nightly one time for any premium member to download or have zipped/emailed. I would completely eliminate any need for individual user PQs for me. At least, I can't think why I would need one.

 

The concern I imagine is that someone could get the 50 PQs and have all the caches for the US. I think if someone wanted to do it, they could do it now without static state PQs, just not as easily, so I'm not sure how much I buy this reason as the main deal breaker.

Well, you could probably do it currently, but it'd take a lot more than 50 PQ's to do using the current system. I think Pennsylvania alone would take like 8 and I'm sure California and some others would take more. By the time you got it all figured out and ran them all, the data in the original ones would be stale..........

If someone wanted to do it, it would just be the number of PQs needed divided by 5 (assuming they wanted each updated daily) and then $30 for each set of 5 PQs.

 

If they wanted data no older then 1 week, then it would be the number of PQs / 35 * $30. If we assume there's 100 PQs needed, that would be a whopping $90 per year for someone. For the heck of it, double it assuming 200 PQs are needed and for < $200/yr, you could have all the caches in the US and keep them updated.

 

Not a significant investment if someone wanted to do it. So, if you look at it that way, I don't think it's a huge effort or cost, so I wouldn't personally (and again it's not my money) think there's tremendous additional risk in having a PQ by state generated once per night for everyone to pull down vs the hundreds of PQs per area that are probable running each day.

 

Just one geeks opinion.

Link to comment

I would like to point out that having us shift load is a band-aid that simply buys a little time (a few weeks, perhaps). The premium member population is growing daily and they all want to get the one service that they are paying for. This has to be very scary for the database managers because it means their integirty is at stake (i.e. not delivering on purchased goods is dishonest if you know that you cannot deliver).

 

I think it would be worthwhile for the database managers to re-evaluate their attitude about the data. The current preference among them is that we always generate new PQ before we go out caching and toss any data that we have obtained with previous PQs. This particular process forces transmission of the same data for a cache numerous times. At the same time recycling of old data is viewed with disdain and hurdles are implemented to specifically discurage it. Yet this, in fact offers the solution to the problem.

 

If the database managers could assist us in recycling data so that we don't have to repeatedly request the same information over and over again, then the PQ system could be made an order of magintude more efficient. If I had a way, for instance to specifically synchoronize the data for the region that I want to maintain on my computer, then this could be done with much smaller files and far fewer of them. Even now the item that allows receiving only info for caches that have changed in the last 7 days could do this if it included archived caches and ony the logs from the past 7 days. But instead it lack these features and for reasons that have been discussed in other threads, we are left downloading data for every cache in a region over and over again.

 

I also suspect that a significant improvement in efficiency could be obtained if the documentation for using PQs were improved. I have spent time trying to teach others how to do it and it is always amazing how confusing it is to most folks. The change I suggest in the previous paragraph won't have much impact if one does not also inform the users about it and how to use it to stream-line their data.

Link to comment

The once a month confirmation sounds like a good plan. An email gets sent to your inbox telling you to click a certain link to re-confirm you still want your PQ's, if you don't click it within a specified time period, then it gets deleted.

Link to comment

May I humbly suggest that after investigating all the low-hanging fruit like inactive members, that Groundspeak investigates more tools to fine-tune pocket queries which would help to reduce the server load by having the PQs be less abusive like:

 

1) Bookmark lists for a query (watchlists require you to get email)

 

2) Attributes as query criteria

 

3) Easier tools to determine how far out you need to go from a center to pick up a certain number of caches in your PQ - this could be as simple as going to the map and showing the number of caches in 5, 10, 20, 50, 100 mile radius (the default of 100 miles may be too generous)

 

4) All caches I've found (regardless of geography) with activity in the last week - currently the radius limits means people will run multiple PQs to get this.

 

5) Caches along a route (I'm sure you're tired of hearing this one)

 

These have all probably been suggested before as a way to get more refined queries for direct use, and generally people are pointed to GSAK. Once you start using GSAK, you don't really need to use PQ files directly.

 

So people who use GSAK to do a lot of filter work generally aren't tuning their PQs much because there's no longer any point when you've got a tool like GSAK, plus you run the risk of excluding caches.

 

If service availability is an issue, refining the service can make a big difference.

Link to comment
May I humbly suggest that after investigating all the low-hanging fruit like inactive members, that Groundspeak investigates more tools to fine-tune pocket queries which would help to reduce the server load by having the PQs be less abusive like:

 

3) Easier tools to determine how far out you need to go from a center to pick up a certain number of caches in your PQ - this could be as simple as going to the map and showing the number of caches in 5, 10, 20, 50, 100 mile radius (the default of 100 miles may be too generous)

 

How much easier do you need than after making up your PQ and hitting "submit" using the "run this search" link and going to the last page to see how far out it goes?

 

4) All caches I've found (regardless of geography) with activity in the last week - currently the radius limits means people will run multiple PQs to get this.

You've got less than 400 finds, you can still get ALL your finds in one PQ. That said, Jeremy has stated that it might sometime be possible for an "all finds" PQ that would return all your finds regardless of number or status (archived for example)

 

5) Caches along a route (I'm sure you're tired of hearing this one)

 

I believe it's being worked on. I highly doubt it's a simple as flipping a switch because people want it.

Link to comment

We just tried to run some pocket queries. 3 regular queries & 1 preview ( no date set to run) query.

 

The first one we ran "Page" ran and we received it in our e-mail.

The second one "St George" has not run yet.

The third was the preview query "Fredonia" and it showed up fine in preview mode.

The last was "Fredonia" and it has not run yet.

 

When we check the "Manage Your Pocket Queries" page the only one that shows is the Fredonia Preview query. Page has run and been received, but does not show on the list. St George and Fredonia do not even show on the list as being in the queue waiting to run.

 

Any suggestions? Should we re-submit the queries that do not show on the waiting list?

 

John

 

added- This is at the top of the "page" query page "Thanks! Your query has been generated. You can run the search on the nearest cache page."

 

This is at the top of the "St George" query page "Thanks! Your query has been modified You can run the search on the nearest cache page."

 

I ran the Page query first then went back and changed the page for St George and ran it then.

Edited by 2oldfarts (the rockhounders)
Link to comment
We just tried a new PQ and it ran fine. Curious to know if using the browser back button does something funky with the PQs. The queries we tried earlier I did the one named Page nad then used the back button to save typing. The Page query came through but the "list" shows it as being "Fredonia".

 

Would it be better to hit "New Query" for each one?

 

John

Yes. Each query is only going to run once per 24 hour period. Just editing it to change the name and settings doesn't change the query. In the system, it's still PQ#123xyz and won't run again in the same 24 hour period.

Link to comment
May I humbly suggest that after investigating all the low-hanging fruit like inactive members, that Groundspeak investigates more tools to fine-tune pocket queries which would help to reduce the server load by having the PQs be less abusive like:

 

3) Easier tools to determine how far out you need to go from a center to pick up a certain number of caches in your PQ - this could be as simple as going to the map and showing the number of caches in 5, 10, 20, 50, 100 mile radius (the default of 100 miles may be too generous)

 

How much easier do you need than after making up your PQ and hitting "submit" using the "run this search" link and going to the last page to see how far out it goes?

 

Yes, I could but I don't. Why don't I? Because I bring everything into GSAK and do my work there. That's the conflict with on the one hand telling people they can use offline tools to get what they want so that resources aren't wasted on enhancing the online tools, and then on the other hand trying to get them to use the online tools more responsibly. People are not going to ever tune the first tool unless it gives them any benefit in the second (or eliminates the need for a second tool).

 

However, you can encourage them into making more efficient PQs by providing better interfaces.

 

e.g. I think that it should be easier to turn any cache search results into a PQ definition or bookmark list without having to re-translate your searching into the online form.

 

It also seems to me that from the mapping/identify page, it would be great to simply turn that into a bookmark list and attach a PQ to it, or turn the mapping page into an interface for the PQ definition.

 

By making regular web-site features an implicit interface into the PQ definition or bookmark generation, instead of PQs being seen as a separate piece, I think you also create something with greater value.

 

4) All caches I've found (regardless of geography) with activity in the last week - currently the radius limits means people will run multiple PQs to get this.

You've got less than 400 finds, you can still get ALL your finds in one PQ. That said, Jeremy has stated that it might sometime be possible for an "all finds" PQ that would return all your finds regardless of number or status (archived for example)

I can't because of the radius, origin limitations.

 

5) Caches along a route (I'm sure you're tired of hearing this one)

 

I believe it's being worked on. I highly doubt it's a simple as flipping a switch because people want it.

 

For instance, many people have mentioned using date partitions to be able to get multiple PQs, each with less than 500 caches to cover an area. This is a good workaround, but is not necessarily the best way to accomplish their ultimate goals (whatever they are).

 

This thread was about problems with PQ, not the overall customer experience, and I fear we now veer towards the broader idea of meeting customer goals.

 

In that spirit, although off-topic, here are my top four goals (not all are PQ-related) I'd have for any geocaching "support system":

 

1. Be able to have an up-to-date list of caches in my GPSr (currently Mapopolis) and cache page viewer (currently GPXSonar), with the ability to make notes on caches I hunt and easily get them onto the web site (I use GSAK to do all this using the current PQ system and its features).

 

2. Be able to plan trips using computer mapping and make lists of caches to be attempted on those trips based on the maps and reading the cache pages and using local advice. (I use GSAK, MapPoint and the forums here to do that).

 

3. Be able to read caches I've found with recent activity to read the stories. (I do local caches only right now - I do not regularly bring in PQs for my more distant finds, as I haven't had time to construct them)

 

4. Be able to read about recent activity on caches in my area (there are only a handful I haven't found, so this overlaps with #3), including archived caches or caches needing maintenance (I use a macro in GSAK to ensure that caches I've found which are now archived are marked properly).

 

You'll see that my #2 goal is NOT ACTUALLY "finding caches along a route". "Finding caches along a route" is what people here commonly ask for, but usually that's not how I usually think about it - which is why my goal is formulated a little differently.

Link to comment

Yes, I could but I don't.  Why don't I?  Because I bring everything into GSAK and do my work there.  That's the conflict with on the one hand telling people they can use offline tools to get what they want so that resources aren't wasted on enhancing the online tools, and then on the other hand trying to get them to use the online tools more responsibly.  People are not going to ever tune the first tool unless it gives them any benefit in the second (or eliminates the need for a second tool).

 

You've got less than 400 finds, you can still get ALL your finds in one PQ.  That said, Jeremy has stated that it might sometime be possible for an "all finds" PQ that would return all your finds regardless of number or status (archived for example)

I can't because of the radius, origin limitations.

Sure you could, but you'd rather waste your time and the system resources instead of learning how to properly use the system. Hint: You don't HAVE to select an origin/distance, you can just select state(s) instead.

Link to comment

I don't spend a lot of time on the site. I run relatively few PQs - maybe 5 a week, which I always manually trigger.

 

Thanks for the hint - I wasn't aware you could select multiple states or countries. (Because the US does not appear in the country list it's not possible to just select countries)

 

I have selected all states and it appears to be working (if 340 out of 399 found caches are active when I remove the recent activity criteria).

 

Now for the fine tuning to make sure my query doesn't strain the system by selecting all states:

 

Do caches in the UK come under state "None"?

 

How do you find out which state a cache is in?

 

For instance:

 

Headley Ford by The Dundle Dots (GCG18N)

United Kingdom

 

this shows United Kingdom where US caches show a US State name, but United Kingdom (nor any UK counties or divisions) is not visible in the States/Provinces list.

 

What about locationless - is the "state/province" which appears on the summary the state used for the PQ? - no state or province for these appears on the cache page.

 

All this trial and error playing with queries on the site helps to reinforce my feeling that the strain on the system is partially self-inflicted by the behavior encouraged by the design.

Link to comment
Any way to somehow identify PQs being generated for inactive members?

We do suspect this is happening. My guess is that people have queries they scheduled a long time ago that get filtered into a folder in Outlook or go to a free webmail service that they've either forgotten about, or only check when they need a recent one. We are considering an audit mechanism to try to find these and disable them.

 

As a hypothetical example, is there a PQ being generated for a premium customer which hasn't visited the site in 1+ months?
Also something to consider is each PQ having an "active period" of say 2 months, and it's automatically unchecked after 2 months, again with an email going to notify the member who could immediately re-active it if they still want it.

These are a couple of the audit mechanisms we're thinking about. The key is finding a way to minimize the inconvenience to active users while eliminating as many of the inactive or forgotten queries as possible.

 

This is probably something we'll end up implementing in the near short term. Even if we didn't have the load issues we have now, its probably something we should be doing anyway.

 

:angry: Elias

 

Elias -

 

Question - how do you propose to determine if one is 'active' or not?

 

Some have written about 'logging on in 3 months'. But how would that work when most of us are logged on somewhat permanently any way. I don't have to log on at all - just click the link to my home page and go from there. Is there a difference and can it be seen that we are not just passively logged on but at least changing a page or two?

 

I guess you could log everyone off every 3 months to see who logs back on.

 

Someone mentioned unchecking ALL PQ's with a note requesting logging in and reactivating if the PQ is still wanted. I kind of like that idea myself.

 

cc\

Link to comment
Some have written about 'logging on in 3 months'.  But how would that work when most of us are logged on somewhat permanently any way.  I don't have to log on at all - just click the link to my home page and go from there.  Is there a difference and can it be seen that we are not just passively logged on but at least changing a page or two?

CC, the system knows you've access the page through the cookie your browser sends - that's how your profile page shows your last access.

 

You would have to not log a cache under the account generating PQs, not visit the forums as yourself, and not view any page on gc.com as yourself.

 

It is highly unlikely someone could actually be geocaching with only PQs and no visits to the website - unless you were a person who didn't ever log any caches under the account with the PQs.

 

As a previous poster mentioned, gc.com could always send them a notice that their queries would be disabled if they didn't log on within a week, say. They wouldn't even need to re-enable the caches - if they signed onto the web site as themselves (cookie or not) within a week their PQs wouldn't be disabled. If they waited, they would have to re-enabled them.

Link to comment

I have two thoughts on this...

 

1. With respect to disabling PQs... I would suggest caution regarding disabling of peoples' pqs. Consider this: Some people have to rely upon others' computers and/or public systems to be able to log caches. It is entirely possible that someone could be using computer time only to get their PQ down to their machine and just going on their way, with no internet time to be able to actually log the caches. While I see it as strange that this would go on indefinitely, I would suggest giving them more than just one week.

 

2. I have changed my PQ setup, and I think this may help somewhat. Rather than running two querys for all active caches in my area, i have reset it so that I am pulling all caches which have been updated within the last 7 days. What I would appreciate is if Jeremy could make it so that, for instance, archived caches will download in PQs for no more than 7 days after the archival. This would make it so that archived caches would be easier to identify and remove from my offline data that I cache with. Also, would it be possible to set up a system by which I could set up a PQ or series thereof to run only once a month, instead of once a week?

Link to comment
I would suggest giving them more than just one week.

I was suggesting a week's notice to people who are suspected of being inactive - the period they would have had to been inactive (haven't visited the site as themselves) wasting PQ cycles would have to be far longer, like a few months.

 

And they can always re-enable their PQs.

Link to comment

Did I miss it? I admit I've just skimmed the last half of this thread, but I saw a lot of "solutions" like identifying inactive cachers, moving PQs around, blah, blah, blah.

 

Well, I guess this Chicken Little did predict the sky was falling.

 

Granted, I'm glad the "changed in last 7 days" was finally implemented, but what about the other query hogs, namely the 500 cache limit?

 

As it is, many folks have to split up their queries into several to get around the 500 PQ limit. By allowing, say, 2500 caches in a single query, the number of queries could drop dramatically. I know I've said it, and plenty of other folks have said it, but it seems like nothing is done until the system comes to grinding halt.

 

I think this fix would be a lot easier to impliment that trying to identify "inactive" accounts. And why should you deactivate them anyway? They paid for it and they should get it. Period. Who says they ain't using them?

 

Increase the limit and your problem will be solved for a long time.

 

Here's another one, increase the 5 log limit. It's the sole reason I pull every changed cache twice a week. I got tired of missing logs.

 

Here's another one, implement the ability to merge several queries into one. Allow the more advanced cachers to built a custom query. That would drop my 20 odd queries down to ONE!

 

Before anyone jumps on me for pulling so many queries. I do it because apparently TPTB don't care to impliment changes that would reduce the load. I paid for it, I'm taking it. You want to yell at someone, yell at TPTB for not listening to us "Chicken Littles."

 

'Nuff said.

Link to comment
By allowing, say, 2500 caches in a single query, the number of queries could drop dramatically.

No. Not true.

 

1. The number of 2500 cache queries would increase dramatically, no matter whether the geocacher needs them or not.

2. 5 PQ of 500 apiece, or 1 PQ of 2500 is constant, and involves the same processing power, if not more, as the query time for each PQ would increase the time before another PQ could be processed.

 

2 low hanging fruit reasons why this idea does not help the issue.

Link to comment

Wow, then I must obviously misunderstand how queries work, then.

 

Given I have to break up a given radius in blocks ordered by date:

 

Queries:

- certain distance from point limited to 500 total records between the dates Jan 01, 2001 and Dec. 31, 2002.

- certain distance from point limited to 500 total records between the dates Jan 01, 2003 and Dec. 31, 2003.

- certain distance from point limited to 500 total records between the dates Jan 01, 2004 and Dec. 31, 2004.

- certain distance from point limited to 500 total records between the dates Jan 01, 2005 and Dec. 31, 2005.

 

...takes no longer, or not much longer, to run than:

- certain distance from point limited to 2500 total records?

 

(with none of the results hitting the number limit.)

 

Curious.

 

But, I'd opt for a single 2500 query a day over 5 500 cache queries. Bump the number of logs included and I could safely drop any one query to once a week without fear of missing something.

Link to comment

I'd be happy with just one query getting through. Can someone tell me what the effect of changing day of week options (eg removing sat sun mon options) might be to a query in the queue that is due today? Does it get reprioritised, or does it stay put?

 

Thanks,

Stuey

Link to comment

IMO the 2500 cache PQ would have it's uses, and even more abuses. Too many folks would be asking for 2500 caches near thier home and delaying my PQ even longer.

 

A 500 cache PQ is enough for going caching for me, but I don't live in a saturated area either.

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