Caching fastcgi url

CJ Ess zxcvbn4038 at gmail.com
Wed Jun 24 17:46:25 UTC 2015


Everything is fastcgi, my question is how best to treat one single fastcgi
URL differently (caching it instead of forwarding every request to the
backend).


On Wed, Jun 24, 2015 at 12:37 PM, ryd994 <ryd994 at 163.com> wrote:

>
>
> On Tue, Jun 23, 2015 at 6:27 PM CJ Ess <zxcvbn4038 at gmail.com> wrote:
>
>> So looks like your saying the best way to do it is to do a separate
>> location and duplicate the fastcgi setup in that location and add the
>> fastcgi_cache stuff.
>>
>> I can work with that, however I came across this example while googling (
>> https://gist.github.com/magnetikonline/10450786) that uses "if" to set a
>> variable which I could use to match on the URL and trigger
>> fastcgi_cache_bypass for everything not matching. Is "if" so toxic that I
>> shouldn't consider doing it this way?
>>
>>
>> On Tue, Jun 23, 2015 at 6:07 PM, Francis Daly <francis at daoine.org> wrote:
>>
>>> On Tue, Jun 23, 2015 at 04:19:48PM -0400, CJ Ess wrote:
>>>
>>> Hi there,
>>>
>>> > - Would I need to define a separate location stanza for the URL I want
>>> to
>>> > cache and duplicate all of the fastcgi configuration that is normally
>>> > required? Or is there a way to indicate that of all the fastcgi
>>> requests
>>> > only the one matching /xyz is to be cached?
>>>
>>> fastcgi caching is handled by the fastcgi_cache directive, documented
>>> at http://nginx.org/r/fastcgi_cache
>>>
>>> It is set per-location.
>>>
>>> See also directives like fastcgi_cache_bypass and fastcgi_no_cache.
>>>
>>> It is probably simplest to have on exact-match location for this url
>>> and not worry about the no_cache side of things.
>>>
>>> "all the configuration that is normally required" is typically four lines
>>> -- one "include" of common stuff; one or two extra fastcgi_param values,
>>> and a fastcgi_pass.
>>>
>>> > - If multiple request for the same URL arrive at around the same time,
>>> and
>>> > the cache is stale, they will all wait on the one request that is
>>> > refreshing the cache, correct? So I should only see one request for the
>>> > cached location per worker per minute on the backend?
>>>
>>> If that's what you want, you can probably configure it.
>>>
>>> http://nginx.org/r/fastcgi_cache_use_stale
>>> http://nginx.org/r/fastcgi_cache_lock
>>>
>>> > - Since my one URI is fairly small, can I indicate that no file
>>> backing is
>>> > needed?
>>>
>>> I don't think so. But you can have fastcgi_cache_path set to a ramdisk,
>>> I think.
>>>
>>>         f
>>> --
>>> Francis Daly        francis at daoine.org
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> For short, if is evil. If you are not sure, don't use.
>
> If you don't have other fastcgi locations, you can do fastcgi setup in
> server
> block. It's fine to set fastcgi parameters, they won't affect static
> requests until you do fastcgi_pass.
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150624/ce20d34a/attachment.html>


More information about the nginx mailing list