The webpy hello world application is like this:
import web
urls = (
'/(.*)', 'hello'
)
app = web.application(urls, globals())
class hello:
def GET(self, *args):
return 'Hello, World!'
if __name__ == "__main__":
app.run()
And it served <300 requests per second under lighttpd.
With setting "max-procs" => 2 on the 2 cores box, the performance
could be improved to about 500 requests per second though. The other
thing is that I prefer to running the script as a single process but
increasing the threads limit of webpy. Do you know how to do that?
On May 25, 12:51 pm, Graham Dumpleton <[email protected]>
wrote:
> On May 25, 2:46 pm, 柯甫敬 <[email protected]> wrote:
>
> > Again, I tested
>
> > def application(environ, start_response):
> > status = '200 OK'
> > output = 'Hello World!'
> > response_headers = [('Content-type', 'text/plain'),
> > ('Content-Length', str(len(output)))]
> > start_response(status, response_headers)
> > return [output]
>
> > But not webpy. And got 1,500 requests per second under Apache/mod_wsgi. Does
> > it make sense to you?
>
> If your web.py hello world test is similar to WSGI hello world test
> then would confirm that overhead of web.py for simple stuff is quite
> is small.
>
> One of the things web.py is known for is being light weight, although
> am surprised it would be so close though to raw hello world. :-)
>
> Graham
>
>
>
> > 2009/5/25 Graham Dumpleton <[email protected]>
>
> > > On May 25, 2:17 pm, Tim <[email protected]> wrote:
> > > > As I talked in the last posts, the hello world application was run
> > > > under apache/mod_wsgi. "I just tested with mod_wsgi under apache and
> > > > the requests/second is about 1,500 with a hello world application. "
>
> > > > Please refer to the 3rd post for the details.
>
> > > I originally suggested a plain WSGI hello world, not a web.py hello
> > > world. There is a difference, as plain WSGI hello world doesn't depend
> > > on web.py. If what you did was a web.py hello world test then fine.
> > > One reason for suggesting a plain WSGI hello world test was that it
> > > would also show you what overhead there was in web.py dispatching.
> > > Depending on the complexity of your application, if the difference
> > > between web.py and plain WSGI hello world was marked, it might show
> > > you that perhaps using WSGI directly may yield better performance. For
> > > something as simple as serving advertisements where URL routing
> > > probably not needed, may not even be a need for web.py.
>
> > > So, if you haven't done a WSGI hello world, would be curious to see
> > > results of that relative to web.py. WSGI hello world program below.
>
> > > def application(environ, start_response):
> > > status = '200 OK'
> > > output = 'Hello World!'
>
> > > response_headers = [('Content-type', 'text/plain'),
> > > ('Content-Length', str(len(output)))]
> > > start_response(status, response_headers)
>
> > > return [output]
>
> > > Graham
>
> > > > On May 25, 12:02 pm, Graham Dumpleton <[email protected]>
> > > > wrote:
>
> > > > > On May 25, 1:41 pm, 柯甫敬 <[email protected]> wrote:
>
> > > > > > For the performance bottlenecks on my application side, I think I
> > > could have
> > > > > > a couple of ways to optimize. You could regard it as a simple hello
> > > world
> > > > > > application for now. My real question actually was "is it possible
> > > for
> > > > > > lighttpd/fastcgi/webpy to support up to 1,000 requests/second for a
> > > simple
> > > > > > hello world application"? I think increasing the threads limit in
> > > webpy
> > > > > > could help, but I didn't find where to set or change in webpy. Can
> > > anyone
> > > > > > help on this?
>
> > > > > What does a hello world program using web.py on Apache/mod_wsgi yield?
> > > > > If you can't even get 1000 requests per second on Apache/mod_wsgi,
> > > > > which is already proving to yield better performance than your fcgi
> > > > > setup, then unlikely that even if fcgi is tuned that you will achieve
> > > > > anything better.
>
> > > > > Even though lighttpd or nginx may be faster than Apache for yielding
> > > > > static files, flup when used with fcgi adds a fair bit more overhead.
> > > > > End result is that more often that not, a fcgi/flup application will
> > > > > run slower than Apache/mod_wsgi. That is why Apache/mod_wsgi is a good
> > > > > reference here as is close to maximum you can expect to get without
> > > > > starting to load balance across multiple boxes etc.
>
> > > > > Graham
>
> > > > > > Thanks in advance.
> > > > > > 2009/5/25 Tim <[email protected]>
>
> > > > > > > Thanks Graham.
> > > > > > > My application is actual an ad serving application. I just tested
> > > with
> > > > > > > mod_wsgi under apache and the requests/second is about 1,500 with
> > > > > > > a
> > > hello
> > > > > > > world application.
> > > > > > > It looks like a problem with fcgi then. How do you think?
> > > > > > > 2009/5/25 Graham Dumpleton <[email protected]>
>
> > > > > > >> On May 25, 12:08 pm, Tim <[email protected]> wrote:
> > > > > > >> > I'm recently porting an apache module to be webpy/fcgi/lighttpd
> > > based
> > > > > > >> > application, but the performance doesn't look like good.
>
> > > > > > >> > With the apache module writen in C, it was able to process up
> > > > > > >> > to
> > > 2,000
> > > > > > >> > requests per second, however, when I ran a simple helloworld
> > > > > > >> > application with webpy/fcgi/lighttpd, the server was processing
> > > about
> > > > > > >> > 300 requests per second.
>
> > > > > > >> > I was followinghttp://webpy.org/installfortheinstallationand
> > > > > > >> > default lighttpd configurations. I'm new to lighttpd and webpy,
> > > so I'm
> > > > > > >> > wondering if there are any configuration options in
> > > lighttpd/webpy to
> > > > > > >> > tune the performance to make the requests/second to be more
> > > > > > >> > than
> > > > > > >> > 1,000? Also, is there any way to increase the threads limit in
> > > webpy
> > > > > > >> > since when I tested with more than 120 concurrent users I would
> > > get
> > > > > > >> > "backend is overloaded" errors?
>
> > > > > > >> What does your application do? Without knowing that, it is very
> > > hard
> > > > > > >> to comment on whether your problems may actually be in your
> > > > > > >> application, the fastcgi bridge, or your web server.
>
> > > > > > >> You should perhaps create a simple WSGI hello world program that
> > > > > > >> doesn't even use web.py and determine how many requests that can
> > > > > > >> handle. You might also as comparison to gauge whether the web
> > > server
> > > > > > >> and/or fastcgi is the issue, compare that to WSGI hello world
> > > program
> > > > > > >> under Apache/mod_wsgi on same system.
>
> > > > > > >> Graham- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
