Chris,
For my app sharing data would not be an issue. That is one of the reasons I'm considering (and testing) using more than one App so that I can have different Scheduler/Instance/Latency settings in each. In my case most of the difference is per domain, but I do know for instance that everything in with a ?s=Keyword is a Search and will therefor take longer than just returning some page with some data. The reason I was looking at "Per Handler" was that I was hoping that something could be done where it was just instance balancing. I would have 2 instances reserved for "Priority 0 requests" and 1 for "p1" requests. If P0 is busy, and p1 is not p1 serves p0 requests. If P0 is busy and P1 is busy more P0 instances spin up If P1 is busy more P1 instances spin up. But the "busy" state for each would be configurable. If P0 Request has "133 ms pending Latency set" and p1 has 1000 ms Pending latency Then the waterfall would look something like this.. P0 Request Instance 1 has 166ms until free -> go next Instance 2 has 266ms until free -> go next Instance 3 is p1 handler has 106ms until free -> serve request P0 Request Instance 1 has 166ms until free -> go next Instance 2 has 266ms until free -> go next Instance 3 is p1 handler has 1206ms until free -> Create new P0 Instance Instance 4 is P0 -> serve request P1 Request Instance 1 is not P1 has 166ms until free -> go next Instance 2 is not P1 has 266ms until free -> go next Instance 3 is p1 handler has 106ms until free -> serve request P1 Request Instance 1 is not P1 has 166ms until free -> go next Instance 2 is not P1 has 266ms until free -> go next Instance 3 is p1 handler has 2106ms until free -> Create New p1 Instance Insance 4 is p1 -> serve request Ideally It would be nice to specify by handler, or Assigned domain. I don't know if there is reason to have more than 2 tiers of service. For small apps I would think 2 would do fine. I can envision large apps looking at 3, but likely you have "Very fast", "Kind of slow" and "Should be done on the back end". Where things get "interesting" is in resource balancing. The Really slow requests being on a separate app in my app is causing extra congestion because they have the really high Cache-Miss rate because they are computing/gathering new data that I don't already have. So they tend to be one off requests that don't benefit much from memcache. I'm a lazy coder so I always check just in case because when you do get lucky and the data is there I save 2000ms and that adds up. But in terms of users serve/pages served that hit cost me a lot of the very fast page serves ability to be cached. SO. putting my slow requests on a separate App Gives me HUGE wins because I get a better cache hit ratio and more total Mem-cache. <Side bar> It doesn't appear that Memcache scales with my number of instances, but rather is a per app limit. Where as local instance memory goes up with my number of instances. As a result instance memory cache hits scale up when you have a spike in traffic to 100s of page, and mem-cache hits go down because if the number of actively requested items goes up mem-cache stays the same size. (this also comes in to play as you start to multi-tenant lots of websites <back on track> So for me the "non-sharing" of data across apps means I get more resources which is a good thing, that wouldn't work for a lot of other people, who don't have such beautifully segmented data that is happy in silo's. Datastore not being available across apps is kind of sad. I mean I like that if I have my PostGres or MySQL or Oracle server I can put as many apps on the edge and talk to it as I want, Datastore in GAE doesn't really allow that, (Though I did do some code that basically talks to DataStore via "curl" I meandered, these are my thoughts "Raw" as I think things through. For me: More Apps = Harder to manage but better and more customizable performance, no ability to have different priorities on the Same Domain Apps with Instance priority =Fewer resources, Easier Management, ability to prioritize with in a single domain From: [email protected] [mailto:[email protected]] On Behalf Of Chris Ramsdale Sent: Wednesday, November 23, 2011 3:59 PM To: [email protected] Subject: Re: [google-appengine] Feature Request I Think.... Hey Brandon, A timely post indeed. Amongst the team, we've been discussing this exact problem. Splitting your app out into smaller apps has a handful of benefits, one of which is the ability to fine tune the performance settings for each app. I'd love to hear more about your design. For example: - Assuming that it's required, how are you going to handle sharing data between the two apps? - Are there other app-specific performance characteristics that you expect to change? - Are there configuration settings that you would expect to be applied to both apps? (E.g., a centralized list of admins or cross-app budget) - Any thoughts on how you would configure this with custom domains? -- Chris Product Manager, Google App Engine On Wed, Nov 23, 2011 at 2:27 PM, Brandon Wirtz <[email protected]> wrote: I am considering asking for the ability to specify Min/Max Latency in the App.Yaml per handler. I am really wishing I could have Fast instances and slow instances. I have a lot of requests that take 66ms to fill, and a lot that take 3000ms Concurrency seems to help some, but really I probably should be breaking these in to two apps one for the slow stuff that it wouldn't matter if it too 5s instead of 3s and on for the stuff that 66 or 133ms wouldn't make any difference. But the ones that take 66 seem really slow when they take 3066ms and I don't really need more instances, just more ability to arrange them. I had thought that by combining apps that I'd get to the point this would be less of an issued, but since the scheduler doesn't know how long requests are going to take it seems most inefficient at dealing with multiple "sized" requests. But all my troubles would go away if "slow requests" and "fast requests" went in to two different buckets. I'm willing to implement this however GAE thinks is best, so I'm posting this as "How do you solve this? And How should I?" -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:google-appengine%[email protected]> . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
