>> Либо я не понял что вы хотите, либо непонятно, где вы тут видите противоречие.
>>
>> Есть какой-то server, в нём есть location с proxy_pass и proxy_cache.
>>
>> curl дёргает урл, nginx лезет на бекенд, забирает ответ, ответ попал в кеш.
>> Теперь второй бекенд (точно так же как curl) дёргает этот же урл,
>> nginx отдаёт ответ из кеша.
>>
>
> Текущая схема:
>
> Запрос
>  |
>  v
> nginx
>  |
>  v
> backend -----------------> service
>
>
> Запрос приходит на nginx, mod_perl овый backend идет за контентом к service.
> Если service тормозит, то на backend'е выстраиваются толпы апачей и всем плохо.

Во-первых вы могли бы поставить кеширующий прокси (например squid или
что-нибудь ещё) между backend и service, потому что, очевидно, это
совершенно отдельное звено от nginx/backend.

Во-вторых, backend может отдавать X-Accel-Redirect чтобы nginx сходил
на service (и опционально закешировал ответ). Для этого нужно будет
написать отдельный внутренний локейшн типа /_proxy/(.+) или
/_proxy?url=... Ну то есть при помощи пары лишних локейшнов
эмулируется непрозрачный proxy. Очевидно, что вариант с отдельным
прокси софтом будет лучше, потому что а) ну просто по-человечески
схема будет проще и понятнее. б) кеширующие прокси должны уметь (squid
точно умеет, про другие не знаю) такую полезную вещь, как "отложить
все запросы от клиентов до получения ответа бекенда, а потом ответить
всем сразу".


Но самое главное, конечно, что service это отдельное звено и работать
с ним нужно соответственно. А вы пытаетесь впихнуть всё в одну схему,
отсюда и кактус и отчаяние.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru