Re: using paste.debug.profile

2007-09-18 Thread Pekka Jääskeläinen
On 9/18/07, Mike Orr [EMAIL PROTECTED] wrote: At the bottom of middleware.py. static_app = StaticURLParser( config['pylons.paths]['static_files'], cache_max_age=3600) Works. Thanks for this. -- --PJ --~--~-~--~~~---~--~~ You received this message

Re: using paste.debug.profile

2007-09-16 Thread Pekka Jääskeläinen
On 9/4/07, Ian Bicking [EMAIL PROTECTED] wrote: Pekka Jääskeläinen wrote: On 8/27/07, *Ben Bangert* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That shouldn't actually be a problem as they use ETag's instead. The Yahoo tool is not perfect, and does have a few

Re: using paste.debug.profile

2007-08-27 Thread Pekka Jääskeläinen
On 8/27/07, Ian Bicking [EMAIL PROTECTED] wrote: Pekka Jääskeläinen wrote: I don't know what I did differently, but this time the server didn't exit, but I got this: Ah... it looks it's because Pylons introspects the signature to figure out what parameters to pass, and the signature

Re: using paste.debug.profile

2007-08-27 Thread Pekka Jääskeläinen
On 8/27/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest taking a look at Yahoo's ySlow Firefox extension which can rank several important factors that affect how long the browser takes to fully load a page. Javascript should be loaded at the bottom of your page whenever possible

Re: using paste.debug.profile

2007-08-27 Thread Pekka Jääskeläinen
On 8/27/07, Pekka Jääskeläinen [EMAIL PROTECTED] wrote: On 8/27/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest taking a look at Yahoo's ySlow Firefox extension which can rank several important factors that affect how long the browser takes to fully load a page. Javascript

Re: using paste.debug.profile

2007-08-27 Thread Pekka Jääskeläinen
On 8/27/07, Ben Bangert [EMAIL PROTECTED] wrote: That shouldn't actually be a problem as they use ETag's instead. The Yahoo tool is not perfect, and does have a few inconsistencies on some things. It seems to be not functioning optimally: I tested reloading my front page and looking at the

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-26 Thread Pekka Jääskeläinen
On 8/26/07, Bob Ippolito [EMAIL PROTECTED] wrote: Well if you have a cache that fills up with active sessions then you The cache is used to store also other objects, thus it eventually will fill up. Sure, if I have a separate memcached instance only for session data, this should not be a

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-26 Thread Pekka Jääskeläinen
On 8/26/07, Bob Ippolito [EMAIL PROTECTED] wrote: It will eventually fill up, but data in memcached is a combination of (opt-in) expiration and LRU. Sessions shouldn't be least recently used, and they only get expired if you gave them an expiration time (which probably makes sense to do).

using paste.debug.profile

2007-08-26 Thread Pekka Jääskeläinen
Hello, How am I supposed to use the paste.debug.profile to get profiling data for the web pages? It seems to have a middleware, but what should I add to the configuration file exactly to get it running? I also tried to use the decorator for a single controller action like this:

Re: using paste.debug.profile

2007-08-26 Thread Pekka Jääskeläinen
I don't know what I did differently, but this time the server didn't exit, but I got this: Error Traceback clear this clear this Module paste.debug.profile:*138* in replacement http://localhost:5000/front# http://localhost:5000/front#*def* *decorator**(**func**)**:* *def*

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-25 Thread Pekka Jääskeläinen
On 8/25/07, Ben Bangert [EMAIL PROTECTED] wrote: I'd highly suggest memcached rather than database backend. It's easy to setup, and of course, very fast. :) Yes, but as far as I know, memcached objects can be always replaced, that is, you cannot define an object to be persistent, can you?

implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-24 Thread Pekka Jääskeläinen
Hello, In our new project we want to implement the web application from the beginning to be easily scalable to 1) multiple cores (on the same server) and to 2) multiple separate servers. Due to the infamous GIL ruining multithreading scalability of Python, the only sensible way to implement both

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-24 Thread Pekka Jääskeläinen
Apache 2.2 has a mod_proxy_balancer. If performance is a concern, you should go with the CherryPy WSGI server. use = egg:PasteScript#cherrypy instead of use egg:Paste#httpserver This didn't work, I changed the line use = egg:Paste#http to use egg:Paste#cherrypy Even though I just

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-24 Thread Pekka Jääskeläinen
On 8/25/07, Cliff Wells [EMAIL PROTECTED] wrote: My only possible explanation is that either a) Nginx makes some attempt to track sessions itself and always passes the same IP back to the same backend Pylons process or b) Pylons automagically makes it work. ...or c) you don't use much the

Re: implementing a scalable (to multiple processors and multiple servers) Pylons webapp

2007-08-24 Thread Pekka Jääskeläinen
On 8/25/07, Cliff Wells [EMAIL PROTECTED] wrote: This is wrong AFAIK. I'm using CP's wsgiserver (which is a standalone app and included with Paste, so you don't actually need to install CP3, although you certainly can), and this is my entry: [server:main] # use = egg:Paste#http use =