AS> смысл в том что все права проверяет апача, если все ок он отдает
специальный ответ nginx который стоит на том же сервере где и апаче
AS> в этом ответе он хитрым способом говорит ему какой файл локально отдавать.
nginx начинает его передавать на frontend. тот в свою
AS> очередь медленно и печально без использования tmp файлов его транслирует
клиенту.
AS> апача занимается только тем что проверяет что кому откуда качать, сам он
файлы непосредственно не отдает.
Да, мне нравится этот подход.
Я обязательно попробую, но мне не ясно как это в целом помогает
не просто разгрузить фронтэнд но и не потерять в трафе.
Безусловно надо чтобы траф мог расти, это основная идея,
неужели если на бекендах поставить nginx, а на фронтэнде запретить
временные файлы система в целом будет работать быстрее?
Я сейчас рисую с snmp апачи на бекендах там не больше 100-120 процессов,
у меня на других серверах по 800-900 на 50 мегабитах и довольно шустро.
Понять не могу какую проблемму мы решаем ускоряя ответы бекендов через
nginx?
Что, если выключить временные файлы и разогнать бекенды выключение
временных файлов на фронтэнде не будет так сильно сказываться на потере
производительности?
Создание временных файлов - это всегда некоторый оверхед.
Создание больших временных файлов - это огромный оверхед.
Для чего nginx создаёт временные файлы при проксировании ?
Для того, чтобы как можно быстрее принять ответ от бэкенда.
Зачем нужно быстро забрать ответ бэкенда ?
Потому что в случае использования mod_perl'а бэкенд может занимать
десятки мегабайт физической памяти и вся эта память в течение секунд,
минут и даже часов используется для обслуживания одного клиента.
Если же бэкендом, отдающий большой файл, будет nginx, то расходы памяти
на клиента будут порядка десятков килобайт физической памяти, то есть,
в 1000 раз меньше. Это значит, что такой бэкенд может обслужить в 1000
раз больше одновременных клиентов, чем mod_perl'овый, при той же памяти.
И в этом случае не нужно создавать временный файлы при проксировании
на фронтенде.
Игорь Сысоев
