[Высокая производительность, Java, Микросервисы] Улучшаем производительность Java-микросервиса парой простых приемов (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр. Для будущих студентов курса "Highload Architect" подготовили перевод материала.
Также приглашаем на открытый вебинар по теме «Репликация как паттерн горизонтального масштабирования хранилищ». На занятии участники вместе с экспертом разберут репликацию — одну из техник масштабирования баз данных, обсудят смысл и ее назначение, рассмотрят преимущества и недостатки различных видов репликации.
Микросервисы на Java замечательны тем, что с помощью них можно создавать большие и сложные системы из множества независимых компонент. Вместо одного приложения получается несколько мини-приложений или сервисов. Компоненты могут тестироваться, развертываться и обслуживаться независимо друг от друга. Так что, если убрать один кирпич, то здание не разрушится полностью.Тем не менее очевидное преимущество микросервисов может стать и причиной возникновения проблем. Если раньше вы уже работали с микросервисами на Java, то знаете, что для получения высокой производительности без потери функциональности могут потребоваться усилия. Но если вы справитесь с этим, то получите потрясающие результаты.Spring Boot — это быстрый способ создания микросервисов на Java. В этой статье мы рассмотрим, как улучшить производительность Spring Boot-микросервиса.Что будем использоватьМы будем использовать два микросервиса:
- External-service (внешний сервис): "реальный" микросервис, доступный по HTTP.
- Facade-service (фасад): микросервис, который будет читать данные из external-service и отправлять результат клиентам. Будем оптимизировать этот сервис.
Что нам нужно
- Java 8
- Jmeter 5.3
- Java IDE
- Gradle 6.6.1
Исходный кодПрежде всего, скачайте исходный код, который мы будем улучшать, отсюда.External serviceСервис был создан с помощью Spring Initializer. В нем один контроллер, имитирующий нагрузку:
@RestController
public class ExternalController {
@GetMapping(“/external-data/{time}”)
public ExternalData getData(@PathVariable Long time){
try {
Thread.sleep(time);
} catch (InterruptedException e) {
// do nothing
}
return new ExternalData(time);
}
}
Запустите ExternalServiceApplication. Сервис должен быть доступен по адресу https://localhost:8543/external-data/300 . Facade serviceЭтот сервис также был создан с помощью Spring Initializer. В нем два основных класса: ExternalService и ExternalServiceClient.Класс ExternalService читает данные из сервиса External Service с помощью externalServiceClient и вычисляет сумму.
@Service
public class ExternalService {
@Autowired
private ExternalServiceClient externalServiceClient;
public ResultData load(List<Long> times) {
Long start = System.currentTimeMillis();
LongSummaryStatistics statistics = times
.parallelStream()
.map(time -> externalServiceClient.load(time).getTime())
.collect(Collectors.summarizingLong(Long::longValue));
Long end = System.currentTimeMillis();
return new ResultData(statistics, (end — start));
}
}
Для чтения данных из external service класс ExternalServiceClient использует библиотеку openfeign. Реализация HTTP-клиента на основе OKHttp выглядит следующим образом:
@FeignClient(
name = “external-service”,
url = “${external-service.url}”,
configuration = ServiceConfiguration.class)
public interface ExternalServiceClient {
@RequestMapping(
method = RequestMethod.GET,
value = “/external- data/{time}”,
consumes = “application/json”)
Data load(@PathVariable(“time”) Long time);
}
Запустите класс FacadeServiceApplication и перейдите на http://localhost:8080/data/1,500,920,20000.Ответ будет следующим:
{
“statistics”: {
“count”: 4,
“sum”: 1621,
“min”: 1,
“max”: 920,
“average”: 405.25
},
“spentTime”: 1183
}
Подготовка к тестированию производительностиЗапустите Jmeter 5.3.1 и откройте файл perfomance-testing.jmx в корне проекта.Конфигурация теста:
Нагрузочный тест будем проводить по следующему URL-адресу: http://localhost:8080/data/1,500,920,200 Перейдите в Jmeter и запустите тест.Первый запуск Jmeter
Сервер стал недоступен. Это связано с тем, что в ExternalService мы использовали parallelStream(). Stream API для параллельной обработки данных использует ForkJoinPool. А по умолчанию параллелизм ForkJoinPool рассчитывается на основе количества доступных процессоров. В моем случае их три. Для операций ввода-вывода это узкое место. Итак, давайте увеличим параллелизм ForkJoinPool до 1000.
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1000
И запустим Jmeter еще раз.Второй запуск Jmeter
Как вы видите, пропускная способность (throughput) увеличилась с 6 до 26 запросов в секунду. Это хороший результат. Кроме того, сервис работает стабильно без ошибок. Но тем не менее среднее время (average time) составляет 9 секунд. У меня есть предположение, что это связано с затратами на создание HTTP-соединение. Давайте добавим пул соединений:
@Configuration
public class ServiceConfiguration {
…
@Bean
public OkHttpClient client()
throws IOException, CertificateException, NoSuchAlgorithmException, KeyStoreException, KeyManagementException, NoSuchProviderException {
…
okhttp3.OkHttpClient client = new okhttp3.OkHttpClient.Builder()
.sslSocketFactory(sslContext.getSocketFactory(), trustManager)
.hostnameVerifier((s, sslSession) -> true)
.connectionPool(new ConnectionPool(2000, 10, TimeUnit.SECONDS))
.build();
OkHttpClient okHttpClient = new OkHttpClient(client);
return okHttpClient;
}
Таким образом, приложение может поддерживать до 2000 HTTP-соединений в пуле в течение 10 секунд.Третий запуск Jmeter
Пропускная способность улучшилась почти в три раза: с 26 до 71 запросов в секунду.В целом пропускная способность улучшилась в 10 раз: с 6 до 71 запросов / сек, но мы видим, что максимальное время запроса (maximum time) составляет 7 секунд. Это много и влияет как на общую производительность, так и на задержку в UI.Поэтому давайте ограничим количество обрабатываемых запросов. Сделать это можно, используя указанные ниже свойства Tomcat в application.properties:
server.tomcat.accept-count=80
server.tomcat.max-connections=80
server.tomcat.max-threads=160
Приложение будет отклонять запросы на подключение и отвечать ошибкой "Connection refused" (отказ соединения) всем клиентам, как только количество подключений достигнет 160.Четвертый запуск Jmeter
Теперь максимальное время составляет меньше пяти секунд и число запросов увеличилось с 71 до 94 запросов в секунду. Процент ошибок ожидаемо увеличился до 29%. Это все ошибки "Connection refused". ЗаключениеВ этой статье мы продемонстрировали реальный сценарий повышения производительности в 15 раз с 6 до 94 запросов / сек без каких-либо сложных изменений кода. Кроме того, упомянутые выше шаги позволяют снизить стоимость инфраструктуры, такой как AWS. Возможно, для вашего следующего проекта вам стоит подумать об использовании микросервисов. Хотя одна из тенденций последних лет — переход к бессерверной архитектуре, но вы должны всё взвесить при переходе к такой архитектуре.Мы рассмотрели общий подход к улучшению производительности Java-приложений, который вы можете использовать на практике. Однако в статье не рассматриваются некоторые специфичные случаи, такие как работа с базами данных. В мире Java-микросервисов есть еще много места для открытий и экспериментов.
Узнать подробнее о курсе "Highload Architect".Смотреть открытый вебинар по теме «Репликация как паттерн горизонтального масштабирования хранилищ».
===========
Источник:
habr.com
===========
===========
Автор оригинала: Vitaliy Havryk
===========Похожие новости:
- [DevOps, Kubernetes] Job’ы и Cronjob’ы Kubernetes (перевод)
- [Системное администрирование, IT-инфраструктура, Amazon Web Services, Облачные сервисы] Почему в AWS все так сложно с прайсом и правами? Как избежать «политических» блокировок и защитить данные в облаке?
- [Java, Профессиональная литература] Книга «Эффективный Java. Тюнинг кода на Java 8, 11 и дальше. 2-е межд. издание »
- [Микросервисы, Serverless] Платформа Netflix Cosmos (перевод)
- [Разработка веб-сайтов, JavaScript, Проектирование и рефакторинг, ReactJS] Вариант повторного использования кода компонентов, который упустили в веб-разработке
- [Разработка веб-сайтов, JavaScript, TypeScript] Exports в package.json
- [Ajax, PHP, JavaScript, CRM-системы] Обзор разработки дополнений для amoCRM, с использованием webHook и виджетов
- [JavaScript, API, Rust, Микросервисы] GraphQL на Rust (перевод)
- [Программирование, Java] Поддержка Null в Protobuf (перевод)
- [JavaScript, Программирование] Программная генерация изображений с помощью API CSS Painting (перевод)
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_java, #_mikroservisy (Микросервисы), #_mikroservisy (микросервисы), #_javascript, #_aws, #_coding, #_highload, #_replikatsija (репликация), #_blog_kompanii_otus (
Блог компании OTUS
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_java, #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:03
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, Хабр. Для будущих студентов курса "Highload Architect" подготовили перевод материала.
Также приглашаем на открытый вебинар по теме «Репликация как паттерн горизонтального масштабирования хранилищ». На занятии участники вместе с экспертом разберут репликацию — одну из техник масштабирования баз данных, обсудят смысл и ее назначение, рассмотрят преимущества и недостатки различных видов репликации.  Микросервисы на Java замечательны тем, что с помощью них можно создавать большие и сложные системы из множества независимых компонент. Вместо одного приложения получается несколько мини-приложений или сервисов. Компоненты могут тестироваться, развертываться и обслуживаться независимо друг от друга. Так что, если убрать один кирпич, то здание не разрушится полностью.Тем не менее очевидное преимущество микросервисов может стать и причиной возникновения проблем. Если раньше вы уже работали с микросервисами на Java, то знаете, что для получения высокой производительности без потери функциональности могут потребоваться усилия. Но если вы справитесь с этим, то получите потрясающие результаты.Spring Boot — это быстрый способ создания микросервисов на Java. В этой статье мы рассмотрим, как улучшить производительность Spring Boot-микросервиса.Что будем использоватьМы будем использовать два микросервиса:
@RestController
public class ExternalController { @GetMapping(“/external-data/{time}”) public ExternalData getData(@PathVariable Long time){ try { Thread.sleep(time); } catch (InterruptedException e) { // do nothing } return new ExternalData(time); } } @Service
public class ExternalService { @Autowired private ExternalServiceClient externalServiceClient; public ResultData load(List<Long> times) { Long start = System.currentTimeMillis(); LongSummaryStatistics statistics = times .parallelStream() .map(time -> externalServiceClient.load(time).getTime()) .collect(Collectors.summarizingLong(Long::longValue)); Long end = System.currentTimeMillis(); return new ResultData(statistics, (end — start)); } } @FeignClient(
name = “external-service”, url = “${external-service.url}”, configuration = ServiceConfiguration.class) public interface ExternalServiceClient { @RequestMapping( method = RequestMethod.GET, value = “/external- data/{time}”, consumes = “application/json”) Data load(@PathVariable(“time”) Long time); } {
“statistics”: { “count”: 4, “sum”: 1621, “min”: 1, “max”: 920, “average”: 405.25 }, “spentTime”: 1183 }  Нагрузочный тест будем проводить по следующему URL-адресу: http://localhost:8080/data/1,500,920,200 Перейдите в Jmeter и запустите тест.Первый запуск Jmeter  Сервер стал недоступен. Это связано с тем, что в ExternalService мы использовали parallelStream(). Stream API для параллельной обработки данных использует ForkJoinPool. А по умолчанию параллелизм ForkJoinPool рассчитывается на основе количества доступных процессоров. В моем случае их три. Для операций ввода-вывода это узкое место. Итак, давайте увеличим параллелизм ForkJoinPool до 1000. -Djava.util.concurrent.ForkJoinPool.common.parallelism=1000
 Как вы видите, пропускная способность (throughput) увеличилась с 6 до 26 запросов в секунду. Это хороший результат. Кроме того, сервис работает стабильно без ошибок. Но тем не менее среднее время (average time) составляет 9 секунд. У меня есть предположение, что это связано с затратами на создание HTTP-соединение. Давайте добавим пул соединений: @Configuration
public class ServiceConfiguration { … @Bean public OkHttpClient client() throws IOException, CertificateException, NoSuchAlgorithmException, KeyStoreException, KeyManagementException, NoSuchProviderException { … okhttp3.OkHttpClient client = new okhttp3.OkHttpClient.Builder() .sslSocketFactory(sslContext.getSocketFactory(), trustManager) .hostnameVerifier((s, sslSession) -> true) .connectionPool(new ConnectionPool(2000, 10, TimeUnit.SECONDS)) .build(); OkHttpClient okHttpClient = new OkHttpClient(client); return okHttpClient; }  Пропускная способность улучшилась почти в три раза: с 26 до 71 запросов в секунду.В целом пропускная способность улучшилась в 10 раз: с 6 до 71 запросов / сек, но мы видим, что максимальное время запроса (maximum time) составляет 7 секунд. Это много и влияет как на общую производительность, так и на задержку в UI.Поэтому давайте ограничим количество обрабатываемых запросов. Сделать это можно, используя указанные ниже свойства Tomcat в application.properties: server.tomcat.accept-count=80
server.tomcat.max-connections=80 server.tomcat.max-threads=160  Теперь максимальное время составляет меньше пяти секунд и число запросов увеличилось с 71 до 94 запросов в секунду. Процент ошибок ожидаемо увеличился до 29%. Это все ошибки "Connection refused". ЗаключениеВ этой статье мы продемонстрировали реальный сценарий повышения производительности в 15 раз с 6 до 94 запросов / сек без каких-либо сложных изменений кода. Кроме того, упомянутые выше шаги позволяют снизить стоимость инфраструктуры, такой как AWS. Возможно, для вашего следующего проекта вам стоит подумать об использовании микросервисов. Хотя одна из тенденций последних лет — переход к бессерверной архитектуре, но вы должны всё взвесить при переходе к такой архитектуре.Мы рассмотрели общий подход к улучшению производительности Java-приложений, который вы можете использовать на практике. Однако в статье не рассматриваются некоторые специфичные случаи, такие как работа с базами данных. В мире Java-микросервисов есть еще много места для открытий и экспериментов. Узнать подробнее о курсе "Highload Architect".Смотреть открытый вебинар по теме «Репликация как паттерн горизонтального масштабирования хранилищ».
=========== Источник: habr.com =========== =========== Автор оригинала: Vitaliy Havryk ===========Похожие новости:
Блог компании OTUS ), #_vysokaja_proizvoditelnost ( Высокая производительность ), #_java, #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:03
Часовой пояс: UTC + 5