Производительность – это мир, который всегда находится в сознании всех разработчиков и инженеров. Многие вещи, используемые среди инструментов, библиотек, фреймворков и методов, обладают хорошей производительностью, что является одной из причин их успеха. Не только производительность при разработке, сборке и развертывании, но, что наиболее важно, производительность, воспринимаемая клиентом. Это был урок, который я усвоил на этой неделе. Я подсознательно осознавал этот факт, но видеть, как это происходит в первый раз, было опытом, который я никогда не забуду отныне.
История очень проста, в моей компании мы разрабатываем веб-приложение с использованием Spring Boot 2.0, а также изучаем, как работает Spring Framework, это был процесс обучения от JAX-RS и чистой Java EE до Spring Boot 2.0, что облегчает многое, но вам все равно нужно знать, как Spring Boot может вам помочь. Это было здорово, хотя мы совершаем ошибки и вынуждены что-то переделывать. Именно в один из таких моментов и пришел урок.
Проект уже почти заканчивается, и мы находимся в финальных тестах, тем не менее, клиент почувствовал некоторую медлительность при загрузке сайта. Честно говоря, по моим меркам, это было не так уж медленно, другие сайты с аналогичной целью работали аналогично или даже хуже. Несмотря на это, я принял вызов, чтобы исследовать и решить проблему, улучшив производительность. Разработчики Google Chrome пришли на помощь, чтобы сначала проанализировать его производительность.
Сначала я использовал Lighthouse для аудита сайта, и у меня появились некоторые идеи о том, где производительность была низкой. Там я обнаружил, что основной причиной низкой производительности была загрузка ресурсов: CSS и JS, в основном. Ответ сервера был очень быстрым, но загрузка страницы занимала слишком много времени. На вкладке “Сеть” вы можете увидеть распределение времени для каждого ресурса и все, что подтверждается тем, что предложил Lighthouse. Поэтому я зашел в код, чтобы увидеть две вещи:
- Сокращать ресурсы
- Ресурсы кэша
Моим приоритетом как бэкэнд-разработчика было сначала ознакомиться с политикой кэширования ресурсов. В то время их не было, я признаю, что это была моя ошибка и ошибка команды, но теперь, когда мы знали проблему, было лучше решить ее так, как она должна быть решена. Я начал исследовать, как Spring решает эту проблему, и еще раз понял, насколько хорош этот фреймворк.
Spring Framework имеет множество различных функций для решения этой проблемы, начиная с самого кэша, например, автоматического добавления соответствующих заголовков ко всем ресурсам и заканчивая управлением версиями всех ресурсов. Одна статья, которая была очень полезной, была написана Baeldung , но это для чистого фреймворка Spring, и хотя это в основном одно и то же, иногда вам нужно перевести его на способ загрузки Spring, иначе могут возникнуть некоторые ошибки. Когда вы видите, что все слишком сложно, вы, вероятно, делаете это неправильно. К сожалению, я не помню всех деталей, которые привели меня к решению, идея текста у меня появилась после события, но окончательная конфигурация выглядит следующим образом:
spring.resources.cache.cachecontrol.max-age=365d spring.resources.chain.strategy.content.enabled=true spring.resources.chain.strategy.content.paths=/**
Первой ссылкой для приложения Spring Boot являются доступные свойства приложения . В первой строке указывается время, в течение которого ресурс будет кэшироваться, в данном случае 365 дней. Вторая строка включает стратегию управления версиями контента, которая в основном добавляет хэш файла к имени всех ресурсов в HTML. В последней строке указаны пути, по которым будет применено управление версиями, и это все.
После этого вы должны указать, какие URL-адреса необходимы для управления версиями. Возможно, есть более автоматический способ сделать это, но это было решение, которое я нашел, если вы знаете лучший способ, пожалуйста, прокомментируйте. Во-первых, по совету контроллера я внедряю экземпляр ResourceUrlProvider , который отвечает за создание нового URL-адреса для каждого ресурса.
@ModelAttribute("urls")
public ResourceUrlProvider urls() {
return this.resourceUrlProvider;
}
После этого вам просто нужно использовать метод get для поиска пути() метод класса по URL-адресам. Он проверит, что это ресурс, выполнит хэш и добавит к имени файла. Если файлы изменятся, его хэш вы меняете, заставляя браузер перезагружать его.
">
Это была дневная работа, которая изменила то, как клиент и менеджер воспринимали производительность приложения. Время загрузки сократилось примерно с 10 секунд до 2 секунд максимум или даже быстрее, в зависимости от страницы. Я думаю, что меня никогда так не хвалили, вот в чем урок. Всегда хорошо показать результат вашего развития так, чтобы он был понятен клиенту и руководству. Для бэкэнд-разработчика это не всегда легко, и в основном речь идет о производительности. Поэтому всегда ищите способы улучшить свою производительность. Это непросто, многие решения в Интернете самые простые, но не всегда лучшие, поэтому старайтесь быть критичными, измеряйте производительность, смотрите, есть ли способ улучшить еще больше.
После этого события я усилил свою заботу о производительности. Я надеюсь, что с этого момента смогу продолжать совершенствоваться подобным образом.:)
Оригинал: “https://dev.to/leoat12/lessons-learned-about-performance-115b”