Re: Questions about GIL and web services from a n00b

Discussion in 'Python' started by Chris H, Apr 15, 2011.

  1. Chris H

    Chris H Guest

    On 4/15/11 1:03 PM, Tim Wintle wrote:
    > On Fri, 2011-04-15 at 12:33 -0400, Chris H wrote:
    >> 1. Are you sure you want to use python because threading is not good
    >> due to the Global Lock (GIL)? Is this really an issue for
    >> multi-threaded web services as seems to be indicated by the articles
    >> from a Google search? If not, how do you avoid this issue in a
    >> multi-threaded process to take advantage of all the CPU cores
    >> available?

    > Is the limiting factor CPU?
    >
    > If it isn't (i.e. you're blocking on IO to/from a web service) then the
    > GIL won't get in your way.
    >
    > If it is, then run as many parallel *processes* as you have cores/CPUs
    > (assuming you're designing an application that can have multiple
    > instances running in parallel so that you can run over multiple servers
    > anyway).
    >
    > Tim Wintle


    Great question. At this point, there isn't a limiting factor, but yes
    the concern is around CPU in the future with lots of threads handling
    many simultaneous transactions.

    Chris
     
    Chris H, Apr 15, 2011
    #1
    1. Advertising

  2. > > Is the limiting factor CPU?
    >
    > > If it isn't (i.e. you're blocking on IO to/from a web service) then the
    > > GIL won't get in your way.

    >
    > > If it is, then run as many parallel *processes* as you have cores/CPUs
    > > (assuming you're designing an application that can have multiple
    > > instances running in parallel so that you can run over multiple servers
    > > anyway).

    >
    > Great question.  At this point, there isn't a limiting factor, but yes
    > the concern is around CPU in the future with lots of threads handling
    > many simultaneous transactions.


    In the Python world, the usual solution to high transaction loads is
    to use event-driven processing (using an async library such as
    Twisted) rather than using multi-threading which doesn't scale well in
    any language.

    Also, the usual way to take advantage of multiple-cores is to run
    multiple pythons in separate processes.

    Threading is really only an answer if you need to share data between
    threads, if you only have limited scaling needs, and are I/O bound
    rather than CPU bound


    Raymond
     
    Raymond Hettinger, Apr 16, 2011
    #2
    1. Advertising

  3. On Sat, Apr 16, 2011 at 10:05 AM, Raymond Hettinger <> wrote:
    >> > Is the limiting factor CPU?

    >>
    >> > If it isn't (i.e. you're blocking on IO to/from a web service) then the
    >> > GIL won't get in your way.

    >>
    >> > If it is, then run as many parallel *processes* as you have cores/CPUs
    >> > (assuming you're designing an application that can have multiple
    >> > instances running in parallel so that you can run over multiple servers
    >> > anyway).

    >>
    >> Great question.  At this point, there isn't a limiting factor, but yes
    >> the concern is around CPU in the future with lots of threads handling
    >> many simultaneous transactions.

    >
    > In the Python world, the usual solution to high transaction loads is
    > to use event-driven processing (using an async library such as
    > Twisted) rather than using multi-threading which doesn't scale well in
    > any language.


    My experience is that if you are CPU bound, asynchronous programming
    in python can be more a curse than a blessing, mostly because the
    need to insert "scheduling points" at the right points to avoid
    blocking and because profiling becomes that much harder in something
    like twisted.

    It depends of course of the application, but designing from the ground
    up with the idea of running multiple processes is what seems to be the
    most natural way of scaling - this does not prevent using async in
    each process. This has its own issues, though (e.g. in terms of
    administration and monitoring).

    Chris, the tornado documention mentions a simple way to get multiple
    processes on one box: http://www.tornadoweb.org/documentation (section
    mentiong nginx for load balancing). The principle is quite common and
    is applicable to most frameworks (the solution is not specific to
    tornado).

    cheers.

    David
     
    David Cournapeau, Apr 16, 2011
    #3
  4. Chris H

    Aahz Guest

    In article <>,
    Raymond Hettinger <> wrote:
    >
    >Threading is really only an answer if you need to share data between
    >threads, if you only have limited scaling needs, and are I/O bound
    >rather than CPU bound


    Threads are also useful for user interaction (i.e. GUI apps).

    I think that "limited scaling" needs to be defined, too; CherryPy
    performs pretty well, and the blocking model does simplify development.

    One problem that my company has run into with threading is that it's not
    always obvious where you'll hit GIL blocks. For example, one would
    think that pickle.loads() releases the GIL, but it doesn't; you need to
    use pickle.load() (and cStringIO if you want to do it in memory).
    --
    Aahz () <*> http://www.pythoncraft.com/

    "At Resolver we've found it useful to short-circuit any doubt and just
    refer to comments in code as 'lies'. :)"
    --Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22
     
    Aahz, Apr 16, 2011
    #4
  5. On Sun, Apr 17, 2011 at 12:44 AM, Aahz <> wrote:
    > In article <>,
    > Raymond Hettinger  <> wrote:
    >>
    >>Threading is really only an answer if you need to share data between
    >>threads, if you only have limited scaling needs, and are I/O bound
    >>rather than CPU bound

    >
    > Threads are also useful for user interaction (i.e. GUI apps).


    I agree; user interaction is effectively I/O on, usually, some sort of
    event queue that collects from a variety of sources; with the
    specialty that, in some GUI environments, the process's first thread
    is somehow "special". But ultimately it's still a "worker thread" /
    "interaction thread" model, which is quite a good one. The interaction
    thread spends most of its time waiting for the user, maybe waiting for
    STDIN, maybe waiting for a GUI event, maybe waiting on some I/O device
    (TCP socket comes to mind).

    Chris Angelico
     
    Chris Angelico, Apr 16, 2011
    #5
  6. On Apr 16, 10:44 am, (Aahz) wrote:
    > In article <>,
    > Raymond Hettinger  <> wrote:
    >
    >
    >
    > >Threading is really only an answer if you need to share data between
    > >threads, if you only have limited scaling needs, and are I/O bound
    > >rather than CPU bound

    >
    > Threads are also useful for user interaction (i.e. GUI apps).  
    >


    I suppose that's why most GUI toolkits use a multithreaded model.

    Jean-Paul
     
    Jean-Paul Calderone, Apr 16, 2011
    #6
  7. On 04/16/2011 02:53 PM, Jean-Paul Calderone wrote:
    > On Apr 16, 10:44 am, (Aahz) wrote:
    >> In article <>,
    >> Raymond Hettinger <> wrote:
    >>
    >>
    >>
    >>> Threading is really only an answer if you need to share data between
    >>> threads, if you only have limited scaling needs, and are I/O bound
    >>> rather than CPU bound

    >>
    >> Threads are also useful for user interaction (i.e. GUI apps).
    >>

    >
    > I suppose that's why most GUI toolkits use a multithreaded model.


    Many GUI toolkits are single-threaded. And in fact with GTK and MFC you
    can't (or shouldn't) call GUI calls from a thread other than the main
    GUI thread. That's not to say GUI programs don't use threads and put
    the GUI it its own thread. But GUI toolkits are often *not*
    multithreaded. They are, however, often asynchronous, which is often
    more cost-effective than multi-threaded.
     
    Michael Torrie, Apr 16, 2011
    #7
  8. Chris H

    sturlamolden Guest

    On Apr 16, 4:59 am, David Cournapeau <> wrote:

    > My experience is that if you are CPU bound, asynchronous programming
    > in python can be  more a curse than a blessing, mostly because the
    > need to insert "scheduling points" at the right points to avoid
    > blocking and because profiling becomes that much harder in something
    > like twisted.


    I think Raymond's argument was that multi-threaded server design does
    not scale well in any language. There is a reason that Windows I/O
    completion ports use a pool of worker threads, and not one thread per
    asynchronous I/O request. A multi-threaded design for a webservice
    will hit the wall from inscalability long before CPU saturation
    becomes an issue.
     
    sturlamolden, Apr 17, 2011
    #8
  9. Chris H

    sturlamolden Guest

    On Apr 17, 12:10 am, Michael Torrie <> wrote:

    > Many GUI toolkits are single-threaded.  And in fact with GTK and MFC you
    > can't (or shouldn't) call GUI calls from a thread other than the main
    > GUI thread.


    Most of them (if not all?) have a single GUI thread, and a mechanism
    by which
    to synchronize with the GUI thread.
     
    sturlamolden, Apr 17, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris H
    Replies:
    4
    Views:
    264
    Chris H
    Apr 20, 2011
  2. disappearedng

    n00b questions for javascript!

    disappearedng, Nov 12, 2008, in forum: Javascript
    Replies:
    61
    Views:
    450
    Dr J R Stockton
    Nov 24, 2008
  3. Chris Angelico

    Re: About GIL Questions!

    Chris Angelico, Jun 20, 2013, in forum: Python
    Replies:
    0
    Views:
    124
    Chris Angelico
    Jun 20, 2013
  4. Thanatos xiao

    About GIL Questions!

    Thanatos xiao, Jun 20, 2013, in forum: Python
    Replies:
    0
    Views:
    104
    Thanatos xiao
    Jun 20, 2013
  5. Joshua Landau

    Re: About GIL Questions!

    Joshua Landau, Jun 20, 2013, in forum: Python
    Replies:
    0
    Views:
    109
    Joshua Landau
    Jun 20, 2013
Loading...

Share This Page