11.08.2010 21:09, Sergey Vlasov пишет: > On Wed, Aug 11, 2010 at 03:58:39PM +0300, Slava Dubrovskiy wrote: > >> 10.08.2010 22:01, Sergey Vlasov пишет: >> >>> >>>>> 2. Зачем конфиги располагаются в версийзависимых директориях? >>>>> >>>>> >>>> Чтобы можно было держать несколько php разных версий одновременно. >>>> >>>> >>> Вопрос в том, насколько разных? Т.е., нужно ли обеспечивать >>> теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14? >>> >>> >> Я думаю что такой необходимости нет. Например Cpanel предоставляет 2 >> версии (4 и 5 ветки) одновременно, но выбор внутри ветки ограничен одной >> версией. В нашем случае разница между 5.2 и 5.3 достаточно существенна и >> есть необходимость иметь возможность иметь их обе в системе. >> Поэтому поддерживаю Антона в том, чтобы убрать разделение конфигов по >> минорной версии и сделать, например, так: >> /etc/php/5.2 >> /etc/php/5.3 >> и т.д. >> где будут в подпапках с именем sapi располагаться конфиги и директории >> для расширений. >> > При этом для разноса конфигураций разных sapi по разным каталогам php > надо патчить; в случае размещения всех файлов php-SAPI.ini для одной > версии рядом в одном каталоге даже патчить не надо (кроме scan_dir). > > >>> Кстати, использованный метод реализации (php_ini_path_override в >>> каждом sapi) в некоторых случаях ведёт себя не так, как оригинальный >>> (например, если установлена переменная PHPRC, но в указанном там >>> каталоге нет php.ini, системный php.ini не будет найден). Возможно, >>> применённая схема была не совсем правильной (вместо засовывания >>> каждого sapi в отдельный каталог можно было собирать php с >>> --with-config-file-path=%php5_sysconfdir, а для поддержки отдельных >>> файлов конфигурации для разных sapi создавать там файлы php-SAPI.ini, >>> не трогая стандартный механизм поиска). >>> >>> >> Что-то подобное сделано в сборке remi. И я попытался воспроизвести >> применительно к АЛЬТ. См. у меня в php53.git >> > Там вариант с дублированием основной части кода (без вынесения > основной части в libphp)? Да > Тогда поводов для дополнительных патчей ещё > меньше (можно просто конфигурировать каждый вариант sapi с > индивидуальными параметрами). > Именно так и сделано. Правда пока я еще не понял все плюсы и минусы выделения libphp. Вот из плюсов legion@ отметил что mod_php на 4М меньше. Но минус в том, то нужно патчить все это, получать дополнительные проблемы в виде трудно обновляемых конфигов. Но самое важное, это производительность. Мне кажется, что с libphp она ниже. Наши девелоперы сделали один достаточно тяжелый магазин. И затем этот же магазин развернули в соседней VPS. Получилось 2 VPS с одной версией php но одна на сизифе, вторая на центосе 5.5. Ничего лишнего там небыло. И при этом оптимизировали время отдачи контента. Так вот у нас время отработки скриптов на 10-20% больше чем, например, та же версия php на центосе собранная без libphp. Других объяснений, кроме как разного системы сборки php не могу найти. Кто-то может объяснить такое? >>> Впрочем, основная проблема в наличии в php.ini настроек, зависящих от >>> версии php - safe_mode_include_dir, include_path, extension_dir, >>> alt_sapi_config_ini_scan_dir, из-за которых при изменении версии php в >>> любом случае придётся править этот файл. Причём введение переменной >>> alt_sapi_config_ini_scan_dir, насколько я понял, вызвано главным >>> образом желанием использовать отдельные каталоги для разных sapi (в >>> противном случае хватило бы опять-таки сборки с нужным значением >>> --with-config-file-scan-dir); в принципе это место можно попытаться >>> пропатчить для использования php-SAPI.d и избавиться от переменной в >>> php.ini (которая тоже добавлена патчем). >>> >>> >> Кстати в .ini который идет в оригинале нет никаких переменных. Т.е. >> нашли на свою голову проблемы. >> > В оригинале там в примерах настроек нет имён каталогов, зависящих от > версии php; в большинстве дистрибутивов, похоже, этим тоже не > заморачиваются. > Да, именно так. -- WBR, Dubrovskiy Vyacheslav