А буфер самого squid'а, очевидно, около 100K. Вот такая акселерация.
Угу, там нужно в конфиге подкрутить размер кэша и squid пересобрать,
по-умолчанию он 128k только выбирает с бэкенда или типа того, не помню
уже. Это где-то то ли в описании хитростей настройки mod_perl толи
где-то еще есть совет как это обойти и у меня это было пофикшено, когда
он процессор не ел. Такие дела. А по-умолчанию он акселерирует большие
объекты весьма своеобразно, ага, я когда это обнаружил в первый раз аж в
панику вдарился. И еще НИКОГДА на диск не свапит, так что если отдаются
150-и метровые файлы можно попасть очень здорово. Но для небольших это
работает отлично.
А с каким буфером был собран squid ? И какие размеры книг - от и до ?
Но моего вопрос это не снимает, видимо.
В чём заключается вопрос ? Почему nginx есть процессор, а squid - нет ?
Я могу ответить достаточно точно только про nginx. Приходит клиент c
даунлоад-мастером за файлом, допустим, 5M. nginx скачивает 5М от бэкенда
за доли секунды. Даунлоад-мастер принимает первые 32K и закрывает соединение.
Затем открывает, скажем, 5 потоков, качающих этот файл с разных мест.
nginx все эти запросы передаёт бэкенду и снова быстро их принимает.
То есть, nginx принимает от бэкенда что-то около 20М. Больший процент
системного времени вызван тем, что всё это копируется сначала Апачом
в ядро, а потом nginx'ом из ядра.
Что касается squid'а, то нужно знать
1) размер его буфера;
2) размер файлов;
3) политику раздачи некэшируемого контента одному и тому же адресу.
В моих опытах со старым squid'ом 2.4.STABLE7, если в ответе стоял
"Cache-Control: private", то squid ходил на Апач каждый раз заново.
4) время обслуживания запроса в логах Апача. Я, например, не уверен,
что оно было меньше секунды для больших файлов.
В общем, раздавать большую private статику через акслерированное
проксирование с помощью nginx'а не имеет смысла. Это надо делать
с помощью X-Accel-Redirect'а.
Игорь Сысоев
