Безусловно в вашем посте есть здравый смысл, но во всем нужна мера.
Может получиться так, что новичек прочтет ваш пост и начнет плодить сотни классов оберток, когда это нужно и не нужно.
Не стоит забывать, что на объявление класса и тратится процессорное время и оперативная память (внутренее устройство сложнее).
Доступ к данным поля объекта через вызов метода значительно медленнее, чем доступ к элементу массива, а если еще используются магические методы, разница огромна.
Всегда казалось, инстанцирование объектов в деструкторе дурным тоном. Одно неловкое исключение — fatal, порядок вызова неявный, заголовки отправлены, рабочая дирректория может отличаться… Для чего вам понадобилась сложная логика в деструкторе?
Ваш вопрос содержал ответ. Зависит от ситуации.
Гипотетически в книжный магазин ежедневно заливается сотни тысяч новых книг и журналов / товаров поставщиков. А покупается / ищется 100-200.
Говоря, к примеру, о MySQL и InnoDВ, помня про clustered index. Монотонно возрастающий ключ приводит к вставке строки в конец, иначе сортировке индекса.
Не будет ли автоинкрементарное поле в данном случае повышать производительность вставки с учетом разнобоя BookId, AuthorId? http://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html
На заметку, в MariaDB нет MyISAM, storage engine называется Aria. Выбор движка не очевиден, чем вам не понравился XtraDB?
Вы не сравнивали производительность WP + Varnish vs WP + memcached (например w3 total cache) vs WP +Varnish + Memcached ?
XDebug был отключен до профилирования, время схоже.
Под конец просто тестировал 3000000 md5 в cli. В докер контейнере результат PHP 5.6.1 cхожий с докер 7.0.0 и 5.6.1 из suse репозитория. А вот PHP 7.0.0 из репо отстает 20с против 5с, явно собрали с разными флагами.
Притом падение наблюдается если PHP пришел из реп (в моем случае OpenSuse)
Если запускать скрипты в официальных образах docker, падения производительности нет.
Протестировал на одном из своих проектов, к сожалению, PHP 7.0.0 не показал повышения производительности, есть даже небольшое падение.
Отключил memcached, прогнал на главной странице (анонсы всех разделов сайта, порядка 80 тяжелых запросов с сортировкой ~ 50 000 записей в бд)
Потребление памяти значительно снизилось:
PHP 5.6.1 — 2.411mb
PHP 7.0.0 — 1.301mb
А вот время исполнения незначительно ухудшилось:
PHP 5.6.1 — 0.98560s.
PHP 7.0.0 — 0.99667s.
Посмотрел профили XDebug, удалось выяснить некоторые причины.
— mysqli на PHP 7.0.0 работает немного медленее (практически все функции)
— md5 работает значительно медленее
— функции по работе со строками немного просели
и т.д.
Комментариев по существу как я понял не будет?
thedailybeast.com выставили NetCraker как источник проблем, который выплатил большую неустойку.
Интересовала ваша точка зрения. Компания допустила промах набрав слабый персонал / оговорили «злые янки» / «инопланетяне».
Обидно, подобные публикации бросают тень не только на вашу компанию, но и на Российских программистов. Более того, создается впечатление, что ситуация не злой умысел, а халатность. Очевидно, не все так просто, ну да ладно.
Здравствуйте! Неужели тот самый Netcracker… Было бы очень интересно услышать комментарии по поводу ситуации с «В США закрыли дело о заражении программистами из России систем Пентагона (http://www.rbc.ru/rbcfreenews/563acbf49a794787a2622435)
Особенно понравилось:
Компании заявили, что они не знали, что на них работают российские программисты.
Если вы являетесь Vendor и продаете конечный продукт ( софт который не используется для разработки и т.п), клиент использует ваше решение без внесения модификаций, то клиент не должен покупать лицензию. Так отвечала техподдержка несколько раз в 2010,2012,2015 годах. После этой статьи задавали вопрос еще раз.
Кстати, верно подмечено выше, вопреки общепринятому представлению GPL, Sencha трактует этот момент в свою пользу как передачу, стоит ли в случае чего с ними судиться стоит 100 раз подумать.
Sencha начали жадничать и закручивать гайки, увеличивать стоимость лицензии. Становится накладно иметь дело с их продуктами в форме Commercial License. Про OEM лицензию маленькие стартапы теперь вовсе могут забыть. Печально, все так хорошо начиналось, на 3,4 верси можно было купить лицензию за $300-$400 без поддержки на одного разработчика.
Может получиться так, что новичек прочтет ваш пост и начнет плодить сотни классов оберток, когда это нужно и не нужно.
Не стоит забывать, что на объявление класса и тратится процессорное время и оперативная память (внутренее устройство сложнее).
Доступ к данным поля объекта через вызов метода значительно медленнее, чем доступ к элементу массива, а если еще используются магические методы, разница огромна.
Гипотетически в книжный магазин ежедневно заливается сотни тысяч новых книг и журналов / товаров поставщиков. А покупается / ищется 100-200.
Не будет ли автоинкрементарное поле в данном случае повышать производительность вставки с учетом разнобоя BookId, AuthorId? http://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html
Вы не сравнивали производительность WP + Varnish vs WP + memcached (например w3 total cache) vs WP +Varnish + Memcached ?
Под конец просто тестировал 3000000 md5 в cli. В докер контейнере результат PHP 5.6.1 cхожий с докер 7.0.0 и 5.6.1 из suse репозитория. А вот PHP 7.0.0 из репо отстает 20с против 5с, явно собрали с разными флагами.
Если запускать скрипты в официальных образах docker, падения производительности нет.
Отключил memcached, прогнал на главной странице (анонсы всех разделов сайта, порядка 80 тяжелых запросов с сортировкой ~ 50 000 записей в бд)
Потребление памяти значительно снизилось:
PHP 5.6.1 — 2.411mb
PHP 7.0.0 — 1.301mb
А вот время исполнения незначительно ухудшилось:
PHP 5.6.1 — 0.98560s.
PHP 7.0.0 — 0.99667s.
Посмотрел профили XDebug, удалось выяснить некоторые причины.
— mysqli на PHP 7.0.0 работает немного медленее (практически все функции)
— md5 работает значительно медленее
— функции по работе со строками немного просели
и т.д.
Таблица с примерами времени исполнения:
thedailybeast.com выставили NetCraker как источник проблем, который выплатил большую неустойку.
Интересовала ваша точка зрения. Компания допустила промах набрав слабый персонал / оговорили «злые янки» / «инопланетяне».
Обидно, подобные публикации бросают тень не только на вашу компанию, но и на Российских программистов. Более того, создается впечатление, что ситуация не злой умысел, а халатность. Очевидно, не все так просто, ну да ладно.
Особенно понравилось:
в заметке для Consultants and Software Integrators
Это не считается распространением в GPLv3.
А вот AGPL накладывает ограничение и на SaaS