Changes between Version 1 and Version 2 of AdvancedApplicationDevelopment

Timestamp:

05/07/26 13:21:43 (3 days ago)

Author:

233062

Comment:

--

AdvancedApplicationDevelopment

@@ -1 @@
-= Напреден Апликативен Развој - Оптимизација на Backend-от =
-
-== Проблем ==
-
-При зголемен број на корисници и захтеви, backend апликацијата покажуваше слаба перформанса поради:
-
-1. Недостаток на соодветна конфигурација на connection pooling (премал pool size од 2)
-2. Непотребни транзакции на read-only операции
-3. N+1 query проблем во WeightService (една query per row за training sessions)
-4. Неоптимална батching на operations во DisciplineService
-
-== Решение ==
+= Напреден Апликативен Развој
 
 === 1. Pooling - Hikari Configuration ===
@@ -16 +5 @@
 Pooling претставува процес каде што не се отвара нова конекција за секој request, туку има константен број на отворени конекције кои се доделуваат на различни requests. Со ова значително се намалува времето по request бидејќи не се губи време за отварање на нова и затворање на стара конекција.
 
-Во projectот ова го правам со Hikari Pool во Java Spring Boot. Hikari е автоматски вклучено во Spring Boot преку spring-boot-starter-web библиотеката.
+Во мојот проект ова го правам со Hikari Pool во Java Spring Boot. Hikari е автоматски вклучено во Spring Boot преку spring-boot-starter-web библиотеката.
 
 Пред (конзервативна конфигурација за SSH tunnel):
@@ -26 +15 @@
 След (поголем default pool за поголем број корисници):
 {{{
-# Максимален број на конекции (default 5, може да се override преку env)
-spring.datasource.hikari.maximum-pool-size=${SPRING_DATASOURCE_HIKARI_MAX_POOL_SIZE:5}
+# Максимален број на конекции (default 20, може да се override преку env)
+spring.datasource.hikari.maximum-pool-size=${SPRING_DATASOURCE_HIKARI_MAX_POOL_SIZE:20}
 
 # Минимум конекции кои секогаш ќе се спремни за да преземат нови requests
-spring.datasource.hikari.minimum-idle=${SPRING_DATASOURCE_HIKARI_MIN_IDLE:1}
+spring.datasource.hikari.minimum-idle=${SPRING_DATASOURCE_HIKARI_MIN_IDLE:5}
 
 # Колку долго да се чека за конекција пред requestot да е одбиен
@@ -261 +250 @@
 }}}
 
-== Резултати ==
-
-По оптимизацијата:
-
-✓ Hikari Pool зголемен од 2 → 5 конекции
-✓ 15+ методи означени со @Transactional(readOnly = true)
-✓ N+1 query решен во WeightService (90% намалување)
-✓ DisciplineService оптимизиран со batch insertions (80% намалување)
-✓ Сите файлови компајлирани без errors
-✓ Backend тестови успешно поминаа
-
-== Заклучок ==
-
-Backend апликацијата е оптимизирана за поголем број на конкурентни корисници, брже read-операции, и намалена database load.