#производительность

12 постов
пост №1846

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

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

Технически сейчас это программа на C#, которая в одну сторону торчит админкой для редакции, а в сторону читателей генерирует HTML-страницы сайта. Это популярный сетап из 2000-х. Техническую задачу я формулирую как облегчение процесса разработки без потери производительности сайта.

Дело в том, что в текущем сетапе фронтендер не может нормально верстать страницы без привлечения бэкенда — это мешает быстрому и предсказуемому развитию бизнеса.

Современный фронтенд ушёл далеко вперёд в удобстве разработки; собрать классический отдельный фронтенд для новостного сайта — не велика затея, мы делали это уже много раз.

Но будет ли современное веб-приложение (SPA) так же производительно, как HTML-страницы из 90-х? Речь и о скорости первого открытия — можно ли загрузить JS после полной отрисовки страницы? — и о скорости перехода между страницами — быстрее ли JavaScript-логика, чем отдать готовый HTML с сервера?

Можно ли получить лучшее из обоих миров? На какие компромиссы придётся пойти?

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

Вдохновляюсь я вот этим видео, где инженер разбирает устройство фронтенда магазина строительных и промышленных инструментов McMaster. На первый взгляд может показаться, что это сайт из 90-х, на самом деле там под капотом почти все ускорения современного веба, которые только можно представить. Редкий случай хорошего видео для разработчиков, очень рекомендую.

P. S. Один из разработчиков McMaster пишет, что под капотом там VB.NET, хранимки и XSL-трансформации поверх XML для генерации веб-страниц. Хочется вот всё то же самое, только без VB, хранимок и XSLT. 🙈

пост №1836

Тормозит приложение.

На днях написала топ-менеджер одной ритейл-сети. Тормозит мобильное приложение. Медленно работает поиск, добавление в корзину, оформление заказа. Нажимаешь на кнопку и ждешь…

В ритейле каждая доля секунды задержки — это люди, которые не купили товары, прямые потери. Мобильные разработчики не исправляют ситуацию. Переводят стрелки на бэкендеров, мол это бэкенд тормозит. Как разобраться, на чьей стороне сломалось и починить проблему?

Хорошие разработчики собирают аналитику по производительности своих приложений — какое время занимают ключевые действия типа «открытие главной», «поиск», «добавление в корзину», «оплата». Это называется Real User Monitoring.

Дальше мы кладем эту информацию на график: на оси Х — время, которое занимает действие, на оси Y — количество пользователей. Столбики слева — хорошо. Длинный хвост справа — это несчастные, у них, например, экран оплаты грузится минуту! Эти люди поменяют приложение, если у них будет выбор!

Но это средние значения. Что, если приложение хорошо работает 23 часа в сутки, а по вечерам, в час-пик, в самое важное время, начинает тормозить?

Тут поможет другой классический график: на оси Х — время (вчера, сегодня в течении дня, завтра), на оси Y — время ответа (задержка, latency). Три черты — среднее время, медиана и 95 персентиль. То есть за сколько миллисекунд происходит оплата в среднем, у медианы и за какое время происходит оплата у 95% быстрых пользователей? Он помогает отследить, нет ли тормозов в определенное время суток или в день недели.

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

Итак, шаг первый — замерить экраны и действия.

Теперь можно переходить к поиску первопричины. Приложение может тормозить само по себе или из-за медленного бэкенда.

Тут мы опираемся на те же два графика, но уже смотрим скорость ответа бэкенда.

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

Хотите заказать классную разработку или аудит? Обращайтесь! @samatg https://fansdev.ru

пост №1699

«Худший программист, которого я знаю». История о чуваке, который не закрывал сам задачи, но помогал начинающим программистам разобраться в проекте и не наломать дров, а для опытных, был полноценным партнером; существенно увеличивал производительность всей команды. Такие люди встречаются даже реже, чем «10× программисты».

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

пост №1272

GTA V — финансово самый успешный продукт в истории развлечений. Эту игру купили больше 90 миллионов копий, она заработала 6 миллиардов долларов. Для сравнения: «Звездные войны» собрали 4 миллиарда, самый успешный фильм в истории «Аватар» — 2.8 миллиарда.

GTA Online — версия игры, в которую можно играть с друзьями онлайн. Эта игра очень долго грузится. Вполне возможно, что многие отказались от игры именно из-за медленной загрузки.

Чувак нашел ошибку в программе и смог уменьшить время загрузки с 6 минут до 2 минут. Причем сделал это не имея исходных кодов, то есть во многом «вслепую! Вот очень короткая и классная статья, где он рассказывает, как нашел проблему и как её починил.

Почему такая жесть пролезла в продакшен супер успешного проекта, мы вряд ли узнаем, но все технари с опытом представят легко: сжатые сроки, «вас не спрашивали, делайте что скажут» и прочие «прелести» промышленной разработки софта. 😢

пост №1036

Похвастаюсь: ко мне на работу в Pure пришел бэкендер Антон Шурашов и начал приводить бэкенд Pure в чувство.

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

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

Спасибо всем, кто откликнулся на вакансию. Познакомились с несколькими интересными специалистами, надеюсь ещё поработаем вместе. 🍒

пост №860

Многие пишут, рекомендуют sitespeed.io. Спасибо большое! Это качественно и красиво упакованный пакет для автоматизированного тестирования и мониторинга производительности, добавил в список. Ну и лендинг у них классный!

пост №779

Что-то я всё про индустрию и совсем мало про технологии. Интересная статья про то, как The Outline (очень модное медиа) программируют свой сайт на Elixir. Вкратце — никаких фронтенд-фреймворков, генерируют html в Phoenix шаблонах, где нужно — пишут руками чуть-чуть джаваскрипта (для комментариев, например) и включают turbolinks. Страницы отдаются менее чем за 90 миллисекунд, за счет этого не нужен никакой CDN, можно делать динамический контент на каждого пользователя.

Вот такие технари нужны в медиа. Шебутные, желающие пробовать новое и при этом делающие реальный продукт, а не витающие в облаках.

Прям чувствуется воздух свободы в этой статье.

пост №687

Долг совести я выполнил, теперь можно о приятном.

Установил вчера первую бету iOS 12 для разработчиков и не нашёл пока ни одного серьёзного глюка.

У меня на iPhone SE (маленькие руки) некоторые вещи раньше работали медленно. В iOS 12 все происходит мгновенно. Это магия какая-то. Конечно, без уменьшения задержек анимации не обошлось, но и объективные тормоза интерфейсов они убрали.

Обратите внимание и не стесняйтесь давать разработке время на рефакторинг и улучшение штук под капотом. Главное, чтобы команда могла внятно объяснить, какой профит принесет каждое изменение, а не «код ради кода».

Мы в RAWG (4 разработчика, два бэка и два фронта), например, за прошлые две недели серьёзно прокачали фронтенд сайта, который до этого делался год:

- у нас большая главная и теперь мы грузим только первые её два экрана, все остальное - по доскроллу. Первое открытие стало на порядок быстрее;
- починили дико бесящее поведение, которое часто встречается на реакт-сайтах, когда при открытии игры с главной, на секунду отображаясь прошлая открытия игра (страница рендерила стейт из кеша). Теперь мы сразу показываем новое называние игры (оно всегда есть в ссылке), пока грузим остальные данные и это ощущается в сто раз быстрее, чем было раньше:
- перенесли все картинки в CDN и воткнули перед сайтом Cloudflare (вот вот включим Railgun), чтобы сайт открывался быстрее у азиатов и американцев.

Вообщем, мы собрали «низковисящие фрукты» и начинаем делать параллельно три (!) крупные задачи:

- AMP - чтобы из результатов поиска игры открывались мгновенно. Хитрость в том, чтобы поженить AMP с существующим сайтом на реакте: не переписывать все заново и не закопаться потом в поддержке;
- SEO - хотим быть первыми по «низкочастотным играм»;
- оптимизация «выбросов» времени ответа API (django) - отдельная большая история, которой мы обязательно поделимся.

Ура рефакторингу.

пост №269

Алексей Иванов из Dropbox (ex-Yandex) опубликовал просто титаническую статью про оптимизацию веб-сервера — текстовую версию своего вчерашнего доклада с NginxConf 2017 (видео пока нет).

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

Во первых, это отличный чеклист по оптимизации.

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

Я легко могу себе представить, как выходит книга в серии животных O'Reilly, написанная на основе этой статьи.

https://blogs.dropbox.com/tech/2017/09/optimizing-web-servers-for-high-throughput-and-low-latency/

P.S. Обратите внимание на кнопку "We're hiring", ненавязчиво висящую в левом верхнем углу на протяжении всей статьи и последний абзац — вот это job marketing, который я уважаю.

пост №250

Раньше сайт Медузы грузил шрифты так, что текст прыгал на доли секунд при загрузке страницы. Это было нежелательным побочным эффектом оптимизации сайта для мобильных читателей, которые попали на Медузу впервые. «Прыжки» подбешивали внимательную аудиторию в десктопе.

Мы переработали схему. Теперь, при первом открытии сайта показываются системные шрифты, а при всех следующих заходах — наши. Без каких-либо дерганий.

Оптимизация веба для скорости — бесконечно большая и интересная тема. Мы пока выбираем 80% процентов профита, достигаемые первыми 20% труда.