Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[6]: Проблема: upstream buffer is too small
- To: nginx-ru@xxxxxxxxx
- Subject: Re: Re[6]: Проблема: upstream buffer is too small
- From: Sergey Shepelev <temotor@xxxxxxxxx>
- Date: Mon, 27 Sep 2010 17:30:46 +0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xBi+iB2sgd39LsCTFYhEVkMRKbyRhVxE/DNS8XCWcRI=; b=kz59CtcZteTU9Dw6XUCpYHOTJl/W1b+k2bBZ1B0AeELeof6pdz4WZqLgJMre0g35g7 gPtY5Fdr2vUbPcf7zTNzDhb69ASRzGtC4r2FEZvYdlXJ68EwbS2D3lvpru/n8La15Oyc /F+GvVpHs6KJPwCN2dyOrIVlnSSLiE1UfAiUQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=pUpFa90dojIBUKxZUH30EBVcmenDpp1ckUO7F2Ck42VlNTLlos3gJpiZqr+0rBTsF/ +Ic7MOfF0y4mvlCkZhWavVmp9vfQQehXE8JHt5gdCj3mIM6ZqcUFKigtZ19ysAVwhJc+ KeJUZSmtTJGu5gwilrPXhmXInc4ugzfJzTe98=
- In-reply-to: <E1P0DFx-0002vl-00.ilvin-mail-ru@xxxxxxxxxxxx>
- References: <AANLkTinQONCPEisnX092Fhpx9-KdK7ADnwBV0xGrhqz@xxxxxxxxxxxxxx> <E1P0DFx-0002vl-00.ilvin-mail-ru@xxxxxxxxxxxx>
>> Либо я не понял что вы хотите, либо непонятно, где вы тут видите
>> противоречие.
>>
>> Есть какой-то 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@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|