[EMAIL PROTECTED] ha scritto: > > > > >> [EMAIL PROTECTED] 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: [email protected] > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > > -- Marcello Romani Responsabile IT Ottotecnica s.r.l. http://www.ottotecnica.com _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
