On Fri, Feb 15, 2013 at 3:33 PM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
> On 02/15/2013 12:28 AM, Tom Lane wrote:
>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>> On 02/14/2013 05:31 AM, Tom Lane wrote:
>>>> [ raised eyebrow... ] I'm fairly sure I've seen it more than once when
>>>> performing a *single* page fetch. In any case, the probability of
>>>> failure increased by a couple orders of magnitude sometime in the past
>>>> month or so, because I'd never seen it before that.
>>
>>> any chance you moved to a different browser (or a new version of it) in
>>> that timeframe?
>>> I can trivially reproduce that issue here now because my browser is
>>> employing fairly agressive prefetching techniques that the currently
>>> rate-limiting system is not prepared to deal with, and from looking at
>>> the logs this is actually a fairly common issue :(
>>
>> Hm. I usually use Apple's Safari, which is currently at 6.0.2, and
>> it looks like I installed that update at the beginning of November.
>> It's possible they instituted aggressive prefetching in the 6.0.1 to
>> 6.0.2 update, but somehow I doubt that.
>
> hm ok...
>
>>
>> Would it make sense to just back off the rate limiting a bit?
>
> done that for now until we have a better solution - lets see if it
> behaves better now.
I've deployed what I think is a better fix for this now - it's now
limited to two parallel *active* connections from wherever, but any
further requests are placed in a queue rather than being rejected iwth
403.
As a bonus, we now also have caching. That makes particularly the
frontpage quite a lot faster for most people - not likely to have a
big effect on details pages, since there are just too many of them to
get efficient caching.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
