Douglas Bell wrote:
About when did this slowdown start? I'd like to know if it correlates to when
we started enabling Fastly caching.
----
The first type of this error I saw in my browsing history was
sometime on or after april 1st.
I can't see exact D&T's in my history, but one entry that was
just below one of the 503's was in the linux kernel bug report
database where I'd just updated/commented on the issue was dated 3/31.
Don't see anymore of the 503's below that update, and see at least
6 uniq, semi-persistent, occurrences below that. When I say
semi-persistent, I mean if I try it with a different browser where I'm
not logged-in, the page _may_ come up w/no error.
Just now, tried exit'ing w/tabs saved (2 of which pointed to cpantesters
pages, but only 1 of those pages had shown the 503). When it reloaded the
pages both got 503's. I clicked on the reload page button on one of them
and after about 15 seconds it came back with "proper" content.
Looks like the page-retrieval rate is about 15s (looking at a squid
log) -- where the 503's show through as:
+13.82 15029ms; ln=813 (59/54) MISS/503 <Athenae [GET
http://www.cpantesters.org/distro/X/Xporter.html - 23.235.47.204 text/html]
but a *successful* retrieval (~89 seconds later...), on a manual refresh
just showed up as a 'MISS':
+88.53 12515ms; ln=7254 (82/580) MISS/200 <Athenae [GET
http://www.cpantesters.org/distro/X/Xporter.html - 199.27.79.204 text/html]
I notice if I don't get an error on the initial request, I rarely,
if ever, seem to get an error in any of the subsequent fetches for that
page. Looking along in the log, that's likely because
they are in squid'smemory cache. Their look to be about
15-20 calls from the basepage that were served from squid's
mem-cache (looking like:)...
+0.16 0ms; ln=3062 (19K/-0) MEM_HIT/200 <Athenae [GET
http://www.cpantesters.org/css/layout2_setup.css - - text/css]
That points to a good reason not to shove everything in a encrypted
https session -- which google is really pushing for -- then on
busy server everything has to come back fresh from the server...
(which in my case is resulting in the '503' error some noticeable
percentage of the time...
Maybe we should've just gone with Memoize for back-end..
Using a locally-hosted cache would solve very little of the problem as it
exists.
Sorry meant _that_ more in silliness/irony especially since it has no way
(that I know of) of timing-out it's in-memory, cached data, thus it'd be
a bit like memoizing the returned value for time-of-day -- and getting the
same value back no matter how long you wait...(just as long as process
stays active, as you mention)....
