Alright, thanks. I was finally shown the right settings to increase the timeout to 60 seconds, so this problem should hopefully disappear (or at least be quite reduced).
> On May 5, 2016, at 12:35 PM, Linda A. Walsh <l...@tlinx.org> wrote: > > 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).... > >> >>
