@CHADo при включенной перекомпиляции ошибка видна не только в siege но и в логах + сам если обновляю в браузере под нагрузкой, частенько код html тупо до конца не грузится (2/3 страницы и обрыв). Если выключить перекомпиляцию все ок.
Сделал sysctl net.core.somaxconn=4096, поставил один воркер и worker_connections=2048. Установил на сервер локально siage, при 300 одновременных соединений к 127.0.0.1/, если зайти на сайт через браузер, лезет 502 периодически от имени nginx. Более 300 не получается, пишет мол сокетов не хватает. Timeout=1 дефолтный. Это нормально? Подскажите, как число сокетов для теста увеличить, хочу больше подключений попробовать.
В режиме перекомпиляции шаблонов response time 0.36s, число failed 10-15% от общего числа хитов. В боевом режиме без перекомпиляции 0.28s. Число failed = 0. Тестирую с домашнего компьютера, не локально то есть. Не знаю как скорость моего домашнего интернета влияет на repsonse time, но сама генерация внутри php занимает в среднем 0.05 - 0.08s, скрипты легкие, этот показатель давно уже мониторю.
Есть у меня одна мысль. В режиме перекомпиляции, каждый раз происходит opcache_reset(), что приводит к пересборке сайта я так понимаю и грузит файловую систему.
Прогнал iotop, в режиме перекомпиляции активность php-fpm от 1% вплоть до 20%. Это нормально? Каждое обращение порядка 10 файлов-шаблонов пишет/читает. В боевом режиме активность десятые проценты.
Т.е. судя по всему, в боевом режиме если поток людей будет очень большим, 502 ошибку по причине нагрузки на запись в диск я врятли увижу?
Ошибка возникает, если включить в шаблонизаторе режим постоянной перекомпилировки шаблонов из tpl в php, тоесть при обширной работе с записью/чтением файлов. В статичном режиме шаблонизатора (только чтение) ошибка не лезет вообще. Я понимаю, что время генерации в режиме перекомпиляции должно быть больше, но всё равно ошибки это не нормально я так понимаю.
