Переоптимизация

Переоптимизация. Болезнь, которой страдают многие неопытные разработчики.

Попробуйте ответить на такой вопрос на засыпку: есть программа, вы провели её профилирование и обнаружили, что одна из функций занимает 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% результата.

Знайте, что вы хотите. Знайте, зачем и ради чего вы это делаете, какой конкретный результат вы хотите получить. Затем, когда находите вменяемый способ получить этот результат — используйте его и двигайтесь дальше. Не пытайтесь найти Идеальный Способ. Лучше вовремя, чем идеально.