Comments 27
4. Стандартное решение:
class ProductCategory extends CActiveRecord
{
...
public function relations()
{
return [
'productsCount'=>array(self::STAT, 'Product', 'id_category'),
];
}
...
}
во-первых здесь речь про yii2, а не про yii1
Сути не меняет, все равно нужно будет делать count($model->productsCount).
Разве бывают случаи когда 500+ запросов к базе — нормально, что-то мне подсказывает, что стандартное решение содержит count() и group by…
Небольшой оффтоп, есть ли красивое решение для yii с использованием группировки?
Небольшой оффтоп, есть ли красивое решение для yii с использованием группировки?
Конечно запросик вроде:
Для этого случачая будет быстрее, тот же QueryBulder легко его построит, но к сожелению не всегда все задачи укладываються в один запрос, притом в тестах все-таки хотелось разной нагрузки.
SELECT COUNT(1),category.id
FROM `productCategory` as `category`, `product`
WHERE category.id = product.categoryId
GROUP BY product.categoryId
Для этого случачая будет быстрее, тот же QueryBulder легко его построит, но к сожелению не всегда все задачи укладываються в один запрос, притом в тестах все-таки хотелось разной нагрузки.
разработчики говорят о совместимости в 99%
Можно узнать, что осталось несовместимым в этом одном проценте?
Я решил погуглить «hhvm incompatibilities». Там какие-то ооочень специфические штуки. Например:
Values of bit data type are returned as binary strings (e.g. "\0" or "\x1F") with libmysql and as decimal strings (e.g. «0» or «31») with mysqlnd. If you want the code to be compatible with both libraries then always return bit fields as numbers from MySQL with a query like this: SELECT bit + 0 FROM table.
Просто у кого-то одного по каким то причинам не завелось.
samdark Сказал что сначала они указали 100% совместимость, но потом ему прилетело письмо от кого-то что возникли проблемы, поэтому они снизили до 99,99% :)
Говорилось это на конференции в Воронеже (если я не ошибаюсь)
Говорилось это на конференции в Воронеже (если я не ошибаюсь)
Не ошибаетесь rmcreative.ru/blog/post/rif-voronezh-2014-video
— Поддержка функционала php 5.6 кроме некоторых функций вроде eval, create_function.
В Yii2 используется eval(). В expression dependency, в частности.
у hhvm есть проблемы с serialize,unserialize — github.com/facebook/hhvm/issues/1620
через 9 месяцев решили все же разобраться :)
через 9 месяцев решили все же разобраться :)
9% прирост… это стоило того да. Можно поиграться с opcache и думаю добиться того же прироста производительности. В целом же за счет того что в Yii1 (да и во втором) все построено на магических методах то оптимизации сильно не добиться так как для магических методов не работает JIT.
ну собственно вы, как человек скептически настроенный к yii, увидели то, что хотели увидеть — бенчмарк Hello world'а. Очень объективно.
А тут больше и видеть то нечего, все остальное к Yii непосредственно имеет слабое отношение. Там где производительность поднялась больше чем на 10% был профит за счет оптимизаций связанных с обходом массивов, сериализацией и конструирование/разбор запросов/ответов в случае с reddis (в принципе работа со строками). В целом же сам фреймворк ускорился на каких-нибудь 10%, хотя справедливости ради стоит отметить что у Yii с оверхэдом всегда все было хорошо за счет очень простой архитектуры.
Меня больше напрягает что не приводятся данные по потреблению памяти, тестирование производилось судя по всему в один поток, никакого конкуренси… Между тем можно было бы оформить например в Docker контейнеры стэнды что бы люди могли позапускать на своем железе, возможно подправить чего (вдруг автор не сделал composer dump-autoload -o или еще чего), можно было бы поиграться с opcache… А так…
Меня больше напрягает что не приводятся данные по потреблению памяти, тестирование производилось судя по всему в один поток, никакого конкуренси… Между тем можно было бы оформить например в Docker контейнеры стэнды что бы люди могли позапускать на своем железе, возможно подправить чего (вдруг автор не сделал composer dump-autoload -o или еще чего), можно было бы поиграться с opcache… А так…
Та ладно не так и много там магии. Всякие Yii::$app->cache, всегда имеют аналог Yii::$app->getCache(); Хотя конечно совсем без магии не обойтись.
Весь AR на магии построен. Бехейверы, почти все используют $app->cache вместо $app->getCache или IoC. А между тем взять ту же задачу обхода 5К элементов AR. Простенький бенчмарк даже такого рода показывает что для php5.5 скажем отказ от магических методов в пользу обычных геттеров/сеттеров составляет ~30% (если мы просто дергаем данные из атрибутов), а для HHVM аж 60% за счет умения оной инлайнить обращения к полям, что по производительности делает обход списка объекто лишь немного медленнее старых добрых массивов.
Кому не нужно удобство AR то можно просто использовать как масив, или вообще писать по старинке sql код вручную. AR без магии с доступами к свойствам раздует модель жутко, зачем оно надо. Я вообще сторонник того что если надо быстрей, то нечего себе мозг… просто возьмите какой-нибудь GO там и кода будете писать побольше, но и оптимизация будет на порядок выше.
GO там и кода будете писать побольше
Если говорить об ORM, вы видели GORP? Как по мне намного элегантнее всего что есть в PHP.
Мой довод был не за то что бы не пользоваться ORM, меня вполне себе они устраивают. Я использую Doctrine2 в повседневной работе а ORM жирнее в PHP нет.
На go библиотек много, но если глянуть в сторону github, то есть один негативный момент, активность в репозиториях мала, в следствие чего автор забивает на проект, по тому что у него нет фидбеков. Хотя сейчас с этих улучшается бесспорно. Но все-равно набор библиотек и их простота не сравнимы с тем что есть на php, python… По этому и всплывает расплата за производительность, которая выливается в большие временные затраты. Как говорится нужно просто выбрать инструмент под задачу, и не пытаться путем отсечения всего удобного, что есть в технологии выгрызть миллисекунды.
Хотя вашу точку зрения я понимаю, и понимаю что бывает разное. Но на такой случай как я писал ниже. Просто переходим на уровень проще. Их в yii 2 выходит аж 3 штуки, выбирай — не хочу.
Хотя вашу точку зрения я понимаю, и понимаю что бывает разное. Но на такой случай как я писал ниже. Просто переходим на уровень проще. Их в yii 2 выходит аж 3 штуки, выбирай — не хочу.
А почему HHVM это экспериментальная виртуальная машина? По-моему она уже очень давно в продакшене и вполне успешно там используется.
Если убрать AR в тех местах где он не нужен то можно выиграть думаю больше. Если пользовать самый неудобный метод построения запросов — commandBuilder (или как он там), то будет прирост раз в 10 на запросах. Если QueryBuilder, то раз в 5. QueryBuilder в принципе можно не использовать, а вызывать просто asArray().
Хотя если вообще все выкидывать и экономить на спичках, то это уже не то. Проще тогда сразу брать какой-нибудь Go.
Хотя если вообще все выкидывать и экономить на спичках, то это уже не то. Проще тогда сразу брать какой-нибудь Go.
Экономия на спичках должна быть тогда, когда больше неначем экономить. Если у вас проект помещается на одном сервере при том что вы используете ORM то беспокоиться неочем, а оверхэд работы AR в Yii невилируется если с ним грамотно работать. Тяжелые операции или операции которые с AR делаются как-то нелогично естественно можно делать напрямую через querybuilder какой и т.д. AR в Yii дико простой, хотя возможно вкрутить если туда прокси классы какие можно было бы много чего оптимизировать… но думаю что профит не стоит подобны усложнений. Вот в Doctrine это да.
Sign up to leave a comment.
Yii2 тестируем на HHVM