Оптимизация fastcgi + php5

Я думаю, что Ваши данные нормальны, это, они отличаются, но только очень немногими %. Я видел значение этого типа на многих других нескольких равных дисках.

Andrea

0
задан 30 May 2011 в 12:26
3 ответа

У одного из поставщиков были проблемы при ответе на запросы, таким образом, все поиски на сайте стояли в очереди много потоков, ожидающих, чтобы быть выполненными fastcgi. Кажется, что там не реально, закрепляют на fastcgi стороне, а скорее реализуют надлежащий тайм-аут в коде и возможно обнаруживают, когда поставщики являются unrespnsive - и прекращают отправлять больше запросов туда.

Кроме того, я переключился на php-fpm и теперь контролирую "/состояние" непрерывно для обнаружения проблем как они рано.

0
ответ дан 4 December 2019 в 14:44

Измените свой двоичный файл PHP на FPM вместо старого fastcgi.

FPM (Диспетчер процессов FastCGI) является альтернативной реализацией PHP FastCGI с некоторыми дополнительными функциями (главным образом) полезными для тяжело загруженных сайтов.

Намного более стабильные работы, у Вас не должно быть проблем тайм-аута с ним.

1
ответ дан 4 December 2019 в 14:44

Как сказанный vartec, PHP-FPM является, вероятно, хорошей идеей здесь. Обратите внимание, что версия PHP 5.2 не поддерживает порождение динамического процесса (несмотря на него являющийся настраиваемой опцией), таким образом, необходимо удостовериться, что у Вас есть достаточно рабочих для обработки всех транспортных скачков.

Если бы Вы переключаетесь на PHP-FPM, одно преимущество было бы кэшем кода операции, совместно используемым всеми Вашими процессами PHP (что-то, чего это возможно достигнуть с lighttpd методом, но немного более раздражающий).

Какие запросы/секунда Вы видите? Я обычно пытаюсь выполнить один процесс PHP для каждого запроса/секунда, который видит сервер. Это не может быть лучшей идеей об относительно низкой системе памяти, но я еще не столкнулся ни с какими проблемами.

Вы используете сокет Unix или TCPIP для соединения lighttpd и php? Необходимо определенно переключиться на сокеты Unix при использовании TCPIP. Я видел все виды неустойчивых, жестких для диагностирования проблем при использовании TCPIP. Можно поражать пределы брандмауэра или ограничения соединения с TCPIP.

Вы контролируете с чем-то как Munin? Это, вероятно, было бы удобно, чтобы у Вас были графики нагрузки по трафику, загрузки сервера, mysql загрузка, и т.д. В то время как это не устранит Вашу проблему только при наличии их, они будут очень удобны Вам.

1
ответ дан 4 December 2019 в 14:44

Теги

Похожие вопросы