Найти в Дзене
PHP Боярин

Семь раз отмерь, один раз выкинь и перепиши заново

Смешная история о программистах заключается в том, что программист весь день сидит перед монитором, пыхтит, шевелит пальцами как будто ударно работает. А когда вечером встает, в продукте внешне ничего не изменилось.

На вопрос о том, чем же он занимался целый день, он искренне недоумевает: вот же, он здесь оптимизировал, здесь исправил баг, здесь сделал рефакторинг.

Налицо фундаментальное непонимание между работником и бизнесом.

Многие далекие от темы руководители пытаются избавиться от айтишников под предлогом того, что они ничего не делают. Особенно забавно это смотрится с админами локальных сетей, которые должны получать зарплату как раз за то, что все работает как часы и делать ничего не надо.

Когда Василий Нутромчуев на коленке делает сайт по ставке 300 рублей/час, вроде все понятно: вот он сайт, вот они деньги за сайт. Продукт, как говорится, налицо.

А когда Иван Оптимизаторов говорит, что возьмется за 5000 рублей в час этот сайт оптимизировать, бизнес искренне недоумевает, за что же надо платить такие деньги.

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

Так или иначе, оптимизация всегда требует наличия самого предмета оптимизации. Мы можем оптимизировать, например, среднюю скорость загрузки страницы, её объем, или вообще нам на это наплевать, но мы хотим сократить потребление системных ресурсов (таких как загрузка диска или потребление памяти).

Улучшить можно только то, что можно измерить!

Разумеется, опытный разработчик имеет представление о том, что хорошо, а что плохо. Что будет работать быстро, а что медленно.

Но, во-первых, никто не идеален. Во-вторых, оптимизация это область многочисленных тонкостей.

Таким образом, системная работа по оптимизации всегда должна начинаться с определения метрик, которыми мы оцениваем текущее состояние системы. Разумно начать с базового набора:

  • Среднее время отклика (с серверной стороны)
  • Потребление памяти
  • Потребление процессора
  • Размер кеша
  • Процент попадания в кеше (это процент запросов, результат которых мы достаем из кеша, вместо того, чтобы производить работу)
  • И так далее

Также очень разумно было бы оценить метрики, относящиеся к бизнесу непосредственно:

  • средняя стоимость лида (затраты на одну покупку)
  • процент конверсии траффика в цели на разных этапах (переход по рекламе, добавление товара в корзину, покупка и т.д.)

Все это было бы правильно представить в той форме, которая понятна владельцу бизнеса. А именно - в форме графиков.

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

Но что такое быстрый сайт?

Для себя я использую формулу "0.1-1-10". Это означает, что:

  • время на обработку страницы на сервере должно быть не более 0.1 секунды
  • время реакции в браузере клиента - не более 1 секунды
  • страница, которая грузится больше 10 секунд, тупо никому не нужна

Экономия системных ресурсов (например, памяти), не всегда приводит именно к ускорению работы сайта. Зато она может понизить требовательность к железу. А это означает сервер подешевле - экономия. А где экономия - там хорошо, потому что для бизнеса сэкономленные 1000 рублей в месяц это заработанные 1000 рублей в месяц.

Экономия памяти от изменения системы хранения кеша
Экономия памяти от изменения системы хранения кеша

Никто не будет платить за то, что сайт "оптимизирован". Но конкретный, измеримый результат, которым можно ткнуть в морду и сказать: "вот здесь мы экономим вам 100500 рублей", - совсем другое дело.

Опять же, в моей практике бывали случаи, когда оптимизированный код из-за каких-либо эффектов второго порядка работал медленнее, чем старый! Поэтому метрики важны и для самого разработчика.

Кстати, кроме метрик скорости и потребления ресурсов, важны и метрики, связанные с ошибками. Как правило, есть неизбежные статистические факторы, из-за которых программа не может доработать до конца. На больших объемах траффика становятся важны и периодические отказы жестких дисков, и ошибки памяти, и прочая ерунда, которой на маленьком проекте можно пренебречь.

Но когда у тебя 1 миллион серверов, в каждом из которых по 4 диска, чисто статистически менять придется несколько сотен в день. И вот тогда метрика ошибок станет важна. Я упоминал об этом в тексте "Как правильно ошибаться". Такого рода метрики позволяют держать ошибки в узде.

Я еще немного погружусь в область нюансов: важно оценивать не просто среднюю скорость ответа сервера. Если 95% запросов обрабатываются быстро, а 5% очень долго, то в среднем ситуация не так уж плоха. Но для человека, посетившего десяток страниц, это означает высокую долю вероятности встретить на сайте задержку. Подсознательно посетитель сделает себе отметку о том, что сайт "тормозит". И таких тонкостей очень много.

Итак. Работа оптимизатора сайта заключается не в том, чтобы, исходя из собственного ощущения, что-то внутри сайта переделывать. Нет!

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

Всего доброго и хорошего настроения!
Всего доброго и хорошего настроения!

А Нутромчуевым - спасибо, всего доброго и хорошего настроения. Если бы все кругом были идеальны, не было бы и вакансий для оптимизации сайтов.