phpBB : настройка и модификация

Эксперименты показали, что ускорение за счет увеличения параметров кэширования realpath достигается только на серверах под windows. Печалька

заменил согласно рекомендациям настройки со стандартных значений на
realpath_cache_size 4096k
realpath_cache_ttl 3600
у меня юникс сервер, разницы никакой.
вопрос - стоит ли оставить эти значения? или вернуть дефолтные? не скажутся ли изменения на ухудшении работы сайта?

Эти параметры имеет смысл менять или как-то двигать только при наличии какого-либо опкешера байт кода. В противном случае вообще нефиг эти параметры трогать. Встроенный OPcache появился в PHP 5.6. Ещё требуемые значения очень зависят от параметров сервера, например от того, в каком режиме работает PHP: если в режиме apache, то показатели будут одни, а в режиме cgi совсем другие. Да и не только от этого. Всё зависит от картины в целом, стоит ли nginx на статике, кешируется ли что в nginx. Очень дофига тут от чего может зависеть. Надо как минимум знать конфигурацию сервака в целом, чтобы что то подсказать. Ну и конечно, желательны тесты, чтобы были сделаны на проблемном серваке, дабы выявить узкие места. Сервер не оптимизируется вот так от головы. Ищутся слабые места, самые узкие, и уже оттуда начинают оптимизацию. У тебя могут зависать и ложить сервак процессы Апача, но причина может быть в том, что в конфигах nginx стоит слишком большой параметр до сброса заголовка когда нет ответа, и создается очередь. Т.е. ложится апач, а виноват nginx. Нет универсальных решений. Надо смотреть.

Это мне так знакомый серверщик сказал.

Не совсем так: opcache появился в php 5.5, параметры realpath можно и нужно трогать при отсутствии опкэшера (специально провел эксперименты). Ну а nginx на мой извращённый вкус - это вообще зло, связку с apache мало кто правильно делает

у меня вроде XCache включен.
пока оставил как есть, хуже работать не стало.

Alecto, можно из спортивного интереса отказаться от файлового кэша, всё взвалив на xcache, для этого в config.php в строкезаменить file на xcache. Это не стоит делать на версиях ниже 3.1.6, ибо там были глюки с очисткой кэша. Кроме того, после изменений очистка кэша вручную через ftp или zcache работать не будет. Было бы интересно попробовать, если вдруг что-то пойдёт не так - всегда можно вернуться к файловому кэшу, предварительно почистив папку cache. Проводил такие эксперименты с apc, всё было отлично, но не стал использовать из-за глюков самого apc, возникавших при очистке кэша. А на xcache ни разу не пробовал - вот и интересно, что получится...

Добавлено спустя 2 минуты 33 секунды:
Во, вспомнил, драйвер xcache в phpbb это для lighttpd, для апача нет, так что "все назад"

В phpbb есть кэши file, apc, eaccelerator, memcache, xcache, wincache (для винды) и null (который ничего не кэширует) и не помню что ещё.

не готов для таких экспериментов на живом сайте, тем более что сам в настройках сервер не разбираюсь от слова "совсем", а гонять саппорта - долго в случае негативных изменений.
может быть есть еще проверенные советы по оптимизации? параметры сайта доступны здесь (можно ли как-то скрыть ссылку от гостей?)

В настройках xcache.count и xcache.var_count задают одинаковыми в зависимости от числа потоков (ядер процессора; если одно - то 1, если 2 - то 2), если мне склероз не изменят... У Вас count равен 2, а var_count равен 1. gc_interval маловат, можно увеличить до 1200 или 3600 (через какое время проверять устаревшие записи). У xcache есть админка, ее можно поставить и смотреть на результаты, затем покрутить параметры.

А ссылочку на phpinfo лучше прибить, мало ли что...

Alecto писал(а):(можно ли как-то скрыть ссылку от гостей?)

c61 писал(а):У xcache есть админка

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

Shredder писал(а):если в режиме apache, то показатели будут одни, а в режиме cgi совсем другие

Единственно верный режим- php5-fpm, всё остальное не то (если конечно у вас там не пул воркеров вебсокет-сервера на php, ну да там свои приколы).

c61 писал(а): Ну а nginx на мой извращённый вкус - это вообще зло, связку с apache мало кто правильно делает

Лол. Всё ровно наоборот. nginx + php5-fpm дерёт apache + mod_php и в хвост и в гриву при правильных настройках.

Alecto писал(а):может быть есть еще проверенные советы по оптимизации?

Не совсем по оптимизации, но версия 5.4 уже устарела и больше не поддерживается.

я могу выбрать в сипанели любую версию, помоему 5.6 сейчас самая верхняя из доступных, но максимально быстро работает 5.3 и 5.4, 5.5 уже на %20-30 помедленнее. в 5.3 глючат некоторые расширения, 5.4 - вполне устраивает, поэтому и держу ее.

Добавлено спустя 49 минут 36 секунд:
внес рекомендованые правки:
xcache.count = 2
xcache.gc_interval = 3600
xcache.var_count = 2
xcache.var_gc_interval = 3600

Xisp писал(а): nginx + php5-fpm дерёт apache + mod_php и в хвост и в гриву при правильных настройках

lighttpd бьёт всех и вся даже при неправильных настройках Между прочим, nginx использует примерно такую же как у lighttpd технологию обработки запросов, а lighttpd появился намноооого раньше.

внес рекомендованые правки:

Не думаю, что стало лучше, но хоть теперь стало "правильнее"...

c61 писал(а):Не думаю, что стало лучше, но хоть теперь стало "правильнее"...

нет, улучшений не заметил, равно как и ухудшений.
так что, пожалуй, оставлю как сейчас.
спасибо за советы

Добавлено спустя 3 минуты 23 секунды:

Shredder писал(а): режиме apache, то показатели будут одни, а в режиме cgi совсем другие

apache

Shredder писал(а): У тебя могут зависать и ложить

нет, у меня вообще нет никаких проблем с работой сервера, просто думал, может удастся выжать еще что-то по времени, которое сейчас состовляет
0.25-0.3 для индекса и 0.3-0.4 для вьютопика.

Alecto писал(а): 5.5 уже на %20-30 помедленнее

Настройки, я думаю.

c61 писал(а):lighttpd бьёт всех и вся даже при неправильных настройках

И ничего не умеет

c61 писал(а):Между прочим, nginx использует примерно такую же как у lighttpd технологию обработки запросов, а lighttpd появился намноооого раньше.

Ну конечно, ибо производительная архитектура. Но nginx можно выбрать только за то, что его писал русский программист. Поддержим отечественного производителя!