Changes between Version 7 and Version 8 of Phase4_Performance_Analysis

Timestamp:

07/22/26 20:10:13 (6 days ago)

Author:

226052

Comment:

--

Phase4_Performance_Analysis

@@ -278 +278 @@
 
 
+= Мерење на перформанси по PostgreSQL tuning
+
+По иницијалното мерење на перформансите беше извршено дополнително подесување на PostgreSQL конфигурацијата. Целта беше базата подобро да ги користи достапните ресурси, особено меморијата, кеширањето и паралелното извршување.
+
+Тестирањето се извршува на машина со 32 GB RAM и Intel i9-9900K процесор. PostgreSQL работи во Docker/WSL околина, каде за време на тестирањето имаше достапно 16 GB RAM. Поради тоа, PostgreSQL tuning параметрите беа избрани според достапната меморија во Docker околината, а не според целосната физичка меморија на машината.
+
+Со `docker inspect` беше проверено дека контејнерот нема посебно зададено ограничување за CPU или меморија:
+
+{{{
+docker inspect postgres-db --format='CPUs={{.HostConfig.NanoCpus}} Memory={{.HostConfig.Memory}}'
+
+CPUs=0 Memory=0
+}}}
+
+== PostgreSQL tuning
+
+Оптимизацијата беше направена со `ALTER SYSTEM`, со што параметрите се запишуваат во PostgreSQL конфигурацијата:
+
+{{{
+ALTER SYSTEM SET shared_buffers = '4GB';
+ALTER SYSTEM SET effective_cache_size = '12GB';
+ALTER SYSTEM SET work_mem = '64MB';
+ALTER SYSTEM SET maintenance_work_mem = '1GB';
+ALTER SYSTEM SET max_worker_processes = 16;
+ALTER SYSTEM SET max_parallel_workers = 8;
+ALTER SYSTEM SET max_parallel_workers_per_gather = 4;
+ALTER SYSTEM SET random_page_cost = 1.1;
+ALTER SYSTEM SET effective_io_concurrency = 200;
+}}}
+
+По поставувањето на параметрите, PostgreSQL контејнерот беше рестартиран:
+
+{{{
+docker restart postgres-db
+}}}
+
+Потоа конфигурацијата беше проверена со следните `SHOW` команди:
+
+{{{
+SHOW shared_buffers;
+SHOW effective_cache_size;
+SHOW work_mem;
+SHOW maintenance_work_mem;
+SHOW max_worker_processes;
+SHOW max_parallel_workers;
+SHOW max_parallel_workers_per_gather;
+SHOW random_page_cost;
+SHOW effective_io_concurrency;
+}}}
+
+Добиената активна конфигурација е:
+
+|| '''Параметар''' || '''Вредност''' || '''Цел''' ||
+|| shared_buffers || 4GB || PostgreSQL кеш за табели и индекси. ||
+|| effective_cache_size || 12GB || Проценка за достапна кеш меморија за query planner-от. ||
+|| work_mem || 64MB || Меморија за sort, hash join, hash aggregate и GROUP BY операции. ||
+|| maintenance_work_mem || 1GB || Меморија за maintenance операции, на пример CREATE INDEX и VACUUM. ||
+|| max_worker_processes || 16 || Максимален број background worker процеси. ||
+|| max_parallel_workers || 8 || Вкупен број parallel workers за серверот. ||
+|| max_parallel_workers_per_gather || 4 || Максимален број parallel workers за еден прашалник. ||
+|| random_page_cost || 1.1 || Пониска цена за random I/O, посоодветна за SSD/NVMe и кеширани податоци. ||
+|| effective_io_concurrency || 200 || Подобро искористување на паралелни I/O операции. ||
+
+Со оваа конфигурација повторно беа извршени истите `pgbench` тестови.
+
+== Детални резултати по PostgreSQL tuning
+
+=== Q1 - Movie Recommendation
+
+Прашалникот прави препорака на филмови за конкретен корисник. Се користат претходните изнајмувања, категориите, рејтинзите и популарноста на филмовите во 2024 година.
+
+|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
+|| 10 || 2 || 1920.007 ms || 724.511 ms || 5.208 || 833.150 ms || 433.224 ms || 12.003 || ~56.6% побрзо ||
+|| 20 || 4 || 3553.036 ms || 1122.492 ms || 5.629 || 2136.662 ms || 1000.752 ms || 9.360 || ~39.9% побрзо ||
+|| 50 || 4 || 8547.274 ms || 1838.716 ms || 5.850 || 5106.524 ms || 1606.435 ms || 9.791 || ~40.3% побрзо ||
+
+По tuning, партиционираната табела `rental` покажува значително подобри резултати од `rental_copy`. Латентноста е помала кај сите нивоа на конкурентност, TPS е повисок, а standard deviation е помала. Ова покажува дека оптимизираната структура дава побрзо и постабилно извршување.
+
+=== Q2 - Popular Films 2024
+
+Прашалникот ги пресметува најизнајмуваните филмови во 2024 година. Содржи филтер по `rental_date`, JOIN со `inventory` и `film`, групирање по филм и сортирање според бројот на изнајмувања.
+
+|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
+|| 10 || 4 || 1560.813 ms || 883.089 ms || 6.407 || 1321.393 ms || 674.246 ms || 7.568 || ~15.3% побрзо ||
+|| 20 || 4 || 3136.978 ms || 1464.866 ms || 6.376 || 2730.179 ms || 1229.865 ms || 7.326 || ~13.0% побрзо ||
+|| 30 || 4 || 5259.732 ms || 2139.302 ms || 5.704 || 3950.966 ms || 1442.761 ms || 7.593 || ~24.9% побрзо ||
+|| 50 || 4 || 9015.934 ms || 2895.372 ms || 5.546 || 6633.659 ms || 2024.828 ms || 7.537 || ~26.4% побрзо ||
+
+По tuning, партиционираната табела има подобри резултати кај сите тестирани нивоа на конкурентност. Кај 10 клиенти латентноста се намалува за околу 15.3%, а кај 50 клиенти за околу 26.4%.
+
+TPS е повисок кај партиционираната табела во сите мерења, а standard deviation е помала. Ова покажува дека оптимизираната верзија има постабилно време на извршување. PostgreSQL tuning помага преку поголем `work_mem` за агрегација и сортирање, додека партиционирањето помага бидејќи прашалникот чита податоци само за 2024 година.
+
+=== Q3 - Monthly Revenue
+
+Прашалникот пресметува месечен приход по продавница за 2024 година. Се користи филтер по `payment_date`, JOIN со `staff` и агрегации како `COUNT`, `SUM`, `AVG`, `MIN` и `MAX`.
+
+|| '''Clients''' || '''Threads''' || '''payment_copy latency''' || '''payment_copy stddev''' || '''payment_copy TPS''' || '''payment latency''' || '''payment stddev''' || '''payment TPS''' || '''Промена''' ||
+|| 10 || 4 || 2681.628 ms || 952.943 ms || 3.729 || 1104.610 ms || 593.580 ms || 9.053 || ~58.8% побрзо ||
+|| 30 || 4 || 6844.099 ms || 1907.879 ms || 4.383 || 3152.069 ms || 1234.209 ms || 9.518 || ~53.9% побрзо ||
+|| 50 || 4 || 11372.246 ms || 2677.587 ms || 4.397 || 5309.611 ms || 1701.580 ms || 9.417 || ~53.3% побрзо ||
+
+Q3 покажува големо подобрување бидејќи прашалникот филтрира по `payment_date`, а табелата `payment` е партиционирана според истата колона. PostgreSQL може да ја ограничи обработката на релевантната партиција за 2024 година.
+
+TPS е повеќе од двојно поголем кај партиционираната табела, а standard deviation е помала во сите тестови. Ова покажува побрзо и попредвидливо извршување.
+
+=== Q4 - INSERT rental
+
+Овој тест мери внесување нови редови во табелата за изнајмувања. За benchmark редовите се користи датумот `2026-03-07 12:00:00`, за да можат лесно да се издвојат и избришат по тестирањето.
+
+|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
+|| 10 || 4 || 2.752 ms || 0.627 ms || 3633.816 || 3.026 ms || 2.168 ms || 3304.381 || ~10.0% побавно ||
+|| 30 || 4 || 2.978 ms || 1.276 ms || 10072.768 || 3.442 ms || 1.440 ms || 8716.851 || ~15.6% побавно ||
+|| 50 || 4 || 3.114 ms || 1.740 ms || 16058.633 || 3.588 ms || 2.118 ms || 13935.611 || ~15.2% побавно ||
+
+Кај INSERT операциите, партиционираната табела е малку побавна во сите три мерења. Ова е очекувано бидејќи при INSERT во партиционирана табела PostgreSQL мора да одреди во која партиција припаѓа новиот ред и да ги ажурира индексите на соодветната партиција.
+
+И покрај тоа, разликата е мала во апсолутна вредност, бидејќи латентноста и кај двете табели останува во опсег од неколку милисекунди. Ова покажува дека партиционирањето не мора секогаш да го забрза INSERT.
+
+=== Q5 - UPDATE rental
+
+Овој тест мери ажурирање на редови со `rental_date = TIMESTAMP '2026-03-07 12:00:00'` и `return_date IS NULL`.
+
+|| '''Clients''' || '''Threads''' || '''rental_copy latency''' || '''rental_copy stddev''' || '''rental_copy TPS''' || '''rental latency''' || '''rental stddev''' || '''rental TPS''' || '''Промена''' ||
+|| 10 || 4 || 697.000 ms || 343.262 ms || 14.347 || 6.907 ms || 3.537 ms || 1447.849 || ~99.0% побрзо ||
+|| 30 || 4 || 1762.767 ms || 393.804 ms || 17.019 || 12.705 ms || 7.407 ms || 2361.325 || ~99.3% побрзо ||
+|| 50 || 4 || 2926.856 ms || 626.986 ms || 17.083 || 16.336 ms || 10.520 ms || 3060.774 || ~99.4% побрзо ||
+
+UPDATE операцијата покажува најголемо подобрување. Кај 10 клиенти латентноста се намалува од 697.000 ms на 6.907 ms, а кај 50 клиенти од 2926.856 ms на 16.336 ms.
+
+TPS е многу поголем кај партиционираната табела, а standard deviation е значително помала. Причината е тоа што условот користи конкретен `rental_date`. Бидејќи `rental` е партиционирана според `rental_date`, PostgreSQL може да ја ограничи операцијата на релевантната партиција наместо да пребарува низ целата табела.
+
+== Вкупна анализа
+
+По PostgreSQL tuning, најголеми придобивки има кај прашалниците што користат временски филтер врз колоната по која е направено партиционирањето.
+
+Најголеми подобрувања:
+
+* Q5 - UPDATE rental: околу 99% намалување на латентноста кај партиционираната табела.
+* Q3 - Monthly Revenue: околу 53-59% намалување на латентноста кај партиционираната табела.
+* Q1 - Movie Recommendation: околу 40-57% подобрување, зависно од бројот на клиенти.
+* Q2 - Popular Films 2024: околу 13-26% подобрување, со помала standard deviation.
+
+Мешан резултат има кај Q4 - INSERT rental. Партиционираната табела е околу 10-16% побавна, бидејќи INSERT во партиционирана табела има дополнителен overhead за избор на партиција и ажурирање на индексите.
+
+== Заклучок
+
+PostgreSQL tuning овозможува подобро користење на меморијата, кешот и процесорските ресурси. Зголемувањето на `work_mem`, `effective_cache_size` и parallel worker параметрите најмногу помага кај прашалници со JOIN, GROUP BY, ORDER BY и агрегации.
+
+Партиционирањето и индексите остануваат најважни кај операции што користат временски филтер по `rental_date` или `payment_date`. Најјасен пример е Q5, каде UPDATE операцијата е над 99% побрза кај партиционираната табела.