Multithreading question

68 views
Skip to first unread message

Richard Arrano

unread,
Nov 22, 2011, 3:18:29 PM11/22/11
to Google App Engine
Hello,
Quick question regarding multithreading in Python 2.7:
I have some requests that call 2-3 functions that call the memcache in
each function. It would be possible but quite complicated to just use
get_multi, and I was wondering if I could simply put each function
into a thread and run the 2-3 threads to achieve some parallelism.
Would this work or am I misunderstood about what we can and cannot do
with regards to multithreading in 2.7?

Thanks,
Richard

Brandon Wirtz

unread,
Nov 22, 2011, 3:22:48 PM11/22/11
to google-a...@googlegroups.com
Front end could mult-get 3 requests from the backend. You don't even need
2.7 to do that.

Thanks,
Richard

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


Brian Quinlan

unread,
Nov 22, 2011, 3:37:31 PM11/22/11
to google-a...@googlegroups.com
Hi Richard,

This will certainly work put I'm not sure that it would be worth the complexity.

Fetching a value from memcache usually takes <5ms so parallelizing 3
memcache gets is going to save you ~10ms.

Cheers,
Brian

Richard Arrano

unread,
Nov 22, 2011, 4:48:33 PM11/22/11
to Google App Engine
@Brandon:
This is true but it just would take a lot of rewriting that may or may
not be worth it.

@Brian
Thanks for the tip, I didn't even realize that(I haven't been using
AppStats, shame on me). Would the savings be worth it, in your
opinion, when they're not present in the cache and have to resort to 3
gets of varying size?

On Nov 22, 12:37 pm, Brian Quinlan <bquin...@google.com> wrote:
> Hi Richard,
>

Brian Quinlan

unread,
Nov 22, 2011, 4:56:11 PM11/22/11
to google-a...@googlegroups.com
On Wed, Nov 23, 2011 at 8:48 AM, Richard Arrano <ricka...@gmail.com> wrote:
> @Brandon:
> This is true but it just would take a lot of rewriting that may or may
> not be worth it.
>
> @Brian
> Thanks for the tip, I didn't even realize that(I haven't been using
> AppStats, shame on me). Would the savings be worth it, in your
> opinion, when they're not present in the cache and have to resort to 3
> gets of varying size?

Its hard to give advice on this kind of complexity vs. performance
trade-off without really understanding the application.

Datastore gets are slower than memcache gets but are still pretty quick.

Cheers,
Brian

Richard Arrano

unread,
Nov 22, 2011, 5:11:05 PM11/22/11
to Google App Engine
I see, I'm guessing it probably isn't worth it to optimize this
particular area but it's good to know that the multithreading ability
would work in a more complex instance where I truly needed the
parallelism.

One last question on the topic, having to do with threadsafe: the
function that I was referring to was actually a decorator that checks
certain permissions that I insert before a large amount of handlers.
It also stores the returned objects via self.permissions for example.
Is there a possibility of a race condition on self.permissions or does
it function in such a manner that this is impossible?

Thanks,
Richard

On Nov 22, 1:56 pm, Brian Quinlan <bquin...@google.com> wrote:

Anand Mistry

unread,
Nov 22, 2011, 6:43:32 PM11/22/11
to google-a...@googlegroups.com
In general, I would recommend against creating threads in frontends unless your request is long-lived since thread creation is a fairly heavy weight operation. get_multi() is probably the best way to get multiple values from memcache because it amortises the cost of making the RPC, both in terms of CPU and wall time.

Brian Quinlan

unread,
Nov 22, 2011, 6:55:46 PM11/22/11
to google-a...@googlegroups.com
On Wed, Nov 23, 2011 at 9:11 AM, Richard Arrano <ricka...@gmail.com> wrote:
> I see, I'm guessing it probably isn't worth it to optimize this
> particular area but it's good to know that the multithreading ability
> would work in a more complex instance where I truly needed the
> parallelism.
>
> One last question on the topic, having to do with threadsafe: the
> function that I was referring to was actually a decorator that checks
> certain permissions that I insert before a large amount of handlers.
> It also stores the returned objects via self.permissions for example.
> Is there a possibility of a race condition on self.permissions or does
> it function in such a manner that this is impossible?

If you are using webapp2 then a new handler instance is created for
every request.

Cheers,
Brian

Joshua Smith

unread,
Nov 23, 2011, 8:48:34 AM11/23/11
to google-a...@googlegroups.com

On Nov 22, 2011, at 6:43 PM, Anand Mistry wrote:

thread creation is a fairly heavy weight operation

Who else sees the irony in this statement?

Nick Johnson

unread,
Nov 24, 2011, 12:42:35 AM11/24/11
to google-a...@googlegroups.com
Hi Richard,

Consider using NDB, and its coroutine-based parallelism. It's pretty much exactly built for this situation: if you have multiple coroutines, each one will be run until it attempts to wait on an RPC (such as a datastore or memcache operation), then the requests will all be automatically batched together and executed as efficiently as possible. Thus, you get the benefits of get_multi, without the complexity of restructuring your code for it.

-Nick Johnson

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




--
Nick Johnson, Developer Programs Engineer, App Engine


Reply all
Reply to author
Forward
0 new messages