Pekka Jääskeläinen wrote:
> On 9/4/07, *Ian Bicking* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> Pekka Jääskeläinen wrote:
> > On 8/27/07, *Ben Bangert* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <mailto:[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 inconsistencies on
> > some things.
> >
> >
> > It seems to be not functioning optimally: I tested reloading my front
> > page and
> > looking at the traffic with Live HTTP Headers. It always wanted to
> > reload the images and javascripts. Also the Proxy I use seemed to
> > produce misses for all the files every time.
>
> ETags won't help this; they only give a way to do conditional requests
> so you don't actually have to download the response.
>
>
>
> A problem with ETags is that the request always goes to the server, even
> if using
> a proxy for caching (or just a browser cache). At least this article leads
> me to understand so:
>
> http://www.infoq.com/articles/etags
>
> I.e., the client always has to ask the server whether the given URL
> has changed or not. This requires a HTTP connection and parallel HTTP
> connections are limited by most browsers and servers. This might explain the
> occasional slowness I'm experiencing with my front page at
> http://movietron.fi/front
I didn't see that particular note in the article, but ETags shouldn't
keep caching from happening. The cache should save the ETag, and if it
things the cached item is still fresh enough the cache itself can
respond with 304 Not Modified. That's not to say all caches work that
way -- there's a lot of bugs in caches (Squid definitely included).
> The weird thing is that the slowness varies *a lot*. Sometimes the page
> loads in 1-2secs,
> sometimes it takes a minute. I profiled it and the front page itself
> loads in about 0.5
> secs when fetching it with wget, so it's not the page generation itself
> that's slow.
>
> There is an option cache_max_age to StaticURLParser, which sets
> Cache-Control: max-age=X. This should cause caching to improve.
>
>
> How/where can I set this?
I'm not sure exactly where in Pylons this is instantiated. It would
probably be nice if Pylons could accept this configuration and pass it on.
> > That will definitely make an impact on speed to an extent. I'd
> > suggest having your front-end app handle gzipping. I use
> Apache in
> > front of Paster, which gzip's the images when I add the
> following
> > (Apache 2):
> >
> >
> > I don't use a front-end app at the moment. The paste.gzipper is
> > not supported by the Pylons at the moment?
>
> Content-Encoding is really weird. I find myself disillusioned with it.
> But oh well; anyway, it should work if you put it in front of your
> app, or just in front of the static files.
>
>
> I don't need Apache for anything else at the moment, I'm serving the
> webpage directly from Paste for simplicity. Maybe gzip support could be
> built to
> 'render' function that just gzips the rendered result and sets
> the headers. Or just a wrapper to that function... could be doable.. hmm.
>
> > The most substantial speed boost I got on the PylonsHQ site,
> was from
> > reducing the CSS from 3 stylesheets to 1 because each CSS
> load goes
> > one at a time, blocking parallel downloads and anything else
> until
> > the CSS is done. Moving the JS to the bottom also resulted in
> > noticeable improvement since it loaded just once at the end
> instead
> > of blocking parallel page component loading.
> >
> >
> > My problem are the large JS libs I use, from which I need only
> some simple
> > function for each page. Too bad they are not modularized so I
> could just
> > pick
> > the functions I really need easily. They could really benefit
> from gzipping.
>
> Combining files often helps more, but gzipping might help some too.
>
>
> The bandwidth seems not to be the bottleneck in my case as
> it's slow even when accessing it at localhost. I suspect it's due to the
> count of
> connections required.
>
> BTW, I've got this kind of errors lately, I wonder if this is related to the
> occasional slugginess I'm seeing.
>
> WARNING:paste.httpserver.ThreadPool:Thread -1297912912 hung (working on
> task for 1901 seconds)
> ----------------------------------------
> Exception happened during processing of request from ('85.157.81.240
> <http://85.157.81.240>', 20273)
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/Paste-
> 1.4.1-py2.5.egg/paste/httpserver.py", line 1046, in
> process_request_in_thread
> self.finish_request(request, client_address)
> File "SocketServer.py", line 254, in finish_request
> self.RequestHandlerClass (request, client_address, self)
> File "SocketServer.py", line 522, in __init__
> self.finish()
> File "SocketServer.py", line 567, in finish
> self.rfile.close()
> File "socket.py ", line 233, in close
> self.flush()
> SystemExit
> ----------------------------------------
Yes, this is paste.httpserver killing a thread that appeared to be hung
-- it raises SystemExit once a thread has been processing a request for
an excessive amount of time.
Though it's odd that it's doing so in what seems to be the socket
handling code. Like the socket isn't flushing and closing properly. It
looks like this is happening after the WSGI app has completed.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
: Write code, do good : http://topp.openplans.org/careers
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
