[Catalyst] C::P::PageCache patch for reducing duplicate processing

[Marcello Romani]

Wade.Stuart at fallon.com ha scritto:
> 
> 
> 
> 
>> Wade.Stuart at fallon.com ha scritto:
>>>
>>>
>>>
>>>> Perrin Harkins wrote:
>>>>> Toby Corkindale wrote:
>>>>>> One of the aims of my patch is to avoid the expense of having
> numerous
>>>>>> processes produce the same code simultaneously. So on the initial
>>> bunch
>>>>>> of requests, I'll still try and have the code delay all-but-one of
>>> them
>>>>>> from building the page.
>>>>> Presumably this only happens when a new cached page suddenly becomes
>>>>> available and is instantly in high demand.  It's not very frequent.
> In
>>>>> my opinion, that isn't worth the danger of messing with something as
>>>>> potentially troublesome as locks that block page generation, but I
>>>>> suppose no one is forced to use the locking.
>>>> Good point.
>>>> I'll try and implement the features so they can be enabled separately.
>>> I will second the "I don't think it is worth it" case.  99% of the time
>>> caching is set at startup and the only time the case you are coding for
> is
>>> hit is on the first page load if the second request comes in for the
> same
>>> page before the page build is done from the first hit.  Seems like such
> an
>>> outside case that I would be against all that extra locking an special
> case
>>> code even if it is an option.
>> Could this condition be triggered by the user hitting "Reload" or "Go"
>> many times while waiting for the page ?
> 
> Yes,  my case statement was general on purpose.  If a user or multiple
> users make multiple requests for the page, and the requests are the first
> ones that happen after the server is started,  multiple builds would happen

not only when the server is (re)started, but also when the cached page 
expires

> until the first build is done and stored in cache.  After the cache is
> populated there is no window of opportunity for the case to exist (given my
> no blocking method is implemented).  That seems to me like very minimal
> exposure and acceptable "startup cost" for a site.

I agree.

> 
> Throwing in locking and all that baggage to avoid the outside case (or all
> the logic to allow the option of the locking) just seems to go against
> KISS.
> 
> 

I agree on this point too.

I also think that the problem at hand could show up only on the most 
requested pages of a heavy-traffic site.
Also, it would have a significant impact only on undersized hardware 
IMHO, because it would cause a spike in memory and cpu utilization, that 
would cease as soon as the first copy of the page is produced, as you said.

In other words, I think some benchmarks would be required to know how 
much a problem this... problem really is.

My $.02 euro :)

> 
> 
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 
> 


-- 
Marcello Romani
Responsabile IT
Ottotecnica s.r.l.
http://www.ottotecnica.com