Переоптимизация
Переоптимизация. Болезнь, которой страдают многие неопытные разработчики.
Попробуйте ответить на такой вопрос на засыпку: есть программа, вы провели её профилирование и обнаружили, что одна из функций занимает 99% времени процессора. Ваши дальнейшие действия?
Если вы ответили «конечно попытаюсь оптимизировать эту функцию!», то вы попались в ту же ловушку. Программа должна решать поставленные перед ней задачи. Если программа должна выдавать человеку список чего-то, то хотя одна из функций занимает 99% затраченного процессорного времени, но результат всё равно получается за менее чем 100мс — ничего оптимизировать не нужно в принципе, человек уже будет воспринимать результат как моментальный. И так далее.
Я занимаюсь настройкой веб-серверов, разработкой и деплоем сайтов. Посмотрите, какой оптимизации добился и гордится мой коллега:
Переведу графики вам на русский язык: занятая оперативная память уменьшилась на целых 100 мегабайт, с нагрузкой на процессор ещё лучше, она стала меньше примерно на 1%.
Внимание, вопрос: сколько серверов и миллионов хитов в сутки должно быть у сайта, чтобы подобная оптимизация была финансово оправдана?
Задача усугубляется ещё и тем, что экосистема WordPress подразумевает Apache
и поддержку .htaccess
. Ранее мы перешли с nginx’а на Apache именно поэтому: если развиваешь сайт на WordPress, сервер nginx объективно нужно поддерживать, апач же будет работать сам. В принципе, разницы никакой: всё равно пхп обрабатывается одним и тем же php-fpm
. Но Апаче
поддерживает .htaccess
, что позволяет использовать заранее настроенные плагины, например для кеширования, и не переживать по поводу верных прав доступа на папки с кешем (true story, ранее на nginx'е это упустили)
.
Я проводил тестирование на маленьких статических файлах: nginx успевает отдать около 8000 файлов в секунду на одном ядре, Apache в этих же условиях отдаёт около 3000 файлов в секунду. Разница в производительности практически в 3 раза.
Но реальность в том, что настоящее приложение упирается вовсе не в сервинг статических файлов. А в процессор по PHP (php-fpm). И даже если включен кеш, и всё будет сервиться из статических файлов, сервер намного скорее упрётся в ограничение по bandwidth
, чем в производительность Apache.
Ну и наконец, финальный штрих: средняя загрузка сервера с сайтом — порядка 1%. Сайт ОЧЕНЬ далеко от того, чтобы начать упираться в какие-либо физические ограничения. Сервер и сайт готовы принимать в десятки, сотни, … раз больше посетителей. Только их нет. Вот над этим надо работать.
Это же правило, кстати, относится не только к IT и программированию.
«Лучшее — враг хорошего».
Закон Парето: 20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата.
Знайте, что вы хотите. Знайте, зачем и ради чего вы это делаете, какой конкретный результат вы хотите получить. Затем, когда находите вменяемый способ получить этот результат — используйте его и двигайтесь дальше. Не пытайтесь найти Идеальный Способ. Лучше вовремя, чем идеально.
Обсуждение
Нечего добавить даже. Не знал чей это закон, всё время думал что это «правило 20 на 80» )
Здравствуйте, Артём. Поговаривают, что есть даже правило 10/90, и даже 5/95 !
Правда, ещё есть известное высказывание ~ «50% денег, которые я трачу на рекламу — не приносят ровно никакого дохода; правда я никогда заранее не знаю, какие именно 50%»

Так что, как минимум, я считаю что нужно не пытаться быть самым умным, и просто Делать.
Проблема в том, что просто делать продукт может быть неинтересно. Почему бы в контексте хобби не помикрооптимизировать? Если занятие нравится, финансы не поджимают — почему бы и нет?
Здравствуйте, Александр.
В данный момент я говорю про достижение цели, про дело, про работу. Если это ваше хобби, то можно хоть крестиком вышивать, я не посмею сказать и слова. Есть например даже целое движение — ребята делают классные программки, чтобы они уместились в как можно меньше строк кода, или например скомпилированный бинарник в 64 килобайта. Соревнуются в этом. Классное и очень требовательное к реальному пониманию происходящего «под капотом компьютера» хобби. Мне нравится demoscene.
А вот когда дело касается работы, за время работника платит работодатель. И тратя оплаченное время на ненужную оптимизацию, работник «крадёт» деньги у владельца. Кроме того, оптимизация производительности приведёт к усложнению понимания кода для человека, а это значит вырастут риски и стоимость поддержки кода на будущее. То есть наш работник «украдёт» не только столько часов, сколько он потратит на оптимизацию, но и намного больше часов на будущую поддержку / исправление / доработку кода. Особенно если в будущем кому-то другому придётся работать с этим куском.
Да и в принципе, любое изменение кода может его сломать. Работает — не трогай. Классика же.