- I'm running an app as a public service, and I'd rather not have to charge for it. Our google overlords have not given me any way to duck the new pricing for my do-gooder app, so I'm looking to game the system if I can. :)
- My app is used infrequently by humans, in short bursts. Normal use would probably stay under the new free quotas, because the instance-alive-time x number-of-bursts-per-day < 24 hours.
- There are kiosks which show information from my app. The kiosk gets a dynamic HTML page in one go, the page includes many DIVs to display to the user over the course of 4-5 minutes or so. When it's gotten through all the DIVs, it refreshes from the server, to pick up any new updates.
In the old pricing model, this wasn't a problem. But in the new model, the kiosk "heartbeats" are keeping an instance alive. That burns up my free quota.
When a human uses the app to browse or update data, I have to pay for it 100% of the time.
So I'm wondering if anyone here has an idea of a different way to deal with the Kiosks, to allow my instances to go away completely between human interactions.
One idea I had was that when a user interaction happened, I could compute the Kiosk page and push it someplace. I can't push it to the Kiosk itself, of course, so I'd have to push it someplace that the Kiosk could hit it without spinning up a new instance in GAE. GAE has an edge cache, but I don't think there's any way for me to prime that. I could push to a different GAE app that just handles the Kiosks, but that sounds like willfully creating multiple apps to avoid quota charges, which is verboten.
I could push it to Amazon S3. That's not awful, and I've certainly done hybrid GAE/AWS apps before. But a two cloud solution is certainly not my first choice on the complexity front.
A half-assed solution would be just to have the Kiosk go through the DIVs several times before refreshing. That's not a horrible solution, but I'm hoping some clever developer here has a better idea…
Thoughts?
-Joshua
So providing what you want can be served by this instance, you dont
have any (instance) changes.
As for saving the file, you could put it in the blobstore. The handler
to serves the send_blob should be very quick and not tie up the
instance for long.
Or Google Storage for developers (G's answer to S3) - that avoids the
instance totally.
You might have to optimize the code around user-interaction requests,
to make sure again they stay on the single instance. But set a high
minimum latency, and that shouldnt be an issue
(or i've missed something)
> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
>
>
Dont you get one instance (well two until multi-threading) free? - so
you can have a dynamic instance always loaded. (ie you get 24 instance
hours free a day)
So providing what you want can be served by this instance, you dont
have any (instance) changes.
As for saving the file, you could put it in the blobstore. The handler
to serves the send_blob should be very quick and not tie up the
instance for long.
Or Google Storage for developers (G's answer to S3) - that avoids the
instance totally.
You might have to optimize the code around user-interaction requests,
to make sure again they stay on the single instance. But set a high
minimum latency, and that shouldnt be an issue
(or i've missed something)
Be noted that Google Storage is in PREVIEW. Did GAE teach us sth?
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/CqsIGSJRnh0J.
Hmm, from what I understand it would be possible to keep one instance. Thats all Free apps get anyway.I've setup against an app not currently serving other traffic two cronjobs, on a server here. every 5 minutes, hits a URL (thats your kiosk) - and then once an hour runs " ab -n 30 -c 2 -t 15 http://....appspot.com/..." to similuate a user.Have also set minumum maximum idle instances (1) and max pending latency. So far it has only one instance. Even when requests reached 4 rps.
Another idea, you get 9 hours of backend free a day too. Could you shunt the 'users' to actully be done via your backend. Leaving the single frontend instance to serve kiosk traffic?
Another idea, you get 9 hours of backend free a day too. Could you shunt the 'users' to actully be done via your backend. Leaving the single frontend instance to serve kiosk traffic?If I can, then I clearly don't understand what a backend is.Can you elaborate on this idea?
1
and 20
indicating the number of instances to assign to the given backend. Defaults to 1
if unspecified."The $50 credit. That should cover costs for about 5 months on a *low
taffic* website.
Which in theory should be enough for Multi-threading and the scheduler
to be fixed* . At which case app can return to free quotas :)
* So that it will stick to one instance, even for a reasonable amount
of traffic. I'm sure this is possible and feasible.
(I'm tempted to signup for the multi-threading trail, just to see what
sort of QPS a multi-threaded instance can handle. )
I dug into the Google Storage and S3 options, and they both suck as solutions because the free tiers go away after year 1. (Plus the authorization stuff is mind-numbingly complex.)
I think my plan right now is to sit tight. The architecture I have looks like it should work when they fix the scheduler, and allow multi-threading in Python. Switching to HR is going to be a huge PITA, because my use case is exactly the one that "eventual consistency" screws up (user posts a meeting, then expects to see it in the list of meetings; silly users). But there's a gun to my head, so I guess I'll spend a weekend on it. Sorry kids.
-Joshua
On Fri, Sep 2, 2011 at 5:46 PM, Joshua Smith wrote:Switching to HR is going to be a huge PITA, because my use case is exactly the one that "eventual consistency" screws up (user posts a meeting, then expects to see it in the list of meetings; silly users).
Can't Entity groups be used to ensure consistency?
http://code.google.com/appengine/docs/java/datastore/hr/overview.html
Put all a users meeting in a single group (based of the User Entity).
Then all the meetings will be shown
Alternativly
A trick I used a long time ago, to deal with replication lag between
mysql servers. When someone added a new item, store it in the session
(as well as writing to master). then when run the query against the
slave (which might be stale) can just tack the saved item on the end.
Within appengine would use memcache. Not sure if its an appropriate
fix for this issue on appengine, but it worked just fine for me then.
(and is very little code)
Can't Entity groups be used to ensure consistency?
http://code.google.com/appengine/docs/java/datastore/hr/overview.html
Put all a users meeting in a single group (based of the User Entity).
Then all the meetings will be shown
Alternativly
A trick I used a long time ago, to deal with replication lag between
mysql servers. When someone added a new item, store it in the session
(as well as writing to master). then when run the query against the
slave (which might be stale) can just tack the saved item on the end.
Within appengine would use memcache. Not sure if its an appropriate
fix for this issue on appengine, but it worked just fine for me then.
(and is very little code)
>