Go instances cannot currently handle more than one request at a time, though within a request you can use goroutines. Concurrent requests is something that is likely coming. We're not providing a roadmap at this time, but that team does read the go mailing list, so make sure your thoughts are heard there.
Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine On Fri, May 20, 2011 at 1:59 PM, DennisP <[email protected]> wrote: > It seems that the inefficient use of instances is the biggest price > hit for anyone who scales beyond minimal levels...and that Go could > help a lot, even without multithreading. I'm no Go expert but Erlang, > for example, can handle a huge number of concurrent requests with a > single OS thread, and Go seems to have similar capabilities. > > It'd be great to get some information from Google on this. Even before > Go apps are able to take advantage of multiple cores, will they be > able to handle concurrent requests on one instance, instead of letting > processor sit idle while it waits for data to arrive from storage? > > If so, then perhaps a viable shortcut would be to build one virtual > machine running Go for each core of the physical machine, instead of > trying to build Go to use multiple OS threads. > > With Go's concurrency and speed, it should be possible to handle quite > a lot of requests per instance. > > (The other common complaint is the minimum for small apps. Google > might want to consider that a lot of those apps are startups that > failed. Most startups fail. If failure is cheap enough for us to fail > a lot, we'll be more likely to find something that succeeds and scales > up.) > > On May 20, 12:51 am, Jeff Schnitzer <[email protected]> wrote: > > I think you're missing out on the bigger picture, which is that: > > > > 1) High-level decisionmakers inside Google are reading this thread. > > > > 2) Early input has greater potential influence than later input, > > especially after a ton of billing code has been written and the > > "momentum" of a big ship like Google has been established. > > > > 3) We here, right now, we're the focus group. There is no better time > > to speak up about your concerns. The chances of your fears > > materializing are much higher if you don't ask about them. "Wait and > > see" is a recipe for disappointment (in life). > > > > We've already seen one major change (half-price Python) which is a > > tacit acknowledgement that the single-threaded model may be a > > significant problem. My goal by "bellyaching" is not to haggle the > > lowest possible price out of appengine, but to get a competitive, > > sustainable, cost-effective platform that makes both Google's > > accountants and my accountants (and my clients' accountants) happy. > > There are two risks - one is that Google unsustainably underprices > > appengine, the other is that Google unsustainably overprices > > appengine. If it turns out that because of low levels of concurrency > > these two overlap, we *all* have very big problems. > > > > In my mind, the biggest risk to the success of GAE is an architectural > > issue that you and I have no control over. The new pricing model is > > largely symptomatic of a deeper problem, and it won't do Google any > > good if the sustainable price is so high that the market flees. An > > instance on GAE may cost the same per hour as an "instance" somewhere > > else, but of that other instance can do 10X the work in the same hour, > > the market will eventually figure out that GAE isn't a very good deal. > > > > By the way, I *do* run several VPS servers with non-GAE projects - > > some of which predate my love affair with appengine. It's a fixed > > outlay, but has the advantage that I can stack additional projects on > > it for nearly no marginal cost. It won't cost me an additional $9/mo > > to build another project on it. > > > > At any rate, I place a lot of trust in the people behind appengine - > > every one I've met has been super smart, engaged, and genuinely > > interested in building what I still think is the coolest thing on the > > internet. But they won't succeed in doing that without lots of > > customer feedback, so bellyache (constructively) as loud as you can as > > long as they're willing to listen... > > > > Jeff > > > > > > > > > > > > > > > > On Thu, May 19, 2011 at 8:16 PM, Greg <[email protected]> wrote: > > > It seems to me that many people are losing sight of the fact that > > > there will still be a free tier. > > > > > So our proverbial web developer can tinker around with her app for as > > > long as she wants, at no cost. Once SHE decides to, she can avail > > > herself of scalability and an SLA for $9 a month, which seems very > > > reasonable to me. > > > > > If her app needs more resources and she can't afford $9 a month, then > > > her app is not financially sustainable and will die. A shame, but it > > > has to happen. Otherwise hundreds of thousands of unsustainable apps > > > will consume infrastructure and support resources, and increase the > > > cost for everyone else. > > > > > To those still bellyaching over $9, maybe you should build your own > > > server. Invest probably $1000 for hardware, $50 a month for internet > > > connection, and however many hours it takes to manage the machine. And > > > you can host all the other people's apps for free - or is it only > > > Google who should give away app hosting for free? > > > > > Or of course you could switch to AWS. Don't forget you'll need two > > > instances in different regions for redundancy, and the cost of > > > bandwidth between them to synchronise, and you still need to put in > > > quite a lot of time managing it all... does $9 seem reasonable now? > > > > > There is still a lot of dust in the air - we don't know how the new > > > scheduler will work, and it may be that Python 2.7 and multiple > > > threads suddenly makes everything ten times cheaper. We really don't > > > know what the new costs will be until we get comparison billing. But > > > after all is said and done, I'm still glad I built my apps on > > > Appengine, and I'm glad Google are making it more commercially > > > sustainable. > > > > > -- > > > 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 athttp:// > 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.
