RE: nginx лучше сквида?

[GribUser]

> А с каким буфером был собран squid ? И какие размеры книг - от и до ?
128MB я ставил, на убой, это же потолок. Книги обычно меньше метра.
Около половины хитов идет на страницы, а не на собственно книги, там
вообще < 100k обычно. Даунлоадеры народ юзает, но погоду они не делают,
размеры не те.

> > Но моего вопрос это не снимает, видимо.
> В чём заключается вопрос ? Почему nginx есть процессор, а 
> squid - нет ?
Да. Почему squid был в низу топа, за мускулом и апачами, где ему и
место, а nginx всех обогнать норовит.

> Я могу ответить достаточно точно только про nginx. Приходит 
> клиент c даунлоад-мастером за файлом, допустим, 5M. nginx 
> скачивает 5М от бэкенда за доли секунды. Даунлоад-мастер 
> принимает первые 32K и закрывает соединение. Затем открывает, 
> скажем, 5 потоков, качающих этот файл с разных мест. nginx 
> все эти запросы передаёт бэкенду и снова быстро их принимает. 
> То есть, nginx принимает от бэкенда что-то около 20М. Больший 
> процент системного времени вызван тем, что всё это копируется 
> сначала Апачом в ядро, а потом nginx'ом из ядра.
При таком раскладе апач никак не должен отставать от nginx по загрузке.
А он отстает безнадежно. Если только я правильно понимаю принцип
измерения загрузки процессора, конечно. Потому что system там или не
system, но загрузка приписывается тому процессу, который к системе
обратился. По-моему так.

> 3) политику раздачи некэшируемого контента одному и тому же адресу.
>     В моих опытах со старым squid'ом 2.4.STABLE7, если в ответе стоял
>     "Cache-Control: private", то squid ходил на Апач каждый 
> раз заново.
Значит ходил. Он не сильно интелектуален в этом плане.

> 4) время обслуживания запроса в логах Апача. Я, например, не уверен,
>     что оно было меньше секунды для больших файлов.
И что это меняет, не понял?
На файлах бэкенд не тормозил особо, размеры не те, секунду на отклик там
уходило только при полном дауне, но этот случай мы не берем.

> В общем, раздавать большую private статику через 
> акслерированное проксирование с помощью nginx'а не имеет 
> смысла. Это надо делать с помощью X-Accel-Redirect'а.
Ну это я уже понял, X-Accel-Redirect рулит. Хочу только разобраться в
происходящем сперва... Народ-то все больше с апача на nginx мигрировал,
а это, конечно, небо и земля, но хочется поковырять поглубже. Фронтэнд,
соперничающий с бэкендом за процессор - это не есть гут. У меня узкое
место будет в процессоре, так что найти, куда убежали 10% CPU time
означает ускорить сервер на 10%. Игра стоит свеч.