Контроллер пружинной загрузки отдыхает довольно медленно - PullRequest
Новая
       7

Контроллер пружинной загрузки отдыхает довольно медленно

0 голосов
/ 05 февраля 2020

Здравствуйте, сообщество переполнения стека. Я использую Spring boot, и он отлично работает для меня, но когда дело доходит до «больших» наборов данных, это становится довольно медленным, позвольте мне показать вам пример кода: 

@GetMapping("/get/some/example/data/{lines}")
public ResponseEntity<String> getTestData(@PathVariable("lines") long lines) {
    StringBuilder stringBuilder = new StringBuilder();

    for(int i=0; i<lines; i++){
      stringBuilder.append("...very long string here...");
    }
    return ResponseEntity.ok(stringBuilder.toString());
  }

Хорошо, что вы видите просто довольно простой контроллер отдыха для генерации динамических ответов размером 1076 *. Представьте, что строка в stringBuilder.append () имеет длину 500 символов и более.

Теперь давайте вызовем эту конечную точку из браузера и просмотрим результат с DevTools (F12) chrome:

Response Заголовки:

Кодировка содержимого: gzip

Тип содержимого: text / html; charset = UTF-8

Кодировка передачи: chunked

варьируется : accept-encoding

Конечная точка вызова для линии = 100:

  • 419 КБ Ресурсы
  • Fini sh 377 мс (+ - 50 мс .. .)

Конечная точка вызова для линии = 1000:

  • 3,0 МБ Ресурсы
  • Фини sh 2108000 мс (+ - 3000 мс)

Давайте сравним эти результаты. ОК, размер ресурса не точен в 10 раз больше из-за сжатия gzip. Но моя проблема - время отклика. Требуется 377 мс и 210800 мсек, что в 10 раз больше данных. Это означает, что на 10 раз больше данных уходит в 559 раз больше времени.

Вы видите, что нет соединения с БД, нет сложного кода вообще. Операция for l oop с 1000 итерациями занимает менее 5 мс, поэтому проблема заключается в самой сцене или в HTTP. Не могли бы вы помочь мне понять, почему большие наборы данных так сильно влияют на производительность. И можете ли вы помочь найти решение для улучшения времени отклика.

Кроме того, вы можете увидеть MIME-тип "Content-Type: text / html" в заголовках, когда это меняется на приложение / json это быстрее, но все же не быстро.

См. Также заголовки запросов здесь: Accept: text / html, application / xhtml + xml, application / xml; q = 0,9, image / webp, image / apng, / ; q = 0,8, приложение / подписанный обмен; v = b3; q = 0,9

Accept-Encoding: gzip, deflate, br

Accept-Language: de-DE, de; q = 0,9, es-VE; q = 0,8, es; q = 0,7, en-US; q = 0,6, en; q = 0,5

Cache -Контроль: без кеша

Соединение: keep-alive

Хост: localhost: 8080

Прагма: без кеша

Se c - Fetch-Mode: навигация

Se c -Fetch-Site: нет

Se c -Fetch-User:? 1

Upgrade-Insecure-Requests: 1

Пользователь-агент: Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537,36 (K HTML, как Gecko)

Chrome / 79.0.3945.130 Safari /537.36

зависимости: 

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.9.RELEASE</version>

<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.0.RELEASE</version>

...

Я очень благодарен за любые подсказки и предложения.

1 Ответ

0 голосов
/ 05 февраля 2020

Я только что понял, что проблем с производительностью нет вообще. Я только что установил Почтальон, чтобы проверить, не там ли он. Нет, Почтальон, а также Firefox DevTools сказали мне, что это довольно быстро. По какой-то причине мой любимый браузер chrome замедлял работу с большими данными. Поверьте мне или нет, один и тот же запрос на firefox и chrome для ответа 14,41 МБ занимает около 223 мс на firefox и на chrome около 23000 мс ...

...