I'll pm you that offline, i'll end up over the hourly limit at some point if not already.
    
With the adjustments 15s/300s(45s active), It's dropped from 950 to 140 api calls over a 5 minute period with no impact on user experience.
That will ease up some activity to your server.

I also found the block message i'm hunting for so i may be able to adjust to 60s/300s(45s) shortly with a little tweak that will get near event driven block -> push notification, backup using block num change in polling.
 {"params":["Block 397940 solved by d00d.PK217 @ ckpool!"] ..

Added some metrics.   The app (overall) is triggering 950 api calls every 5 minutes.

I will bump it to 15s/300s shortly (incrementally by EOD), and drop it down to 45s when the application is awake.

That should drop it down significantly and still provide the functions.

Felt like I was about to bump that limit soon.   I will slow it down.    

I did notice that 30 second worker change frequency and don't pull more frequently than 30s per worker.

The data is normalized through a summary node on my end to make data from kano.is look like data from solo.ckpool.

This also allows for notifications, and controls hits to your system at a known rate.   And if the downstream changes (new pool, new data, changed data structure), I don't need to wait for apple review to make adjustments.

aggregation node thread:

1 pool thread - Every 15 second, watches for block found changes.  collect pool related information
3 thread poll user status - pulls data per user if user's stamp is older than 30 seconds.  which is the minimum useful limit you noted.
(misc thread to watch status file, blockchain payout, etc)

The pool thread triggers the pool block push notification
The user thread triggers user push notifications

Every running app hits was suppose to hit the aggregation node a bit harder as it acts as the relay, and broadcast one-to-many for the 15s poll.

The user notification part has been bothering me too.  I would like not to scrap earlier notification but if it causes stress or ban, that's no good.

The target hits to kano.is:

240x times per hour for pool block change thread.
120x times per hour per app install for user thread.

Here's a few strays that are causing the numbers to be higher, and what i'm doing to address those.

If someone adds in 20 worker addresses and don't use an account.    I did not expect a lot of those, but it is there.
   - solo.ckpool does a worker list in the user view.   i can adjust this the same to save lots of hits should the parent user view eventually show workers.

User Typos.  
   - looking to apply retry suppression.   there's no stamp to baseline off.   need to better distinguish it from no api data, zero api data during restarts.

Also playing with an out of band block change notification.

The 15s/30s can be tuned as required immediately.

That would best case.   15 second poll of kano.is api + apple push latency.   Every so often it will line up.   Every other time it takes folks 30s to click the screen and two more minutes to log in and check the site so it feels instant.   You still have the edge on watching the console.

The more the merrier.  PM me an email address and I'll load it into apple's testflight/beta list.

The refresh rate can use some optimization.   After adding the api key the worker screen will [eventually] say Hashing @ nnn.nnGHs.
But that's about it.   Some basic worker/pool stats and a few fun event notifications right now.

this falls under more stats please, in the misc todo already.    it will likely be there a few iterations down.

Interesting.   Just force closing and reopening it will reinitialize all the objects and arrays, and accomplishes the same.
Might be a timing issue with a ckdb restart but i don't recall one recently.    Let's see if anyone else notices or if i can force recreate it.

thanks for the clarification.   that makes sense, aligning with your various other posts.

trying it out was my next step.   initially sounded like it applied only in solo mining mode, was unsure if proxy mode get broadcasts from upstream pools.

quick question: do i need to wire the notifier to a bitcoind node to pick up block solve messages from upstream in proxy mode?   trying to read through the stratum protocol docs to understand it a bit more, but thought i'd just ask.

seem like ckpool proxy mode is not reporting block solve message downstream.   not sure if that is the nature of the interaction or if i'm missing a setting. 

random light bulb.  switch to -l 7 and going to dig trough ckproxy.log to confirm a crazy idea.  

glad you find it useful.    suggestions tacked to misc todo/wishlist.

apologizing for the delayed block.   catching my first bug.

edit:   but keep the blocks coming so i can iron out the notifications.

and do zero for the other 3/4 of 5Nd.   or go xtream and 10,000Th for 1/40 of 5Nd, and zero at 39/40th of 5Nd.   that might boost up your odds when it matters most.   i would avoid trying too hard though, luck might kick you in the rear.  

after the first one, about 17 minutes.    that first one can be a wait though.

I submitted that with the app review request before starting this thread, that thread was the closest url (required) available to a support page at the time.   No sure if i can update it without another review.   I recheck to see, otherwise it will be updated with v1.2 submission.

edit: link changed and directing here.

adjusted to go down the hierarchy but not up.   this is useful feedback.   appreciated since i don't see all the common use cases yet.   if it's not relevant i'll chime in accordingly and punt the request.

 

thanks.  

also.  you should be able to see solo worker data at this point.   there is still an anomaly floating about that i'm trying to trap but it should be healthy enough to access.   right now, solo worker address can be any syntax as long as the btc address is there address, address_worker, address.worker.   the logic will move up to the top level address and grab all related worker under the user.   as far as i can tell, there appears to be no workers without a corresponding solo users stat, and there's no immediate benefit to just see / track a single worker under the user umbrella.