Разница в производительности среди конфигурационных файлов для PHP - PullRequest
1 голос
/ 02 декабря 2011

Я создаю сайт, данные конфигурации которого хранятся в php file, с не более чем 15 строками переменных.

До сих пор все работало хорошо, но теперь я сталкиваюсь с необходимостьюДля определения большего количества переменных и небольшого исследования я нашел статью о конфигурации приложения в PHP , в выводах которой говорится, что php files является наиболее подходящим вариантом при анализе их масштабирования (Databases - лучший выбор).

Какой наиболее рекомендуемый вариант при выборе формата используемого файла конфигурации?

Ответы [ 3 ]

3 голосов
/ 02 декабря 2011

Прости, что?!

php-файлы являются наиболее подходящим вариантом при анализе их масштабирования (базы данных - лучший выбор).

Это просто странно, потому что вы можете очень хорошо масштабировать php - просто настройте другой сервер, и все, вы дважды масштабировали свой php.

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

Принимая во внимание, что масштабирование баз данных является ракетостроением. Масштабирование баз данных - сложный процесс, требующий хороших внутренних данных и знаний вашей ОС.

Так что я бы никогда не сослался на эту статью.

PS: посмотрел на статью:

Когда скрипт запускается, результаты в нем. В среднем около 0,052640, что делает этот метод самым медленным на сегодняшний день.

Я не могу понять, как просто создание экземпляров переменных может быть медленнее, чем чтение из базы данных (что включает в себя издержки соединения, чтение из таблиц заголовка, передачу данных и один и тот же процесс создания переменных в конце). X просто не может быть больше X + Y по определению.

2 голосов
/ 02 декабря 2011

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

Однако, если конфигурация хранится в базе данных, и для ее получения требуется много объединений без кэширования, производительность может быть хуже, чем при использовании файлов PHP.

С другой стороны, если вы храните свою конфигурацию в файле PHP, который возвращает массив:

//config.php
return array(
   'configitem1' => 'xyz',
)

//then use
$config = require_once('config.php);

производительность не должна быть слишком плохой. Очевидно, что для каждого запроса будет дисковый ввод-вывод, поэтому вы можете увидеть некоторые проблемы с производительностью, если вам требуется много файлов. Вы всегда можете кэшировать результаты в memcached или APC, чтобы избавиться от проблем с производительностью дискового ввода-вывода при необходимости загрузки файлов.

Наконец, вы можете использовать файлы XML или YAML. Они будут наименее производительными, так как вам нужно будет загрузить и прочитать файл, а затем проанализировать его.

Лично я считаю, что конфигурация должна храниться в базе данных, где пользователю приложения может понадобиться ее изменить. Например:

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

Всегда будет конфигурация, которую вам нужно сохранить в файлах:

  • Параметры подключения к базе данных
  • Настройки кэша (то есть настройки memcached).

Однако конфигурацию, хранящуюся в файлах, можно кэшировать в memcached или APC, поэтому ваше приложение все равно должно работать.

Итак, мои 2 цента:

  • Используйте базу данных для хранения конфигурации, если пользователю НУЖНО иметь возможность ее изменить.
  • Сохранение другой конфигурации в файле PHP в виде массива и использование кэширования.
  • Используйте YAML и XML в качестве последнего средства.
0 голосов
/ 02 декабря 2011

Вот почему статья не так:

Type    First Run   Second Run
Ini File    0.000421    0.021381
XML File    0.000717    0.012310
PHP File    0.000450    0.052640
Database    0.005533    0.014184

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

...