hw2

Author: PetyaVasya

src/main/java/ru/vk/itmo/test/kovalevigor/reports/scripts/lua/get_request.lua

@@ -1,5 +1,38 @@
+local threads = {}
+
+function setup(thread)
+   table.insert(threads, thread)
+end
+
+function init(args)
+   count_404 = 0
+   count_503 = 0
+end
+
 function request()
-     key = math.random(1000000)
+     key = math.random(1750000)
 
      return wrk.format("GET", "/v0/entity?id=k" .. key)
  end
+
+function response(status, headers, body)
+    local nstatus = tonumber(status)
+    if nstatus == 404 then count_404 = count_404 + 1
+    elseif nstatus == 503 then count_503 = count_503 + 1
+    end
+end
+
+function done(summary, latency, requests)
+   total_404 = 0
+   total_503 = 0
+
+   for index, thread in ipairs(threads) do
+      total_404 = total_404 + thread:get("count_404")
+      total_503 = total_503 + thread:get("count_503")
+   end
+
+   print("------------------------------\n")
+   local msg_status = "HTTP Status %s Count: %d"
+   print(msg_status:format("404", total_404))
+   print(msg_status:format("503", total_503))
+end

src/main/java/ru/vk/itmo/test/kovalevigor/reports/scripts/lua/put_request.lua

@@ -1,5 +1,5 @@
 function request()
-     key = math.random(1000000)
+     key = math.random(1750000)
      value = ""
      for i = 1, math.random(1, 100) do
         value = value .. math.random(1, 100000)

src/main/java/ru/vk/itmo/test/kovalevigor/reports/scripts/sh/base.sh

@@ -2,7 +2,7 @@
 NAME=$(date +"%s")
 JFR="../../info-$NAME.jfr"
 PREFIX="../../html/stage2"
-(wrk2 -c 64 -t 1 -L -d $1 -R $2 -s "../lua/$3.lua" http://localhost:8080 > "${PREFIX}/${NAME}_wrk.txt") &
+(wrk2 -c 128 -t 8 -L -d $1 -R $2 -s "../lua/$3.lua" http://localhost:8080 > "${PREFIX}/${NAME}_wrk.txt") &
 ./ap/bin/asprof -t -e cpu,alloc,lock -d $1 -f $JFR MainServer
 
 wait

src/main/java/ru/vk/itmo/test/kovalevigor/reports/stage2.md

@@ -0,0 +1,198 @@
+## Факты
+
+Была обновлена система с Monterey на Sonora, а также почищен диск
+
+В связи с чем результаты значительно выросли,
+особеннно в области **GET** запросов, которые очень много работают с диском
+
+Получается достаточное количества места на диске важный параметр
+
+Либо стоит благословить Купертино
+
+## Нагрузка
+### Характеристики
+Macbook Pro M1 16GB после перезапуска
+
+
+## Старый код
+До этого мы тестировали при 1 подключении и 1 потоке
+
+Соответственно у нас было 2 ограничения:
+1. Мы могли упираться в производительность wrk2
+2. Наш код работал только в одном потоке, несмотря на количество селекторов, т.к. подключение 1
+
+Поэтому перезапустим старый код и найдем новые rps
+### PUT
+
+По [локам](old_base_lock.html) переодически можно заметить flush, который тормозит селекторы
+
+Как мы видим [15000](old_base_wrk.txt) нагрузка настолько слабая,
+что нам не понадобились даже все селекторы (их только 4)
+[cpu](old_base_cpu.html)
+
+Немного поискав
+* [30000](old_30000_wrk.txt)
+* [60000](old_60000_wrk.txt)
+* [52000](old_52000_wrk.txt)
+
+остановился на [48000](old_stable_wrk.txt) RPS
+
+[lock](old_stable_lock.html) из интересного можно заметить,
+что по окончании работы закрывается множество сессий
+
+информация об этом пишется в лог и можно сделать выводы о том, что:
+1. не стоить злоупотреблять логами
+2. по этому столбику в целом можно смотреть о проблемности остальных локов
+   *(чем он больше, тем менее значимы остальные локи)*
+
+По [cpu](old_stable_cpu.html) видно, что большая часть ресурсов уходит на обработку подключений
+
+5 min: [rps](old_stable_long_wrk.txt),
+[alloc](old_stable_long_alloc.html)
+[cpu](old_stable_long_cpu.html),
+[lock](old_stable_long_lock.html)
+
+Как мы видим просадки теперь намного значительнее, т.к. flush блокирует все потоки
+
+### GET
+
+Немного поискав
+[60000](old_get_60000_wrk.txt)
+[80000](old_get_80000_wrk.txt)
+[85000](old_get_85000_wrk.txt)
+[90000](old_get_90000_wrk.txt)
+[100000](old_get_100000_wrk.txt)
+
+Остановился на 80000 rps
+5 min:
+[alloc](old_get_stable_long_alloc.html)
+[cpu](old_get_stable_long_cpu.html)
+[lock](old_get_stable_long_lock.html)
+[rps](old_get_stable_long_wrk.txt)
+
+Как мы видим из [lock](old_get_stable_long_lock.html) никаких локов на гет запросах нет, как и из кода
+
+В целом ничего, кроме огромного роста производительности отметить нечего
+
+И если в случае с **PUT** запросами он был всего в несколько раз,
+то здесь рост достаточно линеен, что может говорить о высоком параллелизме кода
+
+## Новый код
+
+### ArrayBlockingQueue
+
+Производительность только упала
+
+#### PUT
+
+Как показали опыты: poolSize имеет значение.
+* 16:
+* * 43000: [alloc](new_put_a_16_43000_alloc.html),
+    [cpu](new_put_a_16_43000_cpu.html),
+    [lock](new_put_a_16_43000_lock.html),
+    [rps](new_put_a_16_43000_wrk.txt)
+* * 48000: [alloc](new_put_a_16_48000_alloc.html),
+    [cpu](new_put_a_16_48000_cpu.html),
+    [lock](new_put_a_16_48000_lock.html),
+    [rps](new_put_a_16_48000_wrk.txt)
+* * [50000](new_put_a_16_50000_wrk.txt)
+* 32
+* * [42000](new_put_a_32_42000_wrk.txt)
+* * 43000: [alloc](new_put_a_32_43000_alloc.html),
+    [cpu](new_put_a_32_43000_cpu.html),
+    [lock](new_put_a_32_43000_lock.html),
+    [rps](new_put_a_32_43000_wrk.txt),
+* * [45000](new_put_a_32_45000_wrk.txt)
+* * [50000](new_put_a_32_50000_wrk.txt)
+
+Чем больше потоков, тем сильнее они мешают друг-другу, что приводит к значительному снижению производительности
+
+Так мы добрались до 8 максимальных (т.е. по числу ядер).
+* [alloc](new_put_a_2_8_48000_alloc.html)
+* [cpu](new_put_a_2_8_48000_cpu.html)
+* [lock](new_put_a_2_8_48000_lock.html)
+* [rps](new_put_a_2_8_48000_wrk.txt)
+
+5 min: [alloc](new_put_a_2_8_stable_long_alloc.html),
+[cpu](new_put_a_2_8_stable_long_cpu.html),
+[lock](new_put_a_2_8_stable_long_lock.html),
+[rps](new_put_a_2_8_stable_long_wrk.txt)
+
+Основные проблемы и заполнение очереди происходили при flush'ах таблицы, что вполне ожидаемо
+
+#### GET
+
+Здесь обратная ситуация, наши ответы достаточно долгие, а запросы наоборот быстрые, т.к. никаких данных считывать нам не нужно
+
+И чем больше poolSize, тем больше допустимый RPS
+
+### LinkedBlockingQueue
+
+Несложно заметить, что у нас большие проблемы с локами. Связано это с тем, что в `ArrayBlockingQueue`
+одна блокировка на чтение и запись, поэтому окончательно разделить селекторы от воркеров не получилось
+
+Воспользуемся `LinkedBlockingQueue`, у которой уже 2 разные блокировки на чтение и запись
+
+#### PUT
+
+Как мы видим, несмотря на то, что время самих блокировок для селекторов значительно уменьшилось
+
+Что повысило скорость поступления новых задач (поэтому был повышел queueCapacity до 200, т.к. он набирался слишком быстро).
+
+Однако, сама очередь достаточно медлена. Из-за чего общая производительность страдает.
+
+* [40000](new_put_l_32_40000_wrk.txt)
+* 45000: [alloc](new_put_l_32_45000_alloc.html),
+  [cpu](new_put_l_32_45000_cpu.html),
+  [lock](new_put_l_32_45000_lock.html),
+  [rps](new_put_l_32_45000_wrk.txt)
+* [48000](new_put_l_32_48000_wrk.txt)
+* [60000](new_put_l_32_60000_wrk.txt)
+
+#### GET
+
+На удивление, **GET'у** стало чуть лучше, но мне кажется, все в рамках погрешности
+
+[rps](new_get_l_32_60000_wrk.txt),
+[alloc](new_get_l_32_60000_alloc.html),
+[cpu](new_get_l_32_60000_cpu.html),
+[lock](new_get_l_32_60000_lock.html)
+
+### Давайте попробуем поделить
+
+Поделим селекторы и воркеров на группы, чтобы уменьшить блокировку
+
+Как мы видим, мы смогли замедлить downgrade касательно времени работы
+
+Однако, как-то значительно улучшить производительность это нам не помогло
+
+#### PUT
+
+
+* 40000:
+  [alloc.html](1709758164_alloc.html)
+  [cpu.html](1709758164_cpu.html)
+  [lock.html](1709758164_lock.html)
+  [wrk.txt](1709758164_wrk.txt)
+* 50000:
+    [alloc](1709758118_alloc.html),
+    [cpu](1709758118_cpu.html),
+    [lock](1709758118_lock.html),
+    [rps](1709758118_wrk.txt)
+
+  * 60000: [alloc](1709758089_alloc.html),
+  [cpu](1709758089_cpu.html),
+  [lock](1709758089_lock.html),
+  [rps](1709758089_wrk.txt)
+
+Локи в селекторах теперь незначительно, но тольку то ;)
+
+## Вывод
+
+Несмотря, на очевидность преимуществ, которые нам может подарить разделение селекторов
+
+Оказывается, что на самом деле это довольно тонкая тема, в связи с многопоточностью и блокировками,
+которые нужно не забывать учитывать
+
+К сожалению, не успел посмотреть `DiscardPolicy` с обрывом сокета для первой в очереди. 
+Это вполне могло повлиять на среднее время ответа

src/main/java/ru/vk/itmo/test/kovalevigor/server/Responses.java

@@ -21,6 +21,10 @@ public Response toResponse() {
         return emptyResponse(responseCode);
     }
 
+    public String getResponseCode() {
+        return responseCode;
+    }
+
     private static Response emptyResponse(String resultCode) {
         return new Response(resultCode, Response.EMPTY);
     }

src/main/java/ru/vk/itmo/test/kovalevigor/server/ServerBasedOnStrategy.java

@@ -0,0 +1,45 @@
+package ru.vk.itmo.test.kovalevigor.server;
+
+import one.nio.http.HttpServer;
+import one.nio.http.HttpServerConfig;
+import one.nio.http.HttpSession;
+import one.nio.http.Request;
+import one.nio.server.SelectorThread;
+
+import java.io.IOException;
+
+public class ServerBasedOnStrategy extends HttpServer implements ServerFull {
+
+    private final ServerStrategy serverStrategy;
+
+    public ServerBasedOnStrategy(HttpServerConfig config, ServerStrategy serverStrategy) throws IOException {
+        super(config);
+        this.serverStrategy = serverStrategy;
+    }
+
+    @Override
+    public synchronized void start() {
+        super.start();
+        serverStrategy.start(this);
+    }
+
+    @Override
+    public void handleRequest(Request request, HttpSession session) throws IOException {
+        serverStrategy.handleRequest(request, session);
+    }
+
+    @Override
+    public void handleDefault(Request request, HttpSession session) throws IOException {
+        serverStrategy.handleDefault(request, session);
+    }
+
+    @Override
+    public void close() throws IOException {
+        serverStrategy.close();
+    }
+
+    @Override
+    public SelectorThread[] getSelectors() {
+        return selectors;
+    }
+}