Какого ловца кода операции PHP я должен использовать для улучшения производительности? [закрытый]

Использовать Query :: matching () или Query :: innerJoinWith ()

При запросе из таблицы Contacts то, что вы ищете, это Query::matching() или Query::innerJoinWith(), not ( только) Query::contain().

См. Cookbook> Database Access & amp; ORM> Query Builder> Фильтрация связанными данными

Вот пример использования ваших таблиц:

$this->Contacts
    ->find()
    ->matching('Users', function(\Cake\ORM\Query $q) {
        return $q->where(['Users.id' => 1]);
    });

Это автоматически добавит необходимые условия соединения + к сгенерированному запросу .

Целевая таблица соединений

Если вы вручную настроили много-много ассоциаций через hasMany и belongsTo, вы можете напрямую настроить таргетинг на таблицу соединений:

$this->Contacts
    ->find()
    ->matching('ContactsUsers', function(\Cake\ORM\Query $q) {
        return $q->where(['ContactsUsers.user_id' => 1]);
    });

Включить сдерживания

Если вы действительно хотите, чтобы все ассоциации были возвращены в ваших результатах, просто продолжайте использовать contain() слишком

$this->Contacts
    ->find()
    ->contain('Users')
    ->matching('Users', function(\Cake\ORM\Query $q) {
        return $q->where(['Users.id' => 1]);
    });

Это будет содержать всех пользователей, принадлежащих к контакту.

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

$this->Contacts
    ->find()
    ->contain(['Users' => function(\Cake\ORM\Query $q) {
        return $q->where(['Users.active' => true]);
    }])
    ->matching('Users', function(\Cake\ORM\Query $q) {
        return $q->where(['Users.active' => true]);
    });

Глубокие ассоциации

Вы также можете нацеливать более глубокие ассоциации таким образом, используя синтаксис с обозначением точки с нотами, известный из Query::contain(), например, если вы также имеет ассоциацию Users hasOne Xyz, вы можете фильтровать Xyz.id с помощью

->matching('Users.Xyz', function(\Cake\ORM\Query $q) {
    return $q->where(['Xyz.id' => 1]);
})

Выберите из другой таблицы вместо

. С этими ассоциациями и вашими простыми требованиями вы также можете легко запросить с другой стороны, то есть через таблицу Users, и использовать только Query::contain() для включения связанных контактов, например

$this->Users
    ->find()
    ->contain('Contacts')
    ->where([
        'Users.id' => 1
    ])
    ->first();

. Все контакты могут быть найдены в сущностях contacts свойство.

57
задан Neysor 1 April 2012 в 08:56
поделиться

7 ответов

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

для принятия моего решения, я использовал ab (апачское место размещения) для тестирования сервера, и протестировал эти три комбинации (пехлеви, eaccelerator, оба выполнения) и доказал, что eAccelerator самостоятельно дал самую большую производительность.

, Если бы у Вас есть роскошь времени, я рекомендовал бы делать подобные тесты самих и принять решение на основе Ваших результатов.

16
ответ дан mercutio 26 November 2019 в 16:55
поделиться

Я использую APC, потому что было легко установить в окнах, и я разрабатываю на WAMP.

Интегрирующийся APC в PHP6 был обсужден здесь: http://www.php.net/~derick/meeting-notes.html#add-an-opcode-cache-to-the-distribution-apc

И существуют направления при установке APC на Травлении Debian здесь: http://www.howtoforge.com/apc-php5-apache2-debian-etch

5
ответ дан Ed Haber 26 November 2019 в 16:55
поделиться

Я выполнил несколько сравнительные тесты с eAcclerator, APC, XCache и Оптимизатором Зенда (даже при том, что Пехлеви является оптимизатором, не кэшем).

Результаты Сравнительного теста http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png

Результат: eAccelerator является самым быстрым (во всех тестах), сопровождаемый XCache и APC. (Тот в схеме является числом секунд для вызова домашней страницы WordPress 10,000 раз).

Оптимизатор Зенда сделал все медленнее (!).

5
ответ дан James 26 November 2019 в 16:55
поделиться

Я не могу сказать Вам наверняка, но место, где я работаю теперь, смотрит на APC и eAccelerator. Однако это могло бы влиять на Вас - , APC будет интегрирован в будущий выпуск PHP (благодаря Ed Haber для ссылки).

4
ответ дан Thomas Owens 26 November 2019 в 16:55
поделиться

Я имел хороший успех с eAccelerator (улучшение скорости без загрузки noticable), но XCache также кажется довольно многообещающим. Можно хотеть запустить некоторые пробные версии с каждым, хотя, приложение могло бы масштабироваться по-другому на каждом.

3
ответ дан Dana the Sane 26 November 2019 в 16:55
поделиться

Я использовал XCache больше года теперь без проблем вообще.

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

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

1
ответ дан The How-To Geek 26 November 2019 в 16:55
поделиться

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

, Таким образом, я сказал бы:

  1. не используют ни одного вышеупомянутого. Купите больше олова вместо этого, это - более надежное (т.е. безошибочный) способ увеличить производительность. ИЛИ
  2. Идут с тем, какой бы ни из вышеупомянутого является самым устойчивым, протестировав штаны от Вашего приложения.

, Но я сказал бы:

  1. Удостоверяются, что это - ДЕЙСТВИТЕЛЬНО код PHP, анализирующий, который вызывает Ваши проблемы производительности путем профилирования приложения. Я думаю, что чрезвычайно вероятно, что это не - в этом случае Вы потратили бы впустую свое время (на самом деле, с помощью времени негативно продуктивно) путем установки любого из них.
1
ответ дан MarkR 26 November 2019 в 16:55
поделиться
Другие вопросы по тегам:

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