Comments 10
Зачем инженерам тратить время на перформанс
Инженер — личность творческая. Позвольте ему тратить время на перформансы, если от этого не страдает производительность. :)
отклик за 100—300 миллисекунд мы воспринимаем как мгновенный
Знайте, что существуем мы, "инвалиды", которые воспринимают как мгновенный отклик за 50-80 миллисекунд. Половина веба — это мелькающее нечто, когда ты мысленно щелчки отсчитываешь после клика перед тем, как сделать следующий (что бы отработали те самые 300мс).
Если действие не требует аякс запроса, подумайте о том, что бы уложить его в 50мс. Так вы сделаете свой сайт доступным бОльшему количеству людей.
Зачем инженерам тратить время на перформанс
Да чтобы оно, мать его, не тормозило, вот зачем! Потому что не у всех топовые сборки компьютеров и телефоны по пятьдесят тысяч деревянных стоимостью!
Конечно, всех технических подробностей в одной статье не уместить. В этой статье я хотел прежде всего объяснить, зачем нужна культура перформанса в компании, какой профит от неё бизнесу и пользователям. Чуть больше технических деталей, например, про автоматизацию профилирования и поддержание производительности можно узнать из доклада моего коллеги Николая Рябова: youtu.be/u7Ld2AWcB2M
Я поддержу коллегу. Статья написана очень поверхностно, много всего свалено в кучу (и бекенд, и фроненд, и приложения), получился набор умных слов/инструментов, но без конкретики и цифр, без которых говорить о производительности, особенно в распределенных системах, не имеет смысла.
Слово "Перформанс" очень режет слух, мне кажется его вполне можно заменить на "Производительность".
Раздел "Ускорение бэкенда" откровенно слаб. Возможно не стоило Android-инженеру его расписывать:
"Это значит, что при каждом обращении на бэкенд, у нас разворачивается множество микросервисов".
Они действительно "разворачиваются" при каждом запросе (как в FaaS), из статьи по ссылке это вроде бы не так?"Не запрашивать в цикле данные у базы. При внедрении цикла легко забыть про транзакцию. Если исправить такие ошибки, сэкономим ещё немного времени на отклик."
Я так понимаю, что здесь речь про то, что не нужно делать n запросов по каждому id, а делать групповые запросы (IN)? Или что-то еще?
Про забытую транзакцию тоже не очень понятно. Речь про то, что цикл увеличивает общее время выполнения транзакции и тем самым занимает соединение на pgbouncer'е более долгое время, или про что-то другое?"Часто запросы идут не параллельно, а суммируются. Если их разделить, уменьшится общее время запроса. Здесь нужно учесть возможности языка. Например, в PHP такая опция зависит от версии."
Здесь не очень понятно. Имеется в виду последовательное vs параллельное выполнение запросов? При параллельном выполнении тоже полно подводных камней, в том числе и с повышенным потреблением ресурсов и доп. нагрузкой на другие сервисы, которое может перекрыть выигрыш времени выполнения запросов (в т.ч. в денежном эквиваленте). Но опять же без цифр (и метрик) тут говорить не о чем.
Про PHP имелся в виду multi_curl? Он вроде достаточно давно доступен. Или какие-то другие подходы (асинхронщина и пр.)? В любом случае, что мешает самому реализовать логику параллельного выполнения запросов на любой версии языка?- Time To Content и дебаунсы в разделе про бекенд вроде бы выглядят немного неуместно.
В целом у вас в блоге очень много действительно сильных и полезных статей, но иногда проскальзывают очень поверхностные/малополезные статьи (возможно, дежурные или от малоопытных сотрудников), которые омрачают общую картину. Эта статья, к сожалению, на мой взгляд ближе ко второму варианту.
Извините за критику, но мы все так или иначе радеем за качество информации, а не ее количество.
Зачем инженерам тратить время на перформанс