On Sun, Jan 11, 2009 at 1:19 PM, Tycon <[email protected]> wrote:
> I guess that means routes can be taken out if I remove the routes
> middleware and use my own url_for (which I was just about ready to
> do).
What Pylons needs is 'wsgiorg.routing_args', 'routes.route', and
'routes.url' in the WSGI environment. In other words, something has
to emulate the RoutesMiddleware, but it does not have to use Routes.
'wsgiorg.routing_args' is used by the Pylons dispatcher. This was
intentionally defined as a neutral standard so that Routes could be
replaced with something else.
The 'routes.url' object is put onto pylons.url. You'll probably have
to provide a dummy object if you don't have a real one, and I imagine
'None' would be OK. url() is called only when the user calls it
(although the user may call it indirectly via redirect_to()).
I'm not sure if Pylons does anything with 'routes.route', but it may
stick it in the config at least, in which case a dummy value would be
needed.
> So in your assessment a simple hello world on pylons using cherrypy
> instead of paster (that is my current config) is going to be as fast
> as just as an equivalent cherrypy (or pretty close, but not twice as
> slow) ?
You're still using paster. You're just replacing PasteHTTPServer with
CherryPy's server component. The CherryPy *server* handles high
traffic better than PasteHTTPServer, according to several user
reports. The difference between a Pylons-CherryPy application vs a
pure CherryPy application is a different question. I would guess the
pure CherryPy application would be slightly more efficient.
But a sizeable application is going to have significant different
stats compared to "Hello World". The overhead of the framework will
be much less than the overhead of the application, so even if one
framework is 10% more efficient, the net difference in application
speed may be only 1%.
> P.S. - mod_wsgi is a hack, it's an unstable and unscalable
> architecture to embed the app server in the web server. And using
> daemon mode makes even less sense as using apache+mod_wsgi as a
> process monitor for the app server (it's better to use a dedicated and
> specialiazed monitoring) as well as a proprietary communication
> protocol when we already have http and fcgi, is silly.
I use Supervisor to manage PasteHTTPServer daemons, and I like having
a HTTP separate daemon for each application so that I can:
- Start and stop them separately ("supervisor restart myapp")
- See their individual memory usage using 'top'.
- Send localhost HTTP requests to them for troubleshooting.
Efficiency is not on my radar because I have plenty of server
capacity. And the efficiency I *do* worry about is large data
structures in memory, which has nothing to do with the deployment
method (except for the impact of multithreaded vs multiprocess). And
if I *did* have to worry about Python overhead so strictly, I'd also
evaluate even more radical choices like not using Python, using a
cloud service, etc.
Fcgi has a long reputation of being buggy. Perhaps it's better now,
but that's why people like me don't use it. SCGI is a *language
neutral* replacement that was written specifically to be simpler and
more reliable. mod_proxy is of course standard. WSGI may be Python
specific, but it does a reasonably good job of making Python
frameworks interchangeable.
--
Mike Orr <[email protected]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
