Комментарии 17
Вот тут rmcreative.ru/blog/post/slaydy-s-uwdc-2013 некоторые комментарии по поводу моих слайдов с UWDC.
Сколько уже можно про новые расширения mysql, уже сколько раз говорили что старое расширение до сих пор не плохо, нигде не устарело и часто работает быстрее. По пунктам:
1. Обязательное указание db_link в mysqli. В 99% приложениях используется одно соединение с базой данных, и здесь вполне хватает старого mysql где оно optinal.
2. Prepared Statements. Бесполезны с точки зрения быстродействия, даже вредны. Полезны только если использовать какой-нибудь PHPDaemon где один вечноживущий процесс php и где prepared statements не будут исчезать на каждый запрос.
3. Multiquery. Да, это хорошо. Но часто ли есть необходимость использовать множественные запросы, не проверяя результат выборки между ними? А для множественных INSERT можно обойтись и одним INSERT со множеством значений для вставок, а также вариациями IGNORE и ON DUPLICATE KEY UPDATE (большинство о них почему-то забывает и хотят использовать более медленные multiquery).
4. Транзакции. Приведёт неудачный пример, можно было обойтись одним словом INSERT IGNORE. Да и обычные SQL SET AUTOCOMMIT=0 и BEGIN/COMMIT/ROLLBACK тоже никто не отменял.
1. Обязательное указание db_link в mysqli. В 99% приложениях используется одно соединение с базой данных, и здесь вполне хватает старого mysql где оно optinal.
2. Prepared Statements. Бесполезны с точки зрения быстродействия, даже вредны. Полезны только если использовать какой-нибудь PHPDaemon где один вечноживущий процесс php и где prepared statements не будут исчезать на каждый запрос.
3. Multiquery. Да, это хорошо. Но часто ли есть необходимость использовать множественные запросы, не проверяя результат выборки между ними? А для множественных INSERT можно обойтись и одним INSERT со множеством значений для вставок, а также вариациями IGNORE и ON DUPLICATE KEY UPDATE (большинство о них почему-то забывает и хотят использовать более медленные multiquery).
4. Транзакции. Приведёт неудачный пример, можно было обойтись одним словом INSERT IGNORE. Да и обычные SQL SET AUTOCOMMIT=0 и BEGIN/COMMIT/ROLLBACK тоже никто не отменял.
Автор поста предлагает включить в PHP некоторый метод, который бы позволял кэшировать состояние приложения между запусками (запросами). В общем, нечто похожее на APC или Zend Optimizer+ но для кэширования объектов и данных, а не опкода. Интересно, но вряд ли когда-либо такое будет.
Так уже сейчас можно. Этот процесс называется «демонизацией». Для больших фреймворков (время bootstrap > 30% от времени обработки запроса) — очень актуально. Как раз прорабатываю один из вариантов.
PHPDaemon есть. Но ни одной CMS/Framework пока нет которая его поддерживает.
см. Ratchet. Работает на базе React. Впилить можно в принципе куда угодно. К тому же недавно видел статью "Handling Symfony2 Events Asynchronously". Там через ZeroMQ реализовать предлагают. Короче интересная тема :-)
Yii прекрасно работает с PHPDaemon.
security.sensiolabs.org — действительно полезная вещь.
Как-то вы релизы Symfony2 вообще игнорируете.
Минорные релизы и беты вообще редко включаем в дайджест, потому как много их слишком и обычно в них мало интересного. Или о каких именно вы релизах?
Погодите, за две недели вышла пара RC-релизов. А на этой неделе должна стабильная выйти.
Даешь дайджест слонов-игрушек из мира PHP!
Про объекты и массивы в 5.4 действительно интересно!
Глупая идея для ядра PHP? — Автор поста предлагает включить в PHP некоторый метод, который бы позволял кэшировать состояние приложения между запусками (запросами). В общем, нечто похожее на APC или Zend Optimizer+ но для кэширования объектов и данных, а не опкода. Интересно, но вряд ли когда-либо такое будет.
Так ведь данные можно кэшировать в APC в разделяемую память — есть функции apc_store() / apc_fetch(), или я не так понял и речь про что другое?
Спасибо за наводку на Faker.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дайджест интересных новостей и материалов из мира PHP за последние две недели №11 (12.02.2013 — 25.02.2013)