Jump to content

PQs behind schedule?


Gremalkin

Recommended Posts

My weekly PQs for Wednesday have not run yet today. Last run times on 4 of them were between 7:01 and 9:21 AM on 3/4. The 5th was run last on 3/4 at 2:34 PM. I made a copy of one and it ran right away.

 

Saw the posts about slow site issues and site errors, but didn't see any mention of PQ problems.

 

Thanks.

Link to comment

Read this...

 

You all are a piece... :rolleyes:

Piece of what?? :blink: Brian, I didn't see any statement there about PQs. I suppose it's probably related to overall site issues, but also agree with others here who point out that this is well beyond the typical slowness we see with PQs. And while I appreciate that Groundspeak is working on the issue (seriously, who could think they're not concerned?), I also think it's fair for people to ask about the status of a feature they pay for. (Maybe not much, and maybe that's part of the problem.)

Link to comment
Read this...

You all are a piece... :rolleyes:

Piece of what?? :blink: Brian, I didn't see any statement there about PQs. I suppose it's probably related to overall site issues, but also agree with others here who point out that this is well beyond the typical slowness we see with PQs. And while I appreciate that Groundspeak is working on the issue (seriously, who could think they're not concerned?), I also think it's fair for people to ask about the status of a feature they pay for. (Maybe not much, and maybe that's part of the problem.)
The bold part is interesting. I say that because I clicked on the thread primarily to see if it was an old thread that someone bumped. It seems like we have this very issue pop up from time to time. Typically, it seems like TPTB throw money at the problem to fix it temporarily, as OpinioNate mentioned. I certainly support their taking a moment to look for better solutions that would actually fix the problems for a longer period of time without their constantly having to make expensive hardware upgrades.

 

The problems exist. They are working on them. That's all we need to know. People are still getting their PQs. It's all good.

Link to comment
Read this...

You all are a piece... :D

Piece of what?? :mad: Brian, I didn't see any statement there about PQs. I suppose it's probably related to overall site issues, but also agree with others here who point out that this is well beyond the typical slowness we see with PQs. And while I appreciate that Groundspeak is working on the issue (seriously, who could think they're not concerned?), I also think it's fair for people to ask about the status of a feature they pay for. (Maybe not much, and maybe that's part of the problem.)
The bold part is interesting. I say that because I clicked on the thread primarily to see if it was an old thread that someone bumped. It seems like we have this very issue pop up from time to time. Typically, it seems like TPTB throw money at the problem to fix it temporarily, as OpinioNate mentioned. I certainly support their taking a moment to look for better solutions that would actually fix the problems for a longer period of time without their constantly having to make expensive hardware upgrades.

 

The problems exist. They are working on them. That's all we need to know. People are still getting their PQs. It's all good.

 

I was waiting for my Thursday PQs last night. they usually show up around 6 Mountain and they did not show up in my mail box till between 3 and 4 am this morning. This issue still persists. Because they didn't ran when they were supposed to they counted against my friday PQ limit.

Edited by supertbone
Link to comment

I think everyone is getting carried away.... but only after the smart (and personally I thought I misread it) comment. I am also a "paying" member and feel like I definitely get my money's worth even IF the site runs slow, or it takes a day for the PQ to arrive.

It just made me realize how nuts/ driven I am about GCing. Wanting to just run a quick query, just a quick one, and then growling at my laptop.

Just relax and take a walk on the way to your next cache. Here in MN, I am hoping that by Monday the snow will be all gone.....

Happy Friday the 13th and Happy Pi Day!!

:-D

Link to comment

My standard PQs have not generated since 3/11 (they were scheduled for 3/10). Yes, I could preview them but they would not generate.

 

Yesterday, I canceled all schedules on them (unchecked the boxes). Then made copies of all of them and rescheduled them. The new ones (3) generated immediately (as they had never run and were then at the top of the priority) and I received the e-mails. The lowest priority ones are the ones having problems.

 

Is GC.com so overloaded with PQ requests that they NEVER get to the bottom of the list each day?

Link to comment

Is GC.com so overloaded with PQ requests that they NEVER get to the bottom of the list each day?

 

How frequently to you have these PQs set up for? Daily? Weekly?

 

My weekly PQs run every week. There is some time creep. Daily PQs would seem likely to miss frequently because there is, at the moment, more requests than Groundspeak can handle daily.

Edited by beejay&esskay
Link to comment

Seeing the same delays - I've also seen the PHP delay errors, and delayed PQ's. I've got two daily PQ's that haven't run since the 10th. I also just got an e-mail that one of my caches was published - except it was published around noon (eastern) on THURSDAY.

 

Haven't seen any specifics on the issues, but it looks to me like something sudden - performance the past few days has been pretty bad across the entire site. No e-mails to forum posts, slow response, and of course the missing PQ schedules...

 

Just expressing observations. Please let me know if there's anything I can do to assist. Have worked on a number of websites, and have experience with web-based database access with various DB's out there.

 

Thanks for the efforts!

 

Steve

Link to comment

I have three PQs that run twice per week. I've never had them not run. They do creep occasionally.

 

Given that TPTB have recognized the issue and are "workin' on it", I have no reason to complain. They will either come up with a permanent solution, or they will throw money at the problem, again. Either way, the problem with be resolved without my whining.

 

Finally, if I missed out on my PQs one week, it still wouldn't be a big deal. I would merely go with my previous data. Big deal. I would accept the risk that one tenth of one percent of the caches in my pda had been archived. Chances are, I wouldn't happen to search for those but even if I did it's no big deal since there is virtually no difference between DNFing an archived cache and an active one. Sure, I also wouldn't have the info for as many as half a dozen brand new caches, but I'll end with those in later PQs.

Link to comment

The problem with the current PQ situation is that it's incredibly unpredictable. Sometimes queries run almost instantly, sometimes they simply never run.

 

If PQs were slow, but were ALWAYS slow, one could plan around it. But you can't.

 

This morning I manually ran 5 saved PQs. Two ran so fast they were in my mailbox before I could finish making my selections. Three of them are still just sitting there, and haven't run yet.

 

All of the queries have been run countless times, so it's not a case of "new ones running first".

Link to comment
The problem with the current PQ situation is that it's incredibly unpredictable. Sometimes queries run almost instantly, sometimes they simply never run.

 

If PQs were slow, but were ALWAYS slow, one could plan around it. But you can't.

 

This morning I manually ran 5 saved PQs. Two ran so fast they were in my mailbox before I could finish making my selections. Three of them are still just sitting there, and haven't run yet.

 

All of the queries have been run countless times, so it's not a case of "new ones running first".

 

Yes, but for us to understand what you are seeing, you would need to tell us the LAST time each of the PQs ran.

 

My experience over the last 3 days is that weekly PQs are running earlier than they did the week before. I'm not sure if this is "permanent" improvement, but I think things have improved.

Link to comment

I would guess the two that did run were last run 7 or more days ago.

 

For the ones that haven't run yet...they last ran 6 days ago. The PQ server is probably busy dealing with PQs that run once a week.

 

(If TPTB would provide a "now serving" display that showed the date/time last run for the PQ currently running, these mysteries would disappear.)

Edited by beejay&esskay
Link to comment

I would guess the two that did run were last run 7 or more days ago.

 

For the ones that haven't run yet...they last ran 6 days ago. The PQ server is probably busy dealing with PQs that run once a week.

 

(If TPTB would provide a "now serving" display that showed the date/time last run for the PQ currently running, these mysteries would disappear.)

 

If I had to guess, I'd say that the two which already ran were part of my allotment on the 11th.

 

So what you're saying is, greater than 7 days = instant, less than 7 days = maybe, maybe not? The difference of one day means I probably won't get my PQs at all?

 

FWIW, none of my PQs are set to run automatically on a recurring basis. I simply sit down and decide which ones I need to run, and run them. All of the PQs in the list above have been run countless times.

 

Also, all 5 I ran on the 13th ran nearly instantly as well. My experience indicates that if you don't get them in the first 30 minutes, you won't get them at all.

 

For the record, I think the fuzzy logic of running some PQs ahead of others based on arbitrary intervals is ridiculous. It should be first come, first served, period.

Edited by sataraid1
Link to comment

For the record, I think the fuzzy logic of running some PQs ahead of others based on arbitrary intervals is ridiculous. It should be first come, first served, period.

 

So if I want a band new PQ for a quick cache run I have to wait 1/2 a day for it? Are you kidding? :ph34r:

Link to comment

I think some are totally misunderstanding the priorty scheme of PQs.

 

New PQs (never run) are bumped up to the front of the line.

Older PQs are prioritized based on the last daytime they ran in reverse.

 

A PQ ran just yesterday is going to get a lot less priority than one that has not run for 3 weeks.

 

I am not certain what the last run datetime of the PQ just processing on the system is going to tell you exactly.

Link to comment

I think some are totally misunderstanding the priorty scheme of PQs.

 

New PQs (never run) are bumped up to the front of the line.

 

Why?

 

Older PQs are prioritized based on the last daytime they ran in reverse.

 

If the delays seemed linear, I could almost buy that. Yet in my case, the difference of one day seems to be the difference between running instantly, and pushing 5 hours.

 

I still don't see why "first come first served" isn't simpler.

Link to comment

I think some are totally misunderstanding the priorty scheme of PQs.

 

New PQs (never run) are bumped up to the front of the line.

 

Why?

 

Older PQs are prioritized based on the last daytime they ran in reverse.

 

If the delays seemed linear, I could almost buy that. Yet in my case, the difference of one day seems to be the difference between running instantly, and pushing 5 hours.

 

I still don't see why "first come first served" isn't simpler.

 

<echo>

So if I want a band new PQ for a quick cache run I have to wait 1/2 a day for it? Are you kidding? :ph34r:

</echo>

Link to comment

 

I still don't see why "first come first served" isn't simpler.

 

Why of course a FIFO queue is much simpler to manage. But what was pointed out is if a PQ is brand new and never run it has a high probability of being a "I'm going caching in a few minutes and I want a PQ of where I'm going" verses the scheduled every week PQ. Now if you had the first kind of PQ would you want to wait some undetermined number of hours for the scheduled PQ's to clear the queue? I suspect you would be back here complaining how it takes hours or days to get your "quickie" PQ. The priority based queue is much harder to handle, but for the spectrum of PQ's it is probably the best approach.

 

Think of it this way. You stop off at the grocery stop to buy a gallon of milk. They have only one checkout open. In front of you are 6 or 7 shoppers with their carts overflowing. You have to stand behind them to get checked out. Would you be happy standing in line knowing that the simpler FIFO queue was being used or would you rather the queue be number of items based?

 

Jim

Link to comment

Think of it this way. You stop off at the grocery stop to buy a gallon of milk. They have only one checkout open. In front of you are 6 or 7 shoppers with their carts overflowing. You have to stand behind them to get checked out. Would you be happy standing in line knowing that the simpler FIFO queue was being used or would you rather the queue be number of items based?

 

Respectfully, that doesn't work because the amount of time involved in processing both queries/checkout carts is equal. What's being arbitrarily judged is the interval.

Link to comment

Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

 

But it does get you around the ever increasing delays of previously scheduled PQ's.

Link to comment

Now Serving? What exactly does that entail?

 

-Raine

I think what they want to see is for pocket queries scheduled to run today that there be another field that says something like "You are number 47283 in the queue". If they refresh the page it would say "You are number 47256 in the queue", and so on. I guess people could look and get a idea of how long till their PQ would run and decide if the want to create a copy and run that instead. A brand new copy would probably say "You are number 2 in the queue".

Link to comment

Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

 

But it does get you around the ever increasing delays of previously scheduled PQ's.

 

You don't even have to recreate them. Just use the "copy" button in the PQ list, and it will run instantly. I have been forced into doing that on several occasions, where I'm basically sitting packed and ready go go and still waiting on PQs I submitted hours previously.

 

But I'd prefer not to have to do that, and continuing to do so doesn't answer any of the questions I've asked.

Link to comment

Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

 

But it does get you around the ever increasing delays of previously scheduled PQ's.

 

You don't even have to recreate them. Just use the "copy" button in the PQ list, and it will run instantly. I have been forced into doing that on several occasions, where I'm basically sitting packed and ready go go and still waiting on PQs I submitted hours previously.

 

But I'd prefer not to have to do that, and continuing to do so doesn't answer any of the questions I've asked.

How ironic... You're complaining how FIFO would be better in one post, and complaining about not getting your fresh PQ right away in another.

 

Why does my post say "Ringbone"? :ph34r:

Link to comment

Sadly, most astute PQ users simply get around the bottlenecks by creating multiple copies of the same PQ and schedule each one to run once a week. After a few months, creep will have moved them down the queue and you will have to delete them all and recreate it.

 

But it does get you around the ever increasing delays of previously scheduled PQ's.

 

You don't even have to recreate them. Just use the "copy" button in the PQ list, and it will run instantly. I have been forced into doing that on several occasions, where I'm basically sitting packed and ready go go and still waiting on PQs I submitted hours previously.

 

But I'd prefer not to have to do that, and continuing to do so doesn't answer any of the questions I've asked.

How ironic... You're complaining how FIFO would be better in one post, and complaining about not getting your fresh PQ right away in another.

 

Why does my post say "Ringbone"? :ph34r:

 

You're quoting two different people.

 

At no point have I complained about fresh PQs not running. I know they do.

Link to comment

I think some are totally misunderstanding the priorty scheme of PQs.

 

New PQs (never run) are bumped up to the front of the line.

 

Why?

 

Older PQs are prioritized based on the last daytime they ran in reverse.

 

If the delays seemed linear, I could almost buy that. Yet in my case, the difference of one day seems to be the difference between running instantly, and pushing 5 hours.

 

I still don't see why "first come first served" isn't simpler.

You don't have to "buy" it - it is what it is. Simple fact.

 

The theory behind it is:

not run=user with no data

ran yesterday = user with 24 hour old data - very little stale data

ran 7 days ago = user with 7 day old data - liklihood of stale data much higher but not bad either

ran 2 months ago = user with ancient data - data has just about got to be stale.

 

Looked at that way does the priority make a bit more sense?

Link to comment

 

You don't have to "buy" it - it is what it is. Simple fact.

 

The theory behind it is:

not run=user with no data

ran yesterday = user with 24 hour old data - very little stale data

ran 7 days ago = user with 7 day old data - liklihood of stale data much higher but not bad either

ran 2 months ago = user with ancient data - data has just about got to be stale.

 

Looked at that way does the priority make a bit more sense?

 

Yes, yes it does. Thank you.

 

But it doesn't appear to be executed that evenly.

 

It would seem highly unlikely that the difference between 8 days old (the 11th) and 6 days (the 13th) old would be the difference between instant processing and a delay of 7+ hours and counting.

 

We're only taking about a difference of 48 hours here.

Link to comment

Now Serving? What exactly does that entail?

 

-Raine

I think what they want to see is for pocket queries scheduled to run today that there be another field that says something like "You are number 47283 in the queue". If they refresh the page it would say "You are number 47256 in the queue", and so on. I guess people could look and get a idea of how long till their PQ would run and decide if the want to create a copy and run that instead. A brand new copy would probably say "You are number 2 in the queue".

 

I was thinking more along the lines of

 

"PQ last run 3/12/09 03:34 AM is now processing" and not consider "instant" requests since that wouldn't really give any information. With a correct understanding that "when last run" is the determining factor for when your PQ will run, a user waiting for a PQ that last ran 3/13/09 6:11 AM would have a better idea why that PQ is not running yet.

 

Number in the queue sounds hard, since it would be PQ-dependent (of course) and would involve a bit of calculation every time requested. (And could lead to "I was 47256 a minute ago but now I show as 47344. What's happening?)

Edited by beejay&esskay
Link to comment

I find it hard to believe that whatever server/system/whatever is used to generate PQ's is running 100% 7/24. Which means that some scheduled PQ's could probably be run earlier than they ran yesterday/last week. But I have never seen one of my scheduled PQ's come in earlier than it did the last time. There is always creep. And that is dumb. If the PQ server isn't doing anything in the middle of the night (or other slow period), then run the PQ's scheduled for that day. Don't wait till later.

 

I understand that on Thursdays and Fridays, the server probably is 100% busy but I doubt that is the case on Tuesdays, for example.

Link to comment

 

You don't have to "buy" it - it is what it is. Simple fact.

 

The theory behind it is:

not run=user with no data

ran yesterday = user with 24 hour old data - very little stale data

ran 7 days ago = user with 7 day old data - liklihood of stale data much higher but not bad either

ran 2 months ago = user with ancient data - data has just about got to be stale.

 

Looked at that way does the priority make a bit more sense?

 

Yes, yes it does. Thank you.

 

But it doesn't appear to be executed that evenly.

 

It would seem highly unlikely that the difference between 8 days old (the 11th) and 6 days (the 13th) old would be the difference between instant processing and a delay of 7+ hours and counting.

 

We're only taking about a difference of 48 hours here.

Ahhhh - but keep in mind that most Geocachers set thier PQs to run only 1 time per week (aka - every 7 days) and that lays right in the middle of your example. Putting a lot of pressure on the 6 day old one.

Link to comment

 

It would seem highly unlikely that the difference between 8 days old (the 11th) and 6 days (the 13th) old would be the difference between instant processing and a delay of 7+ hours and counting.

 

We're only taking about a difference of 48 hours here.

 

The reason for the difference is the large number of PQs set to run every 7 days.

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