Personally, I believe these "synthetic" limits are more than just best practices: http://www.google.com/patents/US20110302243. Background and Summary sections of the Description are actually pretty interesting. If I'm not mistaken, that's where Appengine comes from. At least partially.
Aside from that, take Twitter for instance. Back in the days when they were running some rails apps, it all started failing the moment more people started twitting. Everybody were saying, "just throw more hardware at it", which Twitter tried. Turned out throwing more hardware at it was either highly cost-ineffective or simply didn't scale anyway. They ditched rails at the end, and started doing lots of other stuff to make things scalable. What I'm saying is, guys like Brandon can move off/to Rackspace, AWS and what have you, but it's often not a solution - just delaying something that comes back later. All we do is running huge and complex Turing machines after all. Well, unless it's a neural network thing capable of recognizing cats in Youtube videos :) On Fri, Nov 23, 2012 at 2:55 PM, Mani Doraisamy <[email protected]> wrote: > Wow! you guys are so fast that this thread looks like a chat :) > > In the past, quota limits were based on 2 conflicting objectives: > > discouraging people from building non-scalable applications by restricting > APIs & time limits. > discouraging people from using app engine at an "unfair" cost during the > request pricing regime. > > The synthetic limits problem that you mentioned are the result of the > request pricing regime. It was frustrating to work-around the pricing > constraints instead of constraints based on the best practices for scaling. > With the new instance based pricing, these quota limits exist only as a best > practice for scaling, IMO. > > For example, urlfetch deadline limit is now configurable. Similarly, > Stanford NLP works quite well on the java version or you could very well use > Alchemy API, depending on how much control you want to have on your language > heuristics. > > It is sad that you are leaving. But, I guess, it is a collateral damage of > being an early adopter of a technology whose business model & technology > were figured out in the process. > > regards, > mani > > > On Friday, 23 November 2012 09:28:18 UTC+5:30, Brandon Wirtz wrote: >> >> >IMO, backends & quota limits are mostly problems arising out of bigtable >> > data migration (for new application >versions) & joins/aggregates (in >> > reporting). >> >> >> >> A few “for instances” >> >> We get feeds from Associated Press. When they update the feed and we try >> to grab a few hundred images at a time, we hit URL Fetch limits. >> >> We have a Language Heuristics Engine that is a core tech of all our >> product, we hit limits on how many request from other AppEngine Apps can hit >> that. >> >> >> >> We were trying to do Large jobs with backends, which are supposed to >> autoscale. They don’t. >> >> While you are right that those limits hit during migrations, they are also >> part of our daily life. We spend a lot of time thinking about how we can >> engineer around the synthetic limits of Appengine. And often how those >> limitations are inflicted on us change suddenly without notification. >> >> > > -- > 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/-/1v6LD9zshRoJ. > > 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.
