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=22307&atid=374932
在 2010年2月1日 下午4:30，skp_999 <[email protected]> 写道：
> I'm on a dedicated server, no root access but I can install any app
> (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
>
> On 1 Feb, 03:38, Graham Dumpleton <[email protected]> wrote:
>> On Feb 1, 1:24 pm, David Shieh <[email protected]> wrote:
>>
>>
>>
>> > On 2月1日, 上午9时47分, Graham Dumpleton <[email protected]> wrote:> On
>> > Feb 1, 12:39 pm, David Shieh <[email protected]> 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
>>
>> > Thanks for mentioning, man.
>>
>> > > Graham
>>
>> > > > 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 <[email protected]> wrote:
>>
>> > > > > I run my webpy apps with the following configuration (based on infos
>> > > > > found athttp://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
>
> --
> You received this message because you are subscribed to the Google Groups
> "web.py" 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/webpy?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"web.py" 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/webpy?hl=en.
