2010-01-26 3 views
1

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

<?php 
/** 
* @Filename app-config.php 
* @description Array to return to our config class 
*/ 
return array(
    'db_host' => 'localhost', 
    'db_name' => 'socialnetwork', 
    'db_user' => 'root', 
    'db_password' => '', 
    'site_path' => 'C:/webserver/htdocs/project/', 
    'site_url' => 'http://localhost/project/', 
    'image_path' => 'C:/webserver/htdocs/fproject/images/', 
    'image_url' => 'http://localhost/project/images/', 
    'site_name' => 'test site', 
    'admin_id' => 1, 
    'UTC_TIME' => gmdate('U', time()), 
    'ip' => $_SERVER['REMOTE_ADDR'], 
      'testtttt' => array(
        'testtttt' => false 
        ) 
); 
?> 

Пожалуйста, обратите внимание, фактический конфигурационный массив MUCH MUCH больше, еще много элементов в нем ...
Тогда у меня будет файл Config.class.php, который будет загружать мой файл массива и использовать магический метод __get ($ key). то я могу AutoLoad мой файл класса конфигурации и получить доступ все установки, как это ...

$config->ip; 
$config->db_host; 
$config->db_name; 
$config->db_user; 

Так что я понимаю, что это прекрасно работает и очень гибкий, в моем классе я могу это прочитать в PHP файл с массивом как я делаю сейчас, читаю INI-файл в массив, читаю XML-файл в массив, читаю JSON-файл в массив. Поэтому он очень гибкий для будущих проектов, но меня больше беспокоит производительность для этого конкретного проекта, над которым я сейчас работаю, это будет сайт социальной сети, такой как facebook/myspace, и у меня был один до этого проекта, и как только я производительность около 100 000 пользователей стала очень важной. Поэтому я не «оптимизируюсь» или «преждевременно оптимизирую». Я стараюсь сделать это ЛУЧШИМ способом с учетом производительности, ему не нужно быть гибким, поскольку мне это нужно только в этом проекте.

Так что с этой информацией я всегда читал о людях, пытающихся устранить вызовы функций как можно больше, говоря, что вызовы функций вызывают больше накладных расходов. Так что я хочу узнать от более опытных людей, что вы думаете об этом? Я новичок в использовании классов и объектов в PHP, поэтому вызывается $ config-> db_user; столь же дорогостоящим, как вызов функции в процедурной форме, такой как getOption ('db_user'); ? Я предполагаю, что это то же самое, что и каждый раз, когда я бы назвал параметр, использующий метод __get().

Итак, для лучшей производительности я должен пойти по этому пути по-другому? Как только загрузка моего конфигурационного массива в файл загрузки и доступ к элементу, когда они нужно мне, как это ...

$config['db_host']; 
$config['db_username']; 
$config['db_password']; 
$config['ip']; 

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

ответ

4

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

Кроме того, с точки зрения оптимизации. Наибольший успех для любого отдельного запроса в описываемой вами системе, вероятно, будет разбор XML/INI/JSON, а не доступ к нему через любой синтаксис, который вы решите использовать. Если вы хотите исправить это, сохраните загруженные данные в APC после его анализа. Это будет сделано с одной оговоркой, что вы захотите хранить только статические данные, а не динамические вещи, такие как дата UTC.

+0

+1 для указания доступа к файлам и синтаксического анализа является настоящим узким местом здесь и для предложения APC – Gordon

3

Во-первых, вместо включенного файла, который возвращает массив, я бы вместо этого использовал файл .ini, а затем использовал PHP parse_ini_file() для загрузки настроек.

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

Функциональные вызовы являются только проблемой, если, например, выполнение одного сценария исполняет 100 000 из них.

Так что выбирайте, какая из них самая естественная. Либо объект, либо массив будут работать одинаково хорошо. На самом деле объект имеет преимущество в том, что вы можете сделать:

$db = $config->database->hostname; 

где $config->database может неявно загружать только раздел базы данных из файла INI и создаст другой объект конфигурации, который может вернуть hostname запись. Если вы хотите сегментировать конфигурационный файл таким образом.

+0

Почему вы рекомендуете, чтобы помимо этого некоторые FW использовали его, и его легко отличить от PHP-кода? Храните его как массив, чтобы быть самым быстрым способом. –

+0

@Itay Moav: файлы INI должны быть быстрее, чем массивы PHP, хотя я не учитываю накладные расходы '__get()' в подсказке cletus, конечно. –

+0

Единственной причиной, по которой я избегал использования ini-файла, является то, что я не могу установить такие значения, как IP-адрес пользователя или текущая временная метка UTC для одного из значений. Мне кажется, что любой маршрут я иду, я в основном беру массив, а затем обертываю его в класс, который просто кажется, что он добавляет много накладных расходов, может быть? Я должен добавить к моему сообщению, некоторые элементы конфигурации, возможно, придется просматривать снова и снова на странице. Пример, если мне нужно было получить доступ к настройке ip 10 раз на странице, тогда это будет 10 вызовов функций для одного и того же значения, как вы думаете, было бы лучшим решением для такого типа ситуации? – JasonDavis

1

ИМО это самые быстрые методы (в порядке убывания):

  1. $config['db_user']
  2. $config->db_user непосредственно
  3. $config->db_user через __get()
  4. getOption('db_user') через __get()

Кроме того, у Вас есть уже много задал questions about your config system, не то, что я возражаю, но я специально вспомнил, что вы спросили a question about whether you should use parse_ini_file() or not.

Почему вы повторяете в основном одни и те же вопросы снова и снова?

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

+0

(удалены комментарии, которые на самом деле не добавили никакого значения) –

Смежные вопросы