librelist archives

« back to archive

strange problem with gunicorn

strange problem with gunicorn

From:
Spacelee
Date:
2013-03-29 @ 06:51
I wrote such simple test program below( it will sleep 10 seconds and print
the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0 to
start listening the 8000 port, but when I open several web browser to open
this site, the server won't handle the second request unless it finished
the first one, so my result of 4 web browser page are below, I don't know
why it will be blocked...

start:23:45:26, end:23:45:36
start:23:45:36, end:23:45:46
start:23:45:47, end:23:45:57
start:23:45:57, end:23:46:07


from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    import time
    import datetime
    start_time = datetime.datetime.now().strftime("%H:%M:%S")
    time.sleep(10)
    end_time = datetime.datetime.now().strftime("%H:%M:%S")
    # interval = str((end_time - start_time))

    ret_val = "start:%s, end:%s" % (start_time, end_time)
    return ret_val
if __name__ == "__main__":
    app.run()




-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Steven Kryskalla
Date:
2013-03-29 @ 08:01
On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
> I wrote such simple test program below( it will sleep 10 seconds and print
> the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0 to start
> listening the 8000 port, but when I open several web browser to open this
> site, the server won't handle the second request unless it finished the
> first one, so my result of 4 web browser page are below, I don't know why it
> will be blocked...

With a low concurrency level (only 4 requests at a time) you're seeing
all requests load balanced to the same worker.

Try spawning 16 requests at once, you should see ~4 requests processed
at a time as the other workers start getting requests.

Also, to confirm, try returning the pid (os.getpid()) in the response,
with a low concurrency, you'll see the same pid returned almost every
time.

-Steve

Re: [flask] strange problem with gunicorn

From:
Owein Reese
Date:
2013-03-29 @ 13:20
If you're worried this may happen in a production environment may I suggest
the combination of gevent or eventlet with gunicorn?
On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com> wrote:

> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
> > I wrote such simple test program below( it will sleep 10 seconds and
> print
> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0 to
> start
> > listening the 8000 port, but when I open several web browser to open this
> > site, the server won't handle the second request unless it finished the
> > first one, so my result of 4 web browser page are below, I don't know
> why it
> > will be blocked...
>
> With a low concurrency level (only 4 requests at a time) you're seeing
> all requests load balanced to the same worker.
>
> Try spawning 16 requests at once, you should see ~4 requests processed
> at a time as the other workers start getting requests.
>
> Also, to confirm, try returning the pid (os.getpid()) in the response,
> with a low concurrency, you'll see the same pid returned almost every
> time.
>
> -Steve
>

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-03-31 @ 13:20
I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000 (6560)
2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566


and as you see, it already starts to use gevent.

start:21:15:40, end:21:15:50, pid:6538
start:21:15:50, end:21:16:00, pid:6538
start:21:16:00, end:21:16:10, pid:6538

but the results are the same, all the requests are routed to one process,
and it's not concurrent...

On Fri, Mar 29, 2013 at 9:20 PM, Owein Reese <owreese@gmail.com> wrote:

> If you're worried this may happen in a production environment may I
> suggest the combination of gevent or eventlet with gunicorn?
> On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com> wrote:
>
>> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
>> > I wrote such simple test program below( it will sleep 10 seconds and
>> print
>> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0 to
>> start
>> > listening the 8000 port, but when I open several web browser to open
>> this
>> > site, the server won't handle the second request unless it finished the
>> > first one, so my result of 4 web browser page are below, I don't know
>> why it
>> > will be blocked...
>>
>> With a low concurrency level (only 4 requests at a time) you're seeing
>> all requests load balanced to the same worker.
>>
>> Try spawning 16 requests at once, you should see ~4 requests processed
>> at a time as the other workers start getting requests.
>>
>> Also, to confirm, try returning the pid (os.getpid()) in the response,
>> with a low concurrency, you'll see the same pid returned almost every
>> time.
>>
>> -Steve
>>
>


-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Igor Davydenko
Date:
2013-04-01 @ 07:41
Not sure about gevent, but eventlet concurrency doesn't work without monkey
patching standard library.
On Mar 31, 2013 4:21 PM, "Spacelee" <fjctlzy@gmail.com> wrote:

> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>
>
> and as you see, it already starts to use gevent.
>
> start:21:15:40, end:21:15:50, pid:6538
> start:21:15:50, end:21:16:00, pid:6538
> start:21:16:00, end:21:16:10, pid:6538
>
> but the results are the same, all the requests are routed to one process,
> and it's not concurrent...
>
> On Fri, Mar 29, 2013 at 9:20 PM, Owein Reese <owreese@gmail.com> wrote:
>
>> If you're worried this may happen in a production environment may I
>> suggest the combination of gevent or eventlet with gunicorn?
>> On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com> wrote:
>>
>>> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
>>> > I wrote such simple test program below( it will sleep 10 seconds and
>>> print
>>> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0 to
>>> start
>>> > listening the 8000 port, but when I open several web browser to open
>>> this
>>> > site, the server won't handle the second request unless it finished the
>>> > first one, so my result of 4 web browser page are below, I don't know
>>> why it
>>> > will be blocked...
>>>
>>> With a low concurrency level (only 4 requests at a time) you're seeing
>>> all requests load balanced to the same worker.
>>>
>>> Try spawning 16 requests at once, you should see ~4 requests processed
>>> at a time as the other workers start getting requests.
>>>
>>> Also, to confirm, try returning the pid (os.getpid()) in the response,
>>> with a low concurrency, you'll see the same pid returned almost every
>>> time.
>>>
>>> -Steve
>>>
>>
>
>
> --
> *Space Lee*
>

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-04-01 @ 09:15
In fact, I think the problem is not gunicorn but flask itself...changing to
uwsgi or tornado won't change anything, it seems if the url is too long to
process, it will block the rest of requests to the Process that handle the
pre-long-request...That sounds strange....


On Mon, Apr 1, 2013 at 3:41 PM, Igor Davydenko
<playpauseandstop@gmail.com>wrote:

> Not sure about gevent, but eventlet concurrency doesn't work without
> monkey patching standard library.
> On Mar 31, 2013 4:21 PM, "Spacelee" <fjctlzy@gmail.com> wrote:
>
>> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
>> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
>> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
>> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
>> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
>> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
>> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
>> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>>
>>
>> and as you see, it already starts to use gevent.
>>
>> start:21:15:40, end:21:15:50, pid:6538
>> start:21:15:50, end:21:16:00, pid:6538
>> start:21:16:00, end:21:16:10, pid:6538
>>
>> but the results are the same, all the requests are routed to one process,
>> and it's not concurrent...
>>
>> On Fri, Mar 29, 2013 at 9:20 PM, Owein Reese <owreese@gmail.com> wrote:
>>
>>> If you're worried this may happen in a production environment may I
>>> suggest the combination of gevent or eventlet with gunicorn?
>>> On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
>>>> > I wrote such simple test program below( it will sleep 10 seconds and
>>>> print
>>>> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0
>>>> to start
>>>> > listening the 8000 port, but when I open several web browser to open
>>>> this
>>>> > site, the server won't handle the second request unless it finished
>>>> the
>>>> > first one, so my result of 4 web browser page are below, I don't know
>>>> why it
>>>> > will be blocked...
>>>>
>>>> With a low concurrency level (only 4 requests at a time) you're seeing
>>>> all requests load balanced to the same worker.
>>>>
>>>> Try spawning 16 requests at once, you should see ~4 requests processed
>>>> at a time as the other workers start getting requests.
>>>>
>>>> Also, to confirm, try returning the pid (os.getpid()) in the response,
>>>> with a low concurrency, you'll see the same pid returned almost every
>>>> time.
>>>>
>>>> -Steve
>>>>
>>>
>>
>>
>> --
>> *Space Lee*
>>
>


-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Igor Davydenko
Date:
2013-04-01 @ 10:05
My bad, don't read topic accurately from start, after re-reading and
playing with Gunicorn + gevent/eventlet + Flask/WSGI app got same results.
Think problem somewhere in WSGI protocol, not in Flask/Gunicorn, but this
is strange and rough estimate.


On 1 April 2013 12:15, Spacelee <fjctlzy@gmail.com> wrote:

> In fact, I think the problem is not gunicorn but flask itself...changing
> to uwsgi or tornado won't change anything, it seems if the url is too long
> to process, it will block the rest of requests to the Process that handle
> the pre-long-request...That sounds strange....
>
>
> On Mon, Apr 1, 2013 at 3:41 PM, Igor Davydenko <playpauseandstop@gmail.com
> > wrote:
>
>> Not sure about gevent, but eventlet concurrency doesn't work without
>> monkey patching standard library.
>> On Mar 31, 2013 4:21 PM, "Spacelee" <fjctlzy@gmail.com> wrote:
>>
>>> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
>>> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
>>> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
>>> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
>>> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
>>> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
>>> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
>>> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>>>
>>>
>>> and as you see, it already starts to use gevent.
>>>
>>> start:21:15:40, end:21:15:50, pid:6538
>>> start:21:15:50, end:21:16:00, pid:6538
>>> start:21:16:00, end:21:16:10, pid:6538
>>>
>>> but the results are the same, all the requests are routed to one
>>> process, and it's not concurrent...
>>>
>>> On Fri, Mar 29, 2013 at 9:20 PM, Owein Reese <owreese@gmail.com> wrote:
>>>
>>>> If you're worried this may happen in a production environment may I
>>>> suggest the combination of gevent or eventlet with gunicorn?
>>>> On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com>
>>>> wrote:
>>>>
>>>>> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
>>>>> > I wrote such simple test program below( it will sleep 10 seconds and
>>>>> print
>>>>> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0
>>>>> to start
>>>>> > listening the 8000 port, but when I open several web browser to open
>>>>> this
>>>>> > site, the server won't handle the second request unless it finished
>>>>> the
>>>>> > first one, so my result of 4 web browser page are below, I don't
>>>>> know why it
>>>>> > will be blocked...
>>>>>
>>>>> With a low concurrency level (only 4 requests at a time) you're seeing
>>>>> all requests load balanced to the same worker.
>>>>>
>>>>> Try spawning 16 requests at once, you should see ~4 requests processed
>>>>> at a time as the other workers start getting requests.
>>>>>
>>>>> Also, to confirm, try returning the pid (os.getpid()) in the response,
>>>>> with a low concurrency, you'll see the same pid returned almost every
>>>>> time.
>>>>>
>>>>> -Steve
>>>>>
>>>>
>>>
>>>
>>> --
>>> *Space Lee*
>>>
>>
>
>
> --
> *Space Lee*
>



-- 
Sincerely,
Igor Davydenko

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-04-01 @ 08:08
I check the gunicorn source code, and the file shows that it already adds
monkey patch:

class GeventWorker(AsyncWorker):

    server_class = None
    wsgi_handler = None

    @classmethod
    def setup(cls):
        from gevent import monkey
        monkey.noisy = False
        monkey.patch_all()




On Mon, Apr 1, 2013 at 3:41 PM, Igor Davydenko
<playpauseandstop@gmail.com>wrote:

> Not sure about gevent, but eventlet concurrency doesn't work without
> monkey patching standard library.
> On Mar 31, 2013 4:21 PM, "Spacelee" <fjctlzy@gmail.com> wrote:
>
>> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
>> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
>> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
>> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
>> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
>> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
>> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
>> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>>
>>
>> and as you see, it already starts to use gevent.
>>
>> start:21:15:40, end:21:15:50, pid:6538
>> start:21:15:50, end:21:16:00, pid:6538
>> start:21:16:00, end:21:16:10, pid:6538
>>
>> but the results are the same, all the requests are routed to one process,
>> and it's not concurrent...
>>
>> On Fri, Mar 29, 2013 at 9:20 PM, Owein Reese <owreese@gmail.com> wrote:
>>
>>> If you're worried this may happen in a production environment may I
>>> suggest the combination of gevent or eventlet with gunicorn?
>>> On Mar 29, 2013 4:03 AM, "Steven Kryskalla" <skryskalla@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Mar 28, 2013 at 11:51 PM, Spacelee <fjctlzy@gmail.com> wrote:
>>>> > I wrote such simple test program below( it will sleep 10 seconds and
>>>> print
>>>> > the start&end time) , and using:  gunicorn -w 4 test:app -b 0.0.0.0
>>>> to start
>>>> > listening the 8000 port, but when I open several web browser to open
>>>> this
>>>> > site, the server won't handle the second request unless it finished
>>>> the
>>>> > first one, so my result of 4 web browser page are below, I don't know
>>>> why it
>>>> > will be blocked...
>>>>
>>>> With a low concurrency level (only 4 requests at a time) you're seeing
>>>> all requests load balanced to the same worker.
>>>>
>>>> Try spawning 16 requests at once, you should see ~4 requests processed
>>>> at a time as the other workers start getting requests.
>>>>
>>>> Also, to confirm, try returning the pid (os.getpid()) in the response,
>>>> with a low concurrency, you'll see the same pid returned almost every
>>>> time.
>>>>
>>>> -Steve
>>>>
>>>
>>
>>
>> --
>> *Space Lee*
>>
>


-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Audrius Kažukauskas
Date:
2013-04-01 @ 11:31
On Sun, 2013-03-31 at 21:20:47 +0800, Spacelee wrote:
> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000 (6560)
> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
> 
> and as you see, it already starts to use gevent.
> 
> start:21:15:40, end:21:15:50, pid:6538
> start:21:15:50, end:21:16:00, pid:6538
> start:21:16:00, end:21:16:10, pid:6538
> 
> but the results are the same, all the requests are routed to one process,
> and it's not concurrent...

This is strange, it works correctly here.  I'm running your webapp,
which I modified to sleep for 5 seconds and return PID together with
times.  The webapp is started as follows:

  $ gunicorn -w 4 foo:app -k gevent
  2013-04-01 14:17:00 [7071] [INFO] Starting gunicorn 0.17.2
  2013-04-01 14:17:00 [7071] [INFO] Listening at: http://127.0.0.1:8000 (7071)
  2013-04-01 14:17:00 [7071] [INFO] Using worker: gevent
  2013-04-01 14:17:00 [7076] [INFO] Booting worker with pid: 7076
  2013-04-01 14:17:00 [7077] [INFO] Booting worker with pid: 7077
  2013-04-01 14:17:00 [7078] [INFO] Booting worker with pid: 7078
  2013-04-01 14:17:00 [7079] [INFO] Booting worker with pid: 7079

I then ran the following shell script to fire 16 parallel requests at
it:

  for i in $(seq 16); do
    curl localhost:8000 &
  done
  wait

And here are the results:

  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7077

As you can see, all the requests were handled at the same time and by
the different workers.  gevent-0.13.8 and gunicorn-0.17.2 were used for
testing.

-- 
Audrius Kažukauskas
http://neutrino.lt/

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-04-01 @ 15:32
I tried from the chrome web browser, could you please try to open 5 tabs
and refresh each of them quickly to see if there is any difference.


On Mon, Apr 1, 2013 at 7:31 PM, Audrius Kažukauskas <audrius@neutrino.lt>wrote:

> On Sun, 2013-03-31 at 21:20:47 +0800, Spacelee wrote:
> > I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
> > 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
> > 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
> > 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
> > 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
> > 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
> > 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
> > 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
> >
> > and as you see, it already starts to use gevent.
> >
> > start:21:15:40, end:21:15:50, pid:6538
> > start:21:15:50, end:21:16:00, pid:6538
> > start:21:16:00, end:21:16:10, pid:6538
> >
> > but the results are the same, all the requests are routed to one process,
> > and it's not concurrent...
>
> This is strange, it works correctly here.  I'm running your webapp,
> which I modified to sleep for 5 seconds and return PID together with
> times.  The webapp is started as follows:
>
>   $ gunicorn -w 4 foo:app -k gevent
>   2013-04-01 14:17:00 [7071] [INFO] Starting gunicorn 0.17.2
>   2013-04-01 14:17:00 [7071] [INFO] Listening at: http://127.0.0.1:8000(7071)
>   2013-04-01 14:17:00 [7071] [INFO] Using worker: gevent
>   2013-04-01 14:17:00 [7076] [INFO] Booting worker with pid: 7076
>   2013-04-01 14:17:00 [7077] [INFO] Booting worker with pid: 7077
>   2013-04-01 14:17:00 [7078] [INFO] Booting worker with pid: 7078
>   2013-04-01 14:17:00 [7079] [INFO] Booting worker with pid: 7079
>
> I then ran the following shell script to fire 16 parallel requests at
> it:
>
>   for i in $(seq 16); do
>     curl localhost:8000 &
>   done
>   wait
>
> And here are the results:
>
>   start: 14:17:20 end: 14:17:25 pid: 7078
>   start: 14:17:20 end: 14:17:25 pid: 7077
>   start: 14:17:20 end: 14:17:25 pid: 7077
>   start: 14:17:20 end: 14:17:25 pid: 7077
>   start: 14:17:20 end: 14:17:25 pid: 7076
>   start: 14:17:20 end: 14:17:25 pid: 7079
>   start: 14:17:20 end: 14:17:25 pid: 7076
>   start: 14:17:20 end: 14:17:25 pid: 7076
>   start: 14:17:20 end: 14:17:25 pid: 7079
>   start: 14:17:20 end: 14:17:25 pid: 7078
>   start: 14:17:20 end: 14:17:25 pid: 7078
>   start: 14:17:20 end: 14:17:25 pid: 7078
>   start: 14:17:20 end: 14:17:25 pid: 7077
>   start: 14:17:20 end: 14:17:25 pid: 7077
>   start: 14:17:20 end: 14:17:25 pid: 7079
>   start: 14:17:20 end: 14:17:25 pid: 7077
>
> As you can see, all the requests were handled at the same time and by
> the different workers.  gevent-0.13.8 and gunicorn-0.17.2 were used for
> testing.
>
> --
> Audrius Kažukauskas
> http://neutrino.lt/
>



-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Shawn Milochik
Date:
2013-04-01 @ 15:37
If you install apache2-utils, you'll get the "ab" (Apache Benchmark)
utility. You can use this to specify any number of hits and any number
of concurrent requests (or not).

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-04-01 @ 15:41
in fact, when I tried from curl, it works like yours, but when I tried this
from web browser, it seems blocked, I don't know what's the difference
between these two situations...?


On Mon, Apr 1, 2013 at 11:32 PM, Spacelee <fjctlzy@gmail.com> wrote:

> I tried from the chrome web browser, could you please try to open 5 tabs
> and refresh each of them quickly to see if there is any difference.
>
>
> On Mon, Apr 1, 2013 at 7:31 PM, Audrius Kažukauskas <audrius@neutrino.lt>wrote:
>
>> On Sun, 2013-03-31 at 21:20:47 +0800, Spacelee wrote:
>> > I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
>> > 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
>> > 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
>> > 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
>> > 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
>> > 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
>> > 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
>> > 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>> >
>> > and as you see, it already starts to use gevent.
>> >
>> > start:21:15:40, end:21:15:50, pid:6538
>> > start:21:15:50, end:21:16:00, pid:6538
>> > start:21:16:00, end:21:16:10, pid:6538
>> >
>> > but the results are the same, all the requests are routed to one
>> process,
>> > and it's not concurrent...
>>
>> This is strange, it works correctly here.  I'm running your webapp,
>> which I modified to sleep for 5 seconds and return PID together with
>> times.  The webapp is started as follows:
>>
>>   $ gunicorn -w 4 foo:app -k gevent
>>   2013-04-01 14:17:00 [7071] [INFO] Starting gunicorn 0.17.2
>>   2013-04-01 14:17:00 [7071] [INFO] Listening at: http://127.0.0.1:8000(7071)
>>   2013-04-01 14:17:00 [7071] [INFO] Using worker: gevent
>>   2013-04-01 14:17:00 [7076] [INFO] Booting worker with pid: 7076
>>   2013-04-01 14:17:00 [7077] [INFO] Booting worker with pid: 7077
>>   2013-04-01 14:17:00 [7078] [INFO] Booting worker with pid: 7078
>>   2013-04-01 14:17:00 [7079] [INFO] Booting worker with pid: 7079
>>
>> I then ran the following shell script to fire 16 parallel requests at
>> it:
>>
>>   for i in $(seq 16); do
>>     curl localhost:8000 &
>>   done
>>   wait
>>
>> And here are the results:
>>
>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>
>> As you can see, all the requests were handled at the same time and by
>> the different workers.  gevent-0.13.8 and gunicorn-0.17.2 were used for
>> testing.
>>
>> --
>> Audrius Kažukauskas
>> http://neutrino.lt/
>>
>
>
>
> --
> *Space Lee*
>



-- 
*Space Lee*

Re: [flask] strange problem with gunicorn

From:
Lucas Rolff
Date:
2013-04-01 @ 15:47
That your browser will actually wait for the response to that host, for 
all windows, so yes it will block the request.

That's why curl is good for testing, not a browser, if you want to test 
concurrency at least.

Sent from my iPhone

On 01/04/2013, at 23.42, "Spacelee" 
<fjctlzy@gmail.com<mailto:fjctlzy@gmail.com>> wrote:

in fact, when I tried from curl, it works like yours, but when I tried 
this from web browser, it seems blocked, I don't know what's the 
difference between these two situations...?


On Mon, Apr 1, 2013 at 11:32 PM, Spacelee 
<fjctlzy@gmail.com<mailto:fjctlzy@gmail.com>> wrote:
I tried from the chrome web browser, could you please try to open 5 tabs 
and refresh each of them quickly to see if there is any difference.


On Mon, Apr 1, 2013 at 7:31 PM, Audrius Kažukauskas 
<audrius@neutrino.lt<mailto:audrius@neutrino.lt>> wrote:
On Sun, 2013-03-31 at 21:20:47 +0800, Spacelee wrote:
> I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
> 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
> 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000 (6560)
> 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
> 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
> 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
> 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
> 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>
> and as you see, it already starts to use gevent.
>
> start:21:15:40, end:21:15:50, pid:6538
> start:21:15:50, end:21:16:00, pid:6538
> start:21:16:00, end:21:16:10, pid:6538
>
> but the results are the same, all the requests are routed to one process,
> and it's not concurrent...

This is strange, it works correctly here.  I'm running your webapp,
which I modified to sleep for 5 seconds and return PID together with
times.  The webapp is started as follows:

  $ gunicorn -w 4 foo:app -k gevent
  2013-04-01 14:17:00 [7071] [INFO] Starting gunicorn 0.17.2
  2013-04-01 14:17:00 [7071] [INFO] Listening at: http://127.0.0.1:8000 (7071)
  2013-04-01 14:17:00 [7071] [INFO] Using worker: gevent
  2013-04-01 14:17:00 [7076] [INFO] Booting worker with pid: 7076
  2013-04-01 14:17:00 [7077] [INFO] Booting worker with pid: 7077
  2013-04-01 14:17:00 [7078] [INFO] Booting worker with pid: 7078
  2013-04-01 14:17:00 [7079] [INFO] Booting worker with pid: 7079

I then ran the following shell script to fire 16 parallel requests at
it:

  for i in $(seq 16); do
    curl localhost:8000 &
  done
  wait

And here are the results:

  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7076
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7078
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7077
  start: 14:17:20 end: 14:17:25 pid: 7079
  start: 14:17:20 end: 14:17:25 pid: 7077

As you can see, all the requests were handled at the same time and by
the different workers.  gevent-0.13.8 and gunicorn-0.17.2 were used for
testing.

--
Audrius Kažukauskas
http://neutrino.lt/



--
Space Lee



--
Space Lee

Re: [flask] strange problem with gunicorn

From:
Spacelee
Date:
2013-04-01 @ 15:52
Got it!
So from the curl or ab test, it's concurrent...thanks for everyone of you.


On Mon, Apr 1, 2013 at 11:47 PM, Lucas Rolff <Lucas.Rolff@spilgames.com>wrote:

>  That your browser will actually wait for the response to that host, for
> all windows, so yes it will block the request.
>
>  That's why curl is good for testing, not a browser, if you want to test
> concurrency at least.
>
> Sent from my iPhone
>
> On 01/04/2013, at 23.42, "Spacelee" <fjctlzy@gmail.com> wrote:
>
>   in fact, when I tried from curl, it works like yours, but when I tried
> this from web browser, it seems blocked, I don't know what's the difference
> between these two situations...?
>
>
> On Mon, Apr 1, 2013 at 11:32 PM, Spacelee <fjctlzy@gmail.com> wrote:
>
>> I tried from the chrome web browser, could you please try to open 5 tabs
>> and refresh each of them quickly to see if there is any difference.
>>
>>
>> On Mon, Apr 1, 2013 at 7:31 PM, Audrius Kažukauskas <audrius@neutrino.lt>wrote:
>>
>>> On Sun, 2013-03-31 at 21:20:47 +0800, Spacelee wrote:
>>> > I use this command to start gunicorn: gunicorn -w 4 test:app -k gevent
>>> > 2013-03-31 21:18:52 [6560] [INFO] Starting gunicorn 0.17.2
>>> > 2013-03-31 21:18:52 [6560] [INFO] Listening at: http://127.0.0.1:8000(6560)
>>> > 2013-03-31 21:18:52 [6560] [INFO] Using worker: gevent
>>> > 2013-03-31 21:18:52 [6563] [INFO] Booting worker with pid: 6563
>>> > 2013-03-31 21:18:52 [6564] [INFO] Booting worker with pid: 6564
>>> > 2013-03-31 21:18:52 [6565] [INFO] Booting worker with pid: 6565
>>> > 2013-03-31 21:18:52 [6566] [INFO] Booting worker with pid: 6566
>>> >
>>> > and as you see, it already starts to use gevent.
>>> >
>>> > start:21:15:40, end:21:15:50, pid:6538
>>> > start:21:15:50, end:21:16:00, pid:6538
>>> > start:21:16:00, end:21:16:10, pid:6538
>>> >
>>> > but the results are the same, all the requests are routed to one
>>> process,
>>> > and it's not concurrent...
>>>
>>> This is strange, it works correctly here.  I'm running your webapp,
>>> which I modified to sleep for 5 seconds and return PID together with
>>> times.  The webapp is started as follows:
>>>
>>>   $ gunicorn -w 4 foo:app -k gevent
>>>   2013-04-01 14:17:00 [7071] [INFO] Starting gunicorn 0.17.2
>>>   2013-04-01 14:17:00 [7071] [INFO] Listening at: http://127.0.0.1:8000(7071)
>>>   2013-04-01 14:17:00 [7071] [INFO] Using worker: gevent
>>>   2013-04-01 14:17:00 [7076] [INFO] Booting worker with pid: 7076
>>>   2013-04-01 14:17:00 [7077] [INFO] Booting worker with pid: 7077
>>>   2013-04-01 14:17:00 [7078] [INFO] Booting worker with pid: 7078
>>>   2013-04-01 14:17:00 [7079] [INFO] Booting worker with pid: 7079
>>>
>>> I then ran the following shell script to fire 16 parallel requests at
>>> it:
>>>
>>>   for i in $(seq 16); do
>>>     curl localhost:8000 &
>>>   done
>>>   wait
>>>
>>> And here are the results:
>>>
>>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>>   start: 14:17:20 end: 14:17:25 pid: 7076
>>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>>   start: 14:17:20 end: 14:17:25 pid: 7078
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>   start: 14:17:20 end: 14:17:25 pid: 7079
>>>   start: 14:17:20 end: 14:17:25 pid: 7077
>>>
>>> As you can see, all the requests were handled at the same time and by
>>> the different workers.  gevent-0.13.8 and gunicorn-0.17.2 were used for
>>> testing.
>>>
>>> --
>>> Audrius Kažukauskas
>>> http://neutrino.lt/
>>>
>>
>>
>>
>>  --
>> *Space Lee*
>>
>
>
>
>  --
> *Space Lee*
>
>


-- 
*Space Lee*