A recent version of webob in the sdk would be nice. :)

http://code.google.com/p/googleappengine/issues/detail?id=6507

On Monday, February 27, 2012 6:05:40 PM UTC-5, Cayden Meyer wrote:
>
> The App Engine team have made many recent changes which have fixed bugs 
> and improved performance. We will continue to make improvements and add new 
> libraries as time goes on. 
>
> We have seen many applications which have seen significant reductions in 
> the number of instances when using concurrent requests, however concurrent 
> requests will offer the greatest reduction in instance usage when 
> applications are not CPU bound. 
>
> I encourage you to try Python 2.7 with your own applications and look 
> forward to hearing your questions, comments and suggestions for new 
> libraries <http://code.google.com/p/googleappengine/issues/list>. 
>
> Cayden Meyer
> Product Manager, Google App Engine
>
>
>
> On 28 February 2012 06:20, Brandon Wirtz <[email protected]> wrote:
>
>> I’m on 2.7 it made a huge difference. Likely if your app is Data Store 
>> Heavy you will see Massive improvements. If you are computation heavy you 
>> will not.
>>
>> Look at your dashboard the CPU Seconds Use/Second will tell you the ratio 
>> of Instance CPU Cycles to API CPU cycles. On 2.5  I ran at 1/10 the CPU as 
>> the API. On 2.7 I’m at closer to 1/3   
>>
>> That didn’t equate to 1/3 fewer instances but it did equate to half as 
>> many.
>>
>> ****
>>
>> 2.7 seems to be hit harder by the random “everything is taking 3 times as 
>> long” bug.  And 2.7 instance spin up seems to be a bit slower than 2.5 
>> instances.
>> Also because you can have more than one request per instance you have to 
>> be more aware of your memory usage because if you have an app that uses 50 
>> megs of memory and it is serving 3 requests, you will see your instance 
>> killed more often for hitting the soft memory limit.****
>>
>> ** **
>>
>>
>>
>> ****
>>
>> *From:* [email protected] [mailto:
>> [email protected]] *On Behalf Of *Joshua Smith
>> *Sent:* Monday, February 27, 2012 11:57 AM
>> *To:* [email protected]
>> *Subject:* [google-appengine] Py2.7****
>>
>> ** **
>>
>> In today's blog:****
>>
>> * *
>>
>> *We think the Python 2.7 runtime for App Engine is a great step forward 
>> for our developers.  First, it allows applications to take advantage of *
>> *concurrent 
>> requests*<http://code.google.com/appengine/docs/python/python27/newin27.html#Concurrent_Requests>
>> *, allowing you to build more performant and efficient applications. If 
>> your application wasn't fully utilizing the CPU, chances are that you'll be 
>> able to use concurrent requests to reduce the total number of instances and 
>> serve more with less.*****
>>
>>
>>
>> ****
>>
>> That doesn't at all gibe with the stats people have been posting.****
>>
>> ** **
>>
>> From what I've read on these lists, 2.7 is slow at RPCs. But RPCs are the 
>> main way to not fully utilize the CPU. So for most apps, what you gain in 
>> concurrency, you lose in performance per thread.****
>>
>> ** **
>>
>> Is google announcing some performance breakthrough, or is this just 
>> reality-distortion-field stuff?****
>>
>> ** **
>>
>> -Joshua****
>>
>> ** **
>>
>> -- 
>> 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.
>>
>
>  
On Monday, February 27, 2012 6:05:40 PM UTC-5, Cayden Meyer wrote:
>
> The App Engine team have made many recent changes which have fixed bugs 
> and improved performance. We will continue to make improvements and add new 
> libraries as time goes on. 
>
> We have seen many applications which have seen significant reductions in 
> the number of instances when using concurrent requests, however concurrent 
> requests will offer the greatest reduction in instance usage when 
> applications are not CPU bound. 
>
> I encourage you to try Python 2.7 with your own applications and look 
> forward to hearing your questions, comments and suggestions for new 
> libraries <http://code.google.com/p/googleappengine/issues/list>. 
>
> Cayden Meyer
> Product Manager, Google App Engine
>
>
>
> On 28 February 2012 06:20, Brandon Wirtz <[email protected]> wrote:
>
>> I’m on 2.7 it made a huge difference. Likely if your app is Data Store 
>> Heavy you will see Massive improvements. If you are computation heavy you 
>> will not.
>>
>> Look at your dashboard the CPU Seconds Use/Second will tell you the ratio 
>> of Instance CPU Cycles to API CPU cycles. On 2.5  I ran at 1/10 the CPU as 
>> the API. On 2.7 I’m at closer to 1/3   
>>
>> That didn’t equate to 1/3 fewer instances but it did equate to half as 
>> many.
>>
>> ****
>>
>> 2.7 seems to be hit harder by the random “everything is taking 3 times as 
>> long” bug.  And 2.7 instance spin up seems to be a bit slower than 2.5 
>> instances.
>> Also because you can have more than one request per instance you have to 
>> be more aware of your memory usage because if you have an app that uses 50 
>> megs of memory and it is serving 3 requests, you will see your instance 
>> killed more often for hitting the soft memory limit.****
>>
>> ** **
>>
>>
>>
>> ****
>>
>> *From:* [email protected] [mailto:
>> [email protected]] *On Behalf Of *Joshua Smith
>> *Sent:* Monday, February 27, 2012 11:57 AM
>> *To:* [email protected]
>> *Subject:* [google-appengine] Py2.7****
>>
>> ** **
>>
>> In today's blog:****
>>
>> * *
>>
>> *We think the Python 2.7 runtime for App Engine is a great step forward 
>> for our developers.  First, it allows applications to take advantage of *
>> *concurrent 
>> requests*<http://code.google.com/appengine/docs/python/python27/newin27.html#Concurrent_Requests>
>> *, allowing you to build more performant and efficient applications. If 
>> your application wasn't fully utilizing the CPU, chances are that you'll be 
>> able to use concurrent requests to reduce the total number of instances and 
>> serve more with less.*****
>>
>>
>>
>> ****
>>
>> That doesn't at all gibe with the stats people have been posting.****
>>
>> ** **
>>
>> From what I've read on these lists, 2.7 is slow at RPCs. But RPCs are the 
>> main way to not fully utilize the CPU. So for most apps, what you gain in 
>> concurrency, you lose in performance per thread.****
>>
>> ** **
>>
>> Is google announcing some performance breakthrough, or is this just 
>> reality-distortion-field stuff?****
>>
>> ** **
>>
>> -Joshua****
>>
>> ** **
>>
>> -- 
>> 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.
>>
>
> 

-- 
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/-/KVXFSo5cWH0J.
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.

Reply via email to