Webpy via Nginx + Flup + Spawn-fgi
skp_999
found at http://webpy.org/cookbook/fastcgi-nginx):
relevant part of my nginx.conf (nginx runs with 1 master and 1
worker):
-----
location / {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_pass 127.0.0.1:8100;
}
-----
how I spawn my fcgi processes:
-----
spawn-fcgi -C 5 -f /path/to/myapp.py -a 127.0.0.1 -p 8100 -P /path/to/
myapppid.pid
-----
myapp.py
-----
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import web
urls = ("/.*", "hello")
app = web.application(urls, globals())
class hello:
def GET(self):
return 'Hello, world!'
if __name__ == "__main__":
web.wsgi.runwsgi = lambda func, addr = None: web.wsgi.runfcgi(func,
addr)
app.run()
------
wsgi.py of Webpy
-----
def runfcgi(func, addr=('localhost', 8000)):
"""Runs a WSGI function as a FastCGI server."""
import flup.server.fcgi as flups
return flups.WSGIServer(func, multiplexed=True,
bindAddress=addr).run()
----
Now my questions:
1) Should I spawn 1 or more myapp.py processes (with '-C 5' I have 5
workers) ?
2) Should I run flups with multiplexed=True or False (and/or other
options) ?
3) Do I need a different fcgi port for each of my webpy apps (I'm
talking about port 8000 in wsgi.py) ?
BTW Right now my env variables report :
wsgi.multiprocess: False
wsgi.multithread: True
but with 'top' I see also my 5 processes
tnx
David Shieh
2. I think you should use multiplexed=True
3. If you use some different ports to run web.py, your nginx will a
proxy server then. And I do think this will make your app even faster.
BTW, I don't write any wsgi.py for webpy, just app.py for my
application. Is this wsgi.py part of web.py or you wrote it?
On 1月30日, 下午4时22分, skp_999 <scar...@gmail.com> wrote:
> I run my webpy apps with the following configuration (based on infos
> found athttp://webpy.org/cookbook/fastcgi-nginx):
Graham Dumpleton
On Feb 1, 12:39 pm, David Shieh <mykinghea...@gmail.com> wrote:
> 1. You should use -C 5 or even more, like -C 10
> 2. I think you should use multiplexed=True
Anecdotal evidence from past discussions elsewhere suggests that using
multiplexing is a bad idea and actually slows things down. Pretty well
all FASTCGI hosting mechanisms don't support multiplexing anyway, and
that is part of the issue. That is, you are enabling a feature that
will not do anything and the overhead of it being used in an
environment where it isn't supported seems to slow things down.
Graham
David Shieh
On 2月1日, 上午9时47分, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> On Feb 1, 12:39 pm, David Shieh <mykinghea...@gmail.com> wrote:
>
> > 1. You should use -C 5 or even more, like -C 10
> > 2. I think you should use multiplexed=True
>
> Anecdotal evidence from past discussions elsewhere suggests that using
> multiplexing is a bad idea and actually slows things down. Pretty well
> all FASTCGI hosting mechanisms don't support multiplexing anyway, and
> that is part of the issue. That is, you are enabling a feature that
> will not do anything and the overhead of it being used in an
> environment where it isn't supported seems to slow things down.
>
I didn't do any test for this, and even don't use this parameter, I
just thought it will be better.
And as a matter of fact like you said, it's a bad solution. It's my
fault, I am sorry.
Thanks for mentioning, man.
Graham Dumpleton
On Feb 1, 1:24 pm, David Shieh <mykinghea...@gmail.com> wrote:
> On 2月1日, 上午9时47分, Graham Dumpleton <graham.dumple...@gmail.com> wrote:> On Feb 1, 12:39 pm, David Shieh <mykinghea...@gmail.com> wrote:
>
> > > 1. You should use -C 5 or even more, like -C 10
> > > 2. I think you should use multiplexed=True
>
> > Anecdotal evidence from past discussions elsewhere suggests that using
> > multiplexing is a bad idea and actually slows things down. Pretty well
> > all FASTCGI hosting mechanisms don't support multiplexing anyway, and
> > that is part of the issue. That is, you are enabling a feature that
> > will not do anything and the overhead of it being used in an
> > environment where it isn't supported seems to slow things down.
>
> I didn't do any test for this, and even don't use this parameter, I
> just thought it will be better.
> And as a matter of fact like you said, it's a bad solution. It's my
> fault, I am sorry.
For the record, my feeling on the multiplexing option is that it
wouldn't even necessarily help with performance anyway. This is
because you are trying to shove more data, ie., for multiple requests,
done the same connection. If the reader at either end blocks, then one
would have to think that you are therefore blocking the flow of data
for all concurrent requests across that multiplexed connections.
As such, use of multiplexing may, if supported by hosting mechanism,
make sense if concerned about resource usage, ie., total number of
file descriptors in use across a system, but as far as performance
goes, from a technical standpoint I can't see how it would help one
bit.
Graham
skp_999
skp_999
(webserver, ...). I'm not really concerned about speed (I share the
server with other people so my concerns are cpu&mem) but I want to
config Webpy in the best way. So a little recap:
1. Nginx with one master process and one worker (I don't want to
change this)
2. Spawn-fcgi relevant options are:
-C <children> (PHP only) numbers of childs to spawn (default:
not setting
the PHP_FCGI_CHILDREN environment variable - PHP defaults to
0)
-F <children> number of children to fork (default 1)
-n no fork (for daemontools)
So C seems useless since I use Python (correct?). So -F and -n ?
3. Multiplexing True or False ?
4. Other options to pass to Flup (other than Multiplexing) ?
tnx
xiaobing jiang
in my test and code review:
1. nginx doesn't support mutilplexing.
2. when using mutilplexing , flup will create 2 thread ( one is in
thread pool, another is in _start_request).
because flup using thread.start_new_thread, and webpy using
threading.current_thread. so here are many
DummyThread object in threading module. it don't free memory.
from threading module source:
# Dummy thread class to represent threads not started here.
# These aren't garbage collected when they die, nor can they
be waited for.
# If they invoke anything in threading.py that calls
current_thread(), they
# leave an entry in the _active dict forever after.
# Their purpose is to return *something* from current_thread().
# They are marked as daemon threads so we won't wait for them
# when we exit (conform previous semantics).
4. maybe maxSpare.
another:
1. careful flup bug, fix in trunk but not released.
2. if using mysql-python, it leaks memory.
https://sourceforge.net/tracker/?func=detail&aid=1464563&group_id=22307&atid=374932
> --
> You received this message because you are subscribed to the Google Groups "web.py" group.
> To post to this group, send email to we...@googlegroups.com.
> To unsubscribe from this group, send email to webpy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
>
>
skp_999
Mercurial repository, run Spawn-fcgi with default values (so -C 0 -F
1). I'll do some tests...
tnx
On 1 Feb, 09:59, xiaobing jiang <s7v7nisla...@gmail.com> wrote:
> 3. False
> in my test and code review:
> 1. nginx doesn't support mutilplexing.
> 2. when using mutilplexing , flup will create 2 thread ( one is in
> thread pool, another is in _start_request).
> because flup using thread.start_new_thread, and webpy using
> threading.current_thread. so here are many
> DummyThread object in threading module. it don't free memory.
> from threading module source:
> # Dummy thread class to represent threads not started here.
> # These aren't garbage collected when they die, nor can they
> be waited for.
> # If they invoke anything in threading.py that calls
> current_thread(), they
> # leave an entry in the _active dict forever after.
> # Their purpose is to return *something* from current_thread().
> # They are marked as daemon threads so we won't wait for them
> # when we exit (conform previous semantics).
>
> 4. maybe maxSpare.
>
> another:
> 1. careful flup bug, fix in trunk but not released.
> 2. if using mysql-python, it leaks memory.https://sourceforge.net/tracker/?func=detail&aid=1464563&group_id=223...