Немного об оптимизации веб-сайтов. часть 1.

Большую часть работы я трачу на поддержку и развитие уже написанных сайтов. Немалую долю времени при поддержке приходится тратить на оптимизацию. Именное ей и будет посвящен набор статей виде отдельных историй об одном абстрактном программисте.

Этап 1 - становление.

Опыт 1.

Начинающий веб программист получает заказ на небольшой сайт. На удивление сайт завершен за 2 недели до сроков, даже с учетом затребованных изменений. Программист понимает что код его далек от идеала, многие вещи реализованы не оптимально. Принято решение заняться оптимизацией сайта. Сказал - сделал. Время генерации сайта до оптимизации 0.02 секунды, время генерации сайта после оптимизации 0.015 секунды. Т.е. страница генерируется на 25% быстрее. Итак по мнению программиста сайт обслужит на 25% больше пользователей.

Проверка.

Пусть следующий скрипт эмулирует сайт до оптимизации.


$echo “<?php usleep(20000);” > /var/www/site_before.php


А следующий после:


$echo “<?php usleep(15000);?>” > /var/www/site_after.php


Запускаем проверку.


$ ab -q -n 1000 -c 150 http://127.0.0.1/site_before.php | grep "Requests per second"
Requests per second: 64, 3[#/sec] (mean) (усреднено по трем замерам)


$ ab -q -n 1000 -c 150 http://127.0.0.1/site_after.php | grep "Requests per second"
Requests per second: 64 [#/sec] (mean) (усреднено по трем замерам)


Результат.

Прироста в 25% нет. Есть падение производительности в рамках погрешности.

Предположение.

При фиксированных параметрах веб серверва и физических ресурсах сервера есть некое пороговое значение времени выполнения процесса ниже которого оптимизация теряет смысл.

Подтверждение


$echo “<?php ” > /var/www/site_null.php
$ ab -q -n 1000 -c 150 http://127.0.0.1/site_null.php | grep "Requests per second"
Requests per second: 67 [#/sec] (mean) (усреднено по трем замерам)


Т.е. даже если убрать весь код из нашего проекта мы получим лишь 4% прирост производительности вебсервера.

Объяснение.

Пороговая производительность веб сервера при выполнении какой либо задачи напрямую связана с типом задачи. В нашем примере скорее всего значительную часть времени было потрачено на запуск интерпретатора, что составляло настолько большую долю в процессе отдачи страницы, что временем выполнения скрипта вообще можно было пренебречь.

Резюме.

При выполнении оптимизации вы должны быть четко уверены в том что она нужна.
Перед оптимизацией кода будьте уверены что проблема именно в нем. Есть много способов оптимизации сайта, которые не затрагивают исходные коды.

Мое мнение.

Вообще вывод тривиален, да, согласен. Но я склонен считать что этой ошибке подвержены все начинающие веб программисты. В целом нет ничего плохого в том, что делал наш абстрактный программист, он изучал возможности языка и это очень полезное качество. Вопрос тут в другом. Нужно правильно расставлять акценты. Не нужно подменять понятия. В своей жизни я видел задержки проектов по срокам, из-за подобной деятельности, при этом человек занявшись "оптимизацией" (на самом деле просто игрался), начинал сам верить что оптимизирует сайт и даже обижался когда ему указывали на срыв сроков. И начинал заговариваться утверждая, что его действия необходимы для поддержки и развития проекта. Начинающий программист должен понимать, что если он занимается оптимизацией, а никаких оснований для этого нет, то он просто изучает язык, приемы, но никак не улучшает конечный продукт.