JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 Implementasi Strategi Default Connection Pool dan Prewarm Connection Pool pada Integrasi Minio Menggunakan Go dan K6 Muhammad Miftakul Salam1.
Ronggo Alit2 Program Studi S1 Teknik Informatika.
Universitas Negeri Surabaya 22101@mhs.
2ronggoalit@unesa.
dengan object storage didominasi oleh transfer data berukuran besar melalui protokol HTTP/HTTPS yang bersifat stateless.
Meskipun optimalisasi koneksi melalui mekanisme Connection Pooling telah terbukti krusial untuk meningkatkan performa sistem database, seperti ditunjukkan oleh Sobri et al.
yang menemukan bahwa konfigurasi pool yang tepat dapat menurunkan latensi hingga 53% pada arsitektur microservice .
, literatur yang membahas spesifik mengenai strategi pooling untuk object storage masih sangat terbatas.
Mayoritas penelitian masih berfokus pada ranah database relasional atau fungsi serverless .
Dalam ekosistem bahasa pemrograman Go, manajemen koneksi HTTP ditangani oleh http.
Transport yang secara default menerapkan strategi Lazy Initialization .
embuatan koneksi secara on-deman.
Strategi ini efisien dalam penggunaan memori saat kondisi diam .
, namun rentan terhadap masalah cold start penalty, yaitu tingginya latensi pada permintaan pertama karena overhead inisialisasi koneksi TCP dan TLS .
Sebagai alternatif, strategi Prewarm atau Eager Initialization, yang mengadopsi konsep prebaking pada lingkungan FaaS, menawarkan solusi dengan menyiapkan koneksi di awal startup .
, namun dengan konsekuensi alokasi sumber daya yang lebih besar.
Efisiensi akses terhadap storage sangat bergantung pada konfigurasi pool yang tepat, terutama dalam lingkungan dengan tingkat konkurensi tinggi .
Kata KunciAi Connection Pool.
Go.
MinIO.
Object Storage.
Ketidakpastian mengenai trade-off performa antara kedua Performance Testing.
Prewarm.
strategi ini pada konteks object storage menciptakan celah pengetahuan yang perlu diisi.
Penelitian ini bertujuan untuk PENDAHULUAN membandingkan secara empiris performa strategi Default Aplikasi digital modern menghadapi tantangan signifikan Connection Pool dan Prewarm Connection Pool pada dalam mengelola volume data yang terus meningkat secara eksponensial, terutama data multimedia tidak terstruktur.
integrasi aplikasi Go dengan MinIO.
Fokus utama penelitian adalah menganalisis dampak masing-masing strategi terhadap Sistem tidak hanya harus menyimpan data dalam jumlah besar, metrik kritis meliputi latency, throughput, dan efisiensi tetapi juga mampu mengelolanya dengan performa tinggi untuk menghindari bottleneck I/O .
Untuk mengatasi sumber daya (CPU & Memor.
di bawah berbagai skenario kebutuhan skalabilitas ini, arsitektur Object Storage seperti beban kerja menggunakan alat uji K6.
Hasil penelitian MinIO.
AWS S3, dan GCP Storage menjadi standar industri diharapkan dapat memberikan panduan teknis bagi karena menawarkan kapasitas tak terbatas dan biaya yang pengembang dalam memilih strategi manajemen koneksi yang lebih efisien dibandingkan penyimpanan berbasis blok .
paling optimal sesuai karakteristik beban kerja aplikasi Namun, adopsi object storage dalam arsitektur backend mereka.
menghadirkan tantangan unik dalam pengelolaan koneksi II.
METODOLOGI PENELITIAN
yang berbeda secara fundamental dari database relasional.
Penelitian ini menggunakan metode eksperimental untuk Interaksi dengan database relasional umumnya bersifat dan membandingkan performa strategi connection transaksional dengan frekuensi tinggi dan latensi rendah di Pelaksanaan penelitian dilakukan atas protokol yang stateful .
Sebaliknya, komunikasi AbstrakAi Pengelolaan koneksi antara aplikasi backend dan object storage sering kali menghadapi tantangan efisiensi, terutama terkait latensi awal dan penggunaan sumber daya.
Strategi default connection pool yang bersifat lazy initialization cenderung memicu cold start penalty yang tinggi, sedangkan strategi prewarm menawarkan kesiapan koneksi namun membutuhkan alokasi memori awal.
Penelitian ini bertujuan untuk membandingkan kinerja kedua strategi tersebut dalam integrasi MinIO menggunakan bahasa pemrograman Go guna menentukan solusi paling optimal.
Penelitian menggunakan metode eksperimental dengan melakukan performance testing menggunakan alat uji K6 melalui empat skenario beban kerja:
cold start burst, gradual ramp-up, spike test, dan sustained high Metrik utama yang dianalisis meliputi latency, throughput, error rate, serta penggunaan CPU dan memori.
Hasil pengujian menunjukkan bahwa strategi prewarm berhasil mengeliminasi cold start, menurunkan latency maksimal secara signifikan sebesar 72,2% .
ari 20,69 detik menjadi 5,74 deti.
dibandingkan strategi default.
Selain itu, pada pengujian beban tinggi jangka panjang, strategi prewarm menunjukkan stabilitas sumber daya yang superior dengan penggunaan CPU yang stabil di kisaran 25%, berbeda dengan strategi default yang mengalami ketidakstabilan berupa lonjakan CPU hingga 70% dan memory Berdasarkan hasil tersebut, strategi prewarm connection pool direkomendasikan untuk lingkungan produksi dengan traffic tinggi atau layanan yang membutuhkan ketersediaan JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 melalui tujuh tahapan sistematis, yaitu: .
identifikasi masalah, .
studi literatur, .
analisis kebutuhan, .
perancangan sistem, .
implementasi dan pengujian, .
pengumpulan dan analisis data, serta .
Arsitektur sistem dirancang dengan topologi client-server seperti tampak di Gbr 1.
Nginx dikonfigurasi sebagai reverse proxy yang membagi lalu lintas ke dua instance aplikasi backend (Refin.
berbasis Go: satu menerapkan Default Connection Pool dan lainnya menerapkan Prewarm Connection Pool.
Kedua aplikasi terhubung ke instance MinIO yang terisolasi untuk memastikan kemurnian data uji.
Implementasi dan Pengujian Implementasi dilakukan dengan mengembangkan aplikasi studi kasus "Refina" berbasis Go yang menyediakan endpoint unggah file ke MinIO.
Pengujian performa dilaksanakan menggunakan instrumen K6 melalui empat skenario yang masing-masing difokuskan pada metrik spesifik: .
Cold Start Burst yang menargetkan analisis Latency awal akibat inisialisasi koneksi.
Gradual Ramp-up untuk mengevaluasi batas toleransi sistem berdasarkan Error Rate.
Spike Test Gbr.
1 Tahapan Penelitian yang mengukur stabilitas Throughput (RPS) saat terjadi fluktuasi beban ekstrem .
Sustained High Load untuk Identifikasi Masalah memvalidasi efisiensi dan stabilitas Resource Usage (CPU Tahap ini berfokus pada analisis kesenjangan .
ap analysi.
dan Memor.
dalam jangka panjang.
terkait minimnya literatur mengenai optimasi koneksi pada TABEL I object storage.
Masalah utama yang diidentifikasi adalah TEST CASE SCENARIO K6 perbedaan karakteristik antara database relasional dan object storage, di mana strategi pooling yang umum digunakan pada Nama Test Case Virtual Durasi File Size Users database belum tentu optimal jika diterapkan langsung pada TC1 - Cold Start 2 menit 40 20 KB 0 Ie 100 object storage yang bersifat stateless.
Studi Literatur Kajian mendalam dilakukan terhadap konsep Connection Pool .
hususnya strategi Lazy vs Eager Initializatio.
, arsitektur MinIO, dan bahasa pemrograman Go.
Studi ini menjadi landasan teoretis untuk merancang skenario pengujian yang relevan dan memahami parameter kinerja yang krusial.
Analisis Kebutuhan Spesifikasi infrastruktur ditetapkan untuk mendukung validitas pengujian.
Sisi Server menggunakan VPS dengan prosesor AMD EPYC 9354P .
-Cor.
RAM 8 GB, dan penyimpanan SSD berbasis Ubuntu 20.
Sisi Client .
oad generato.
menggunakan perangkat berbasis AMD Ryzen 3 dengan RAM 8 GB.
Perangkat lunak utama meliputi Docker untuk orkestrasi kontainer.
K6 untuk load testing, serta Prometheus dan Grafana untuk pemantauan metrik.
Perancangan Sistem Burst TC2 - Gradual Ramp-up Load TC3 - Spike Test TC4 - Sustained High Load Vus 0 Ie 150 Vus 0 Ie 250 VUs .
x Spik.
0 Ie 100 VUs (Konsta.
8 menit 30
8 menit 15 menit 1 MB
20 KB
20 KB
Pengumpulan dan Analisis Data Data dikumpulkan secara real-time menggunakan protokol Remote Write dari K6 ke Prometheus.
Metrik penggunaan sumber daya (CPU dan Memor.
dipantau menggunakan Portainer.
Seluruh data disentralisasi ke dalam dashboard Grafana untuk mempermudah visualisasi tren performa antar kedua strategi.
Hasil Tahap akhir melibatkan ekstraksi dan komparasi metrik performa utama, yaitu Latency (Avg.
P95.
Ma.
Throughput (RPS).
Error Rate, serta efisiensi sumber daya (CPU dan Memor.
HASIL DAN PEMBAHASAN
Paragraf harus teratur.
Semua paragraf harus rata, yaitu sama-sama rata kiri dan dan rata kanan.
Hasil Pengujian Baseline (Kondisi Idl.
Gbr.
1 Arsitektur Sistem JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 Pengujian baseline bertujuan untuk mengamati perilaku manajemen memori dan CPU saat aplikasi baru dijalankan .
dan belum menerima trafik.
Perbandingan kedua strategi pada kondisi idle dirangkum dalam Tabel II.
TABEL i PERBANDINGAN RESOURCE USAGE KONDISI IDLE .
Resource Utilization pada Default Connection Pool:
Pada strategi Default (Lazy Initializatio.
, aplikasi tidak membuat koneksi saat startup.
Pola Penggunaan Memori:
Parameter Konsumsi Memori (Idl.
Default
Rendah
MB)
Prewarm Lebih Tinggi .
MB) Perilaku Startup Stabil Lonjakan Tinggi .
MB) Stabilitas Grafik Fluktuatif Sangat Stabil (Fla.
Gbr.
3 Grafik Resource Usage pada Default Connection Pool saat Idle Berdasarkan pemantauan pada Gbr.
3, karakteristik sistem adalah sebagai berikut:
Penggunaan memori relatif rendah, bergerak stabil di kisaran 8.
5Ae9.
5 MB.
Grafik menunjukkan fluktuasi kecil .
aik-turu.
sekitar 8Ae12%.
Hal ini wajar karena tidak ada beban koneksi yang disimpan .
tored connection.
, sehingga memori murni digunakan oleh runtime dasar Go.
Pola Penggunaan CPU: Terdapat aktivitas CPU dengan lonjakan periodik .
eriodic spike.
4Ae0.
6%, meskipun rata-rata tetap rendah .
1Ae0.
2%).
Ini menunjukkan aktivitas standar container tanpa beban manajemen pool yang kompleks.
Analisis Prewarm membutuhkan memori ekstra untuk memelihara pool koneksi yang aktif.
Dampak dari inisialisasi koneksi massal di awal pada strategi Prewarm.
Setelah startup.
Prewarm cenderung lebih tenang secara resource karena koneksi sudah siap .
Hasil Pengujian Performa Pengujian performa dilakukan dalam empat skenario untuk mengukur Latency.
Error Rate.
Throughput, dan stabilitas Resource.
Skenario 1 Cold Start Burst (Fokus Latenc.
: Skenario ini mengukur respons sistem saat menghadapi lonjakan pengguna tiba-tiba .
ke 100 VU.
dari kondisi diam.
Resource Utilization pada Prewarm Connection Pool:
Pada strategi Prewarm, aplikasi menginisialisasi koneksi ke MinIO segera setelah startup.
Gbr.
4 Grafik Resource Usage pada Prewarm Connection Pool saat Idle Berdasarkan Gbr.
2, terlihat perbedaan signifikan akibat proses prewarming:
Pola Penggunaan Memori: Terjadi lonjakan penggunaan memori yang tinggi di awal startup hingga mencapai 30Ae32 MB.
Lonjakan ini adalah dampak langsung dari inisialisasi koneksi massal.
Setelah fase ini, memori turun dan stabil di angka 13Ae15 MB, yang mana lebih tinggi dibandingkan strategi Default karena adanya alokasi untuk menjaga koneksi tetap aktif .
Pola Penggunaan CPU: Setelah inisialisasi selesai, grafik CPU cenderung sangat datar dan stabil di 0Ae0.
1% dengan lonjakan yang sangat Ini mengindikasikan bahwa setelah koneksi terbentuk .
, sistem tidak memerlukan daya komputasi besar untuk Gbr.
5 Default Connection Pool Performance Cold Start Burst Test JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 Gbr.
6 Prewarm Connection Pool Performance Cold Start Burst Test Gbr.
8 Prewarm Connection Pool Performance Gradual Ramp-up Load Test Berdasarkan Gbr.
5 dan Gbr.
6, analisis hasil menunjukkan:
Analisis dari Gbr.
7 dan Gbr.
8 menunjukkan:
Latency Maksimal: Strategi Default mengalami Max Latency hingga 20,69 detik.
Hal ini disebabkan oleh cold start penalty, di mana request pertama harus menunggu proses TCP/TLS handshake selesai.
Sebaliknya.
Prewarm berhasil menahan Max Latency di angka 5,74 detik, atau penurunan sebesar 72,2%.
Implikasi: Hasil ini membuktikan bahwa strategi Prewarm sangat efektif menghilangkan hambatan Untuk aplikasi yang menuntut responsivitas tinggi sejak detik pertama, strategi Default tidak memadai karena menyebabkan penundaan signifikan bagi pengguna awal.
Skenario 2 Gradual Ramp-up Load (Fokus Error Rat.
Skenario ini menguji batas ketahanan sistem dengan mengirimkan file besar .
MB) sembari meningkatkan jumlah pengguna .
ke 150 VU.
Tingkat Kegagalan: Kedua strategi mengalami kegagalan tinggi.
Default mencatat Error Rate 55,16%, sedangkan Prewarm sebesar 54,48%.
Faktor Penyebab: Tingginya error pada kedua kubu mengindikasikan bahwa manajemen connection pool bukan faktor penentu dalam skenario ini.
Kegagalan lebih disebabkan oleh saturasi bandwidth jaringan atau Disk I/O akibat ukuran file yang besar.
Optimasi di sisi aplikasi .
terbukti tidak dapat sepenuhnya mengompensasi keterbatasan infrastruktur fisik.
Skenario 3 Spike Test (Fokus Throughpu.
: Skenario ini mensimulasikan lonjakan trafik ekstrem yang berulang .
ke 250 VU.
untuk mengukur kapasitas pemrosesan.
Gbr.
9 Default Connection Pool Performance Spike Test Gbr.
7 Default Connection Pool Performance Gradual Ramp-up Load Test JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 Gbr.
12 Prewarm Connection Pool Performance Gradual Ramp-up Load Test Perbandingan detail penggunaan sumber daya disajikan dalam Tabel i TABEL i PERBANDINGAN RESOURCE USAGE PADA SUSTAINED HIGH LOAD Gbr.
10 Prewarm Connection Pool Performance Spike Test Berdasarkan Gbr.
9 dan Gbr.
10, ditemukan bahwa:
Kapasitas Pemrosesan:
Strategi Prewarm mencatatkan total permintaan sukses yang lebih banyak .
287 vs 19.
dan rata-rata throughput yang lebih tinggi .
,94 req/s vs 39,49 req/.
Stabilitas: Meskipun selisih angka terlihat kecil ( 1,1%).
Prewarm menunjukkan konsistensi yang lebih baik dalam menjaga aliran data.
Strategi Default harus berjuang membuka koneksi baru secara reaktif saat spike terjadi, yang berpotensi menghambat antrian permintaan.
Prewarm yang memiliki koneksi siaga mampu memproses antrian dengan lebih mulus.
Skenario 4 Sustained High Load (Fokus Resourc.
Skenario jangka panjang .
ini bertujuan mendeteksi efisiensi internal dan potensi kebocoran memori.
Parameter Pola Memori Default Naik Perlahan Prewarm Sangat Stabil Rentang Memori 10 Ie 16 MB (Tren Nai.
35 Ie 16 (Konsta.
Pola CPU Fluktuatif Tinggi Datar Lonjakan CPU (Spik.
Ekstrem Terkendal i .
%) Kesimpulan Berisiko Degradasi Sangat Stabil Analisis Lazy mengalami kenaikan memori 4050% seiring waktu, berisiko kebocoran .
jangka panjang.
Prewarm menjaga konsistensi alokasi tanpa akumulasi Fluktuasi CPU pada Lazy menandakan manajemen koneksi yang tidak efisien dalam durasi panjang.
Lonjakan 70% pada Lazy berbahaya karena dapat memblokir proses lain dan menyebabkan waktu respons tidak stabil.
Lazy menyimpan risiko instabilitas untuk layanan alwayson, sedangkan Prewarm sangat Analisis mendalam dari Gbr.
Gbr.
12, dan Tabel i Instabilitas Strategi Default: Strategi Default terbukti tidak stabil untuk beban jangka panjang.
Hal ini ditandai dengan fenomena Memory Creep .
enaikan penggunaan memori bertahap tanpa pembersihan efekti.
dan lonjakan CPU ekstrem hingga 70%.
Aktivitas buka-tutup koneksi yang terus menerus membebani Garbage Collector dan CPU.
Keunggulan Strategi Prewarm: Sebaliknya, strategi Prewarm menunjukkan profil penggunaan sumber daya yang datar .
Meskipun membutuhkan alokasi memori awal lebih tinggi, ia berhasil menjaga penggunaan CPU tetap tenang di Gbr.
11 Default Connection Pool Performance Gradual Ramp-up Load Test JINACS: Volume 07 Nomor 03, 2026 (Journal of Informatics and Computer Scienc.
ISSN : 2686-2220 kisaran 25%.
Hal ini menegaskan bahwa untuk layanan jangka panjang .
ong-running service.
Prewarm jauh lebih aman dan terprediksi, mencegah degradasi performa seiring berjalannya IV.
KESIMPULAN
Penelitian ini berhasil mengungkap karakteristik performa dan efisiensi antara strategi Default Connection Pool (Laz.
dan Prewarm Connection Pool pada integrasi MinIO menggunakan bahasa Go.
Berdasarkan analisis hasil pengujian, strategi Prewarm terbukti secara signifikan mengungguli strategi Default dalam aspek responsivitas awal.
Strategi ini mampu mengeliminasi cold start penalty dan memangkas latensi maksimal (Max Latenc.
hingga 72,2% .
ari 20,69 detik menjadi 5,74 deti.
dibandingkan strategi Default yang mengalami hambatan inisialisasi koneksi berat saat menerima trafik pertama .
Dalam hal stabilitas sistem jangka panjang, strategi Prewarm menunjukkan superioritas yang jelas.
Strategi ini berhasil mempertahankan penggunaan sumber daya yang datar .
dan terprediksi, serta menjaga penggunaan CPU stabil di kisaran 25% bahkan di bawah beban kerja konstan selama 15 menit.
Sebaliknya, strategi Default terbukti rentan terhadap instabilitas internal, ditandai dengan fenomena kenaikan penggunaan memori akumulatif .
emory cree.
dan lonjakan CPU ekstrem hingga 70% yang berisiko mendegradasi performa layanan always-on.
Meskipun demikian, terdapat trade-off yang perlu diperhatikan.
Strategi Prewarm membutuhkan alokasi memori awal yang lebih besar saat startup demi menjaga kesiapan koneksi.
kepada Fakultas Teknik.
Universitas Negeri Surabaya yang telah memfasilitasi pelaksanaan penelitian.
Penulis juga mengapresiasi dukungan emosional maupun informasional yang diberikan oleh keluarga dan rekan-rekan selama proses penelitian berlangsung.
REFERENSI
UCAPAN TERIMA KASIH