Тузиков Александр, ИТМО DWS, Stage 5 #170
Conversation
# Conflicts: # src/main/java/ru/vk/itmo/test/tuzikovalexandr/Server.java # src/main/java/ru/vk/itmo/test/tuzikovalexandr/ServerImpl.java # src/main/java/ru/vk/itmo/test/tuzikovalexandr/ServiceImpl.java
![codeclimate[bot]](https://avatars.githubusercontent.com/in/9403?s=60&v=4){kind=small}
src/main/java/ru/vk/itmo/test/tuzikovalexandr/ConsistentHashing.java
Outdated
Show resolved
Hide resolved
| } else { | ||
| private CompletableFuture<Response> sendProxyRequest(HttpRequest httpRequest) { | ||
| return httpClient.sendAsync(httpRequest, HttpResponse.BodyHandlers.ofByteArray()) | ||
| .thenApplyAsync(this::processingResponse); |
There was a problem hiding this comment.
Да, согласен, что такой способ тоже хорош. Когда делал этап, очень много думал над этим. Что если мы не указываем явно, то тратим ресурсы на создание дефолтных каждый раз. И на лекции говорили, что, вроде, лучше делать пул экзекьюторов и потом отдавать их задачам.
There was a problem hiding this comment.
Но, если пул будет переполнен, то тоже не очень хорошо же получится
There was a problem hiding this comment.
Я про то, что без явного указания Executor непонятно, где исполняются callback'и, а мы точно не хотим исполняться на дефолтном, который используется для других сторонних нужд.
| В остальном ничего другого не заметил. Хотя, как мне казалось, должна была быть аллокация на дефолтный экзекьютор, так | ||
| как сам я их не создавал. Но этого не нашел. |
There was a problem hiding this comment.
Я подходил с этим вопросом после окончания дедлайна. Говорил, что если мы не даем екзекьюторы, то они должны создаваться дефолтные у задачи (как я понял). А этого обнаружить не смогу. Вы мне потом пояснили, что там надо было через флаг смотреть. Что догадка верна моя
There was a problem hiding this comment.
Не смог осознать ответ. Если мы не указываем Executor, то исполняться код может на разных (в т.ч. на дефолтном) в зависимости от готовности CompletableFuture. Аллокация -- это про память, а здесь речь о чём-то другом, видимо?
| 50.000% 19.96s 14.93s | ||
| 75.000% 24.76s 17.96s | ||
| 90.000% 27.25s 23.90s | ||
| 99.000% 28.48s 26.10s | ||
| 99.900% 28.56s 26.33s | ||
| 99.990% 28.57s 26.35s | ||
| 99.999% 28.57s 26.35s | ||
| 100.000% 28.57s 26.35s |
There was a problem hiding this comment.
Секунды нет смысла анализировать. Система явно перегружена.
There was a problem hiding this comment.
В случае с виртуалкой для меня было проблематично определять эти показатели, потому что и на секундах как-то пахало и на этом спасибо
There was a problem hiding this comment.
Но здесь нечего анализировать и сравнивать в режиме перегрузки.
|
|
||
| [get-profile-1th-cpu.html](get-profile-1th-cpu.html) | ||
|
|
||
| Аналогично, как и в случае с PUT запросами. Только немного другие пропорции. |
There was a problem hiding this comment.
Как можно объяснить изменение пропорций? Согласен, что наша система выполняет те же функции, но как объяснить изменение распределения ресурсов?
There was a problem hiding this comment.
Если в контексте с предыдущим этапом, то изменение пропорций произошло из-за появления новых асинхронных операций, ну и соответственно новые сэмплы также появились, как я понимаю.
Также если мы и добавили работы воркерам, именно что работу с фьючерами.
А если говорить именно между get и put, то думаю, что несколько причин может быть. Например, насколько была заполнена база при get запросах, насколько трудоемко они отрабатывали.
There was a problem hiding this comment.
Хотелось бы увидеть больше конкретики по результатам анализа профилей вместо общих рассуждений про future.
|
|
||
| [get-profile-1th-lock.html](get-profile-1th-lock.html) | ||
|
|
||
| Аналогично, как и в случае с PUT запросами. Только немного другие пропорции. |
There was a problem hiding this comment.
Хотелось бы увидеть объяснение изменения пропорций.
There was a problem hiding this comment.
Тут также как и с предыдущим комментарием, все идет вокруг добавления работы с асинхронными задачами. Соответственно и появление новых сэмплов, которые отражают это.
There was a problem hiding this comment.
Нужна конкретика -- что за методы появились, какую работу они выполняют, можно ли её устранить или она обоснована и т.д.
| - При добавлении логики асинхронной работы с CompletableFuture, соответсвенно выросла и трата ресуросв на работу с ними. | ||
| Соответсвенно, самыми показательными были LOCK фреймы. |
There was a problem hiding this comment.
Можно конкретнее, пожалуйста? В чём показательны LOCK фреймы?
There was a problem hiding this comment.
Так как выросло количество блокировок. У сэмплов на 4 этапе в принципе не были видны java/util/concurrent/CompletableFuture$AsyncSupply.run, java/util/concurrent/ThreadPoolExecutor.getTask, jdk/internal/net/http/common/SequentialScheduler$SchedulableTask.run. А на 5 этапе, так как были добавлена работа с асинхронностью, мы видим, какие блокировки срабатывают на ожидание задач, на их получение. Также, что они занимают хоть и не большую, но все равно весомую часть нагрузки
There was a problem hiding this comment.
Это всё достойно попадания в отчёт.
Отчет в директории result/stage5 report.md