Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Analisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQL Kamarudin1 Nuzulul Afia Idris2 Guntur3 Yusri4 Program Studi Teknik Informatika.
Universitas Handayani Makassar1,2 Program Studi Sistem Komputer.
Universitas Handayani Makassar3 Program Studi Manajemen.
STIE Pelita Buana Makassar4 Jln.
Adyaksa No.
01 Makassar.
Sulawesi Selatan, 90231.
Indonesia1,2,3 Jln.
Laniang Blok F No.
Sulawesi Selatan, 90245.
Indonesia4 kamarudin@handayani.
id1, nakkekulo136@gmail.
com2, guntur@handayani.
acho@gmail.
Kata Kunci :
Go.
Bun.
PHP.
Benchmark.
Grafana k6.
ABSTRAK
Penelitian ini menyajikan analisis komparatif performa tiga runtime backend Go.
Bun, dan PHP dalam menangani HTTP request dengan beban data besar dari database MySQL.
Pengujian dilakukan menggunakan Grafana k6 dengan skenario ramp up hingga 250Ae300 virtual users (VU) selama 6Ae7 menit, di deploy pada platform Railway.
app dengan spesifikasi 8 vCPU dan 8 GB RAM.
Tiga skenario diuji: .
000 baris y 40 field dengan 250 VU, .
000 baris y 40 field dengan 250 VU, dan .
baris y 50 field dengan 300 VU.
Hasil menunjukkan bahwa Go secara konsisten unggul di seluruh skenario dengan throughput tertinggi mencapai 19,3 req/s pada skenario 10.
000 baris dan konsumsi memori yang efisien .
Ae 155 MB).
Bun berada di posisi kedua dengan throughput 2,1Ae3,04 req/s namun mengalami konsumsi memori tertinggi .
Ae425 MB) akibat double allocation pada proses JSON.
stringify().
PHP menunjukkan throughput terendah .
,5Ae4,8 req/.
dengan error rate yang sangat tinggi .
,4Ae99,9%) akibat keterbatasan arsitektur PHP-FPM yang sinkronus dalam menangani concurrent requests.
Root cause analysis mengidentifikasi bahwa streaming JSON encoder Go, model goroutine yang ringan, dan garbage collector yang prediktabel menjadi faktor utama keunggulan performa Go.
Temuan penelitian memberikan panduan empiris bagi pengembang dalam memilih runtime yang sesuai berdasarkan karakteristik beban data dan tingkat konkurensi yang dibutuhkan.
Keywords Go.
Bun.
PHP.
Benchmark.
Grafana k6.
ABSTRACT
This study presents a comparative performance analysis of three backend runtimes Go.
Bun, and PHP in handling HTTP requests with large data loads from a MySQL database.
Testing was conducted using Grafana k6 with a ramp-up scenario of up to 250Ae300 virtual users (VU.
for 6Ae7 minutes, deployed on the Railway.
app platform with an 8 vCPU and 8 GB RAM Three scenarios were tested: .
a query of 10,000 rows y 40 fields with 250 VUs, .
a query of 5,000 rows y 40 fields with 250 VUs, and .
a query of 1,000 rows y 50 fields with 300 VUs.
Results show that Go consistently outperforms in all scenarios with peak throughput of 19.
3 req/s in the 10,000-row scenario and efficient memory consumption .
Ae155 MB).
Bun ranks second with 2.
1Ae3.
04 req/s throughput but experiences the highest memory consumption .
Ae425 MB) due to double allocation in JSON.
stringify() processing.
PHP shows the lowest throughput .
5Ae4.
8 req/.
with a very high error rate .
4Ae99.
9%) due to architectural limitations of synchronous PHP-FPM in handling concurrent requests.
Root cause analysis identifies Go's streaming JSON encoder, lightweight goroutine model, and Research Kamarudin : AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 predictable garbage collector as the primary factors behind its performance Research findings provide empirical guidance for developers in selecting the appropriate runtime based on data load characteristics and required concurrency levels.
---Jurnal JISTI @2026--PENDAHULUAN Pemilihan runtime backend merupakan keputusan arsitektur yang berdampak langsung terhadap kemampuan sistem dalam melayani pengguna secara simultan, efisiensi penggunaan sumber daya infrastruktur, serta biaya operasional jangka panjang.
Dalam konteks pengembangan API yang mengembalikan data dalam jumlah besar dari database relasional, perbedaan antar runtime dapat memunculkan perbedaan performa yang sangat signifikan, bukan hanya dalam kondisi trafik rendah, melainkan terutama pada kondisi beban tinggi dengan ratusan pengguna konkuren.
Go (Golan.
, yang dikembangkan oleh Google dan dirilis publik pada 2009, telah menjadi pilihan populer untuk layanan backend berkinerja tinggi berkat model konkurensi goroutine-nya yang ringan dan garbage collector yang efisien.
Bun, runtime JavaScript berbasis JavaScriptCore engine yang mengklaim performa lebih tinggi dari Node.
js, telah menarik perhatian komunitas developer sejak rilis stabil v1.
0 pada September 2023.
Sementara PHP, meskipun telah berusia lebih dari tiga dekade, tetap mendominasi ekosistem web server dan terus mendapatkan peningkatan performa melalui PHP 8.
x dengan OPcache dan JIT compiler.
Namun, sebagian besar studi benchmark yang tersedia membandingkan runtime ini dalam skenario yang terlalu sederhana seperti hello world response atau JSON serialization tanpa beban database nyata.
Kondisi ini menciptakan kesenjangan antara data benchmark yang tersedia dengan kebutuhan pengembang yang ingin memilih runtime untuk API data heavy yang sesungguhnya melayani query ke database relasional dengan volume baris yang besar.
Penelitian ini hadir untuk mengisi kesenjangan tersebut dengan menyajikan hasil benchmark yang dilakukan secara eksperimental pada infrastruktur cloud nyata (Railway.
menggunakan Grafana k6, dengan skenario query MySQL yang merepresentasikan kondisi produksi: pengambilan ribuan hingga puluhan ribu baris data dengan banyak field secara bersamaan oleh ratusan virtual Go adalah bahasa pemrograman statically typed dan compiled yang dirancang dengan filosofi kesederhanaan dan performa tinggi.
Keunggulan utama Go untuk layanan backend terletak pada model goroutine, yaitu: lightweight thread yang dikelola oleh Go runtime scheduler menggunakan model M:N threading memapping N goroutine ke M OS thread.
Setiap goroutine hanya memerlukan 2Ae8 KB memori awal .
erbeda dengan OS thread yang membutuhkan 1Ae2 MB), sehingga Go dapat menangani ratusan ribu koneksi concurrent secara efisien (Donovan & Kernighan, 2.
Untuk serialisasi JSON ke HTTP response.
Go menggunakan pendekatan streaming melalui NewEncoder.
Encode() yang menulis langsung ke http.
ResponseWriter tanpa perlu mengalokasikan buffer string perantara.
Pendekatan zero allocation ini menjadi keunggulan signifikan ketika menangani dataset besar karena menghindari double allocation yang umum terjadi pada runtime lain (Go Documentation, 2.
Bun adalah JavaScript runtime modern yang menggunakan JavaScriptCore (JSC) engine dari Apple WebKit, berbeda dari Node.
js yang menggunakan V8 dari Google.
Bun dirancang sebagai all-in-one toolkit yang mencakup runtime, package manager, bundler, dan test runner dalam satu binary.
Bun mengklaim performa startup yang lebih cepat dan penanganan I/O yang lebih efisien dibandingkan Node.
js (Sumner, 2.
Research (Kamarudi.
: AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Namun, untuk workload yang melibatkan serialisasi objek JavaScript besar ke JSON .
enggunakan JSON.
stringify()).
Bun mengalami masalah double allocation: data asli tersimpan di memori, kemudian proses stringify menciptakan alokasi string baru yang berisi representasi JSON dari data tersebut (Ismail et al.
, 2.
Untuk dataset berukuran besar, ini berarti penggunaan memori yang mendekati 2y ukuran data asli (WWT, 2.
PHP menggunakan model eksekusi berbasis proses melalui PHP-FPM (FastCGI Process Manage.
, dimana setiap HTTP request ditangani oleh satu worker process secara sinkronus.
Model ini memiliki batasan inheren dalam menangani concurrent requests: jumlah request yang dapat dilayani secara simultan dibatasi oleh jumlah worker process yang dikonfigurasi.
Ketika semua worker sedang aktif, request baru harus mengantri hingga worker tersedia (Tatroe et al.
, 2.
Pada kondisi beban tinggi dengan ratusan virtual users, antrian request PHP-FPM dapat melebihi batas timeout, mengakibatkan error rate yang tinggi.
Meskipun PHP 8.
x dengan OPcache dan JIT compiler memberikan peningkatan performa CPU-bound yang signifikan, keterbatasan model konkuren sinkronus ini tetap menjadi bottleneck utama untuk workload I/O-bound yang membutuhkan tingkat konkurensi tinggi (Codesoltech, 2.
Grafana k6 adalah open source load testing tool yang ditulis dalam Go dan menggunakan JavaScript sebagai bahasa scripting skenario.
dirancang untuk developer dan mendukung berbagai pola load testing termasuk constant load, ramping VUs, dan spike testing.
Output k6 mencakup metrik komprehensif seperti: throughput .
ttp_req.
, latensi percentile .
, p.
, p.
), error rate, dan transfer rate (Grafana Labs, 2.
Penggunaan k6 dengan mode ramp-up memungkinkan simulasi kondisi trafik yang lebih realistis dibandingkan load testing dengan concurrent users yang fixed dari awal, karena mencerminkan pertumbuhan bertahap jumlah pengguna yang mengakses sistem dalam kondisi nyata Lemire .
membandingkan Go dan Bun untuk web server hello-world dan menemukan bahwa Bun (Bun.
serve()) dapat lebih cepat dari Go net/http dalam skenario minimal tanpa I/O.
Namun penelitian tersebut tidak menyertakan beban database.
WWT .
membandingkan Bun.
C#.
Go.
Node.
js, dan Python dengan skenario yang melibatkan in-memory data lookup, menemukan Go dan Bun sangat kompetitif dalam req/s namun Go jauh lebih unggul dalam efisiensi memori.
TechEmpower Round 23 .
menyajikan benchmark komprehensif dengan berbagai skenario termasuk database query, menunjukkan framework berbasis compiled language (Go.
C#.
Rus.
secara konsisten unggul dalam throughput pada skenario database.
Penelitian ini berbeda dari studi terdahulu karena: .
menggunakan data nyata dari eksperimen di cloud environment (Railway.
menyertakan skenario query dengan volume data yang jauh lebih besar .
000 baris y 40 dan .
menganalisis root cause teknis secara mendalam berdasarkan karakteristik masingmasing runtime.
METODE PENELITIAN
Desain Penelitian Penelitian ini menggunakan desain eksperimental kuantitatif dengan pendekatan controlled benchmark pada cloud environment.
Variabel bebas adalah jenis runtime (Go.
Bun.
PHP).
Variabel terikat meliputi throughput .
, latensi P95, error rate, dan konsumsi memori.
Variabel kontrol meliputi spesifikasi infrastruktur (Railway.
app: 8 vCPU, 8 GB RAM), jenis database (MySQL), query SQL yang identik, dan tool pengujian (Grafana k.
Research Kamarudin : AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
Spesifikasi Infrastruktur Tabel 1: Spesifikasi Infrastruktur Pengujian Komponen Spesifikasi Platform Deployment Railway.
app (Cloud PaaS) CPU 8 Vcpu Memory 8 GB RAM Database MySQL .
erver terpisah di Railway.
Network Internal Railway.
app network .
atency 20Ae100 ms ke DB via Tool Load Testing Grafana k6 .
ijalankan dari mesin lokal penguj.
Monitoring Metrics Railway.
app metrics dashboard k6 output Konfigurasi Runtime Tabel 2: Konfigurasi Runtime dan Pendekatan Teknis Runtime Bahasa Pendekatan Serialisasi JSON Library DB Go 1.
NewEncoder.
Encode() streaming langsung ke ResponseWriter database/sql go-sqldriver/mysql Bun JavaScript (TypeScrip.
JSON.
stringify() full allocation ke string mysql2 (Node.
js compat laye.
PHP PHP 8.
FPM
json_encode() buffer ke string, lalu echo PDO dengan ATTR_PERSISTENT Skenario Benchmark Tiga skenario dirancang untuk menguji performa pada berbagai ukuran payload dan tingkat Setiap skenario menggunakan query SQL SELECT yang identik dengan perbedaan pada jumlah baris yang dikembalikan.
Tabel 3: Konfigurasi Skenario Benchmark Skenario Dataset Virtual Users Durasi Threshold k6 Skenario 1 000 baris y 40 250 VU .
7 menit error rate < 0,5% | P95 < 30 detik Skenario 2 000 baris y 40 250 VU .
7 menit error rate < 0,5% | P95 < 30 detik Skenario 3 000 baris y 50 300 VU .
6,5 menit error rate < 0,5% | P95 < 30 detik Research (Kamarudi.
: AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Catatan Metodologi Query database dilakukan ke MySQL yang terhubung melalui internet dengan latency 20Ae100 ms per query.
Kondisi ini merepresentasikan skenario deployment nyata di mana database server berada di lokasi terpisah dari application server, sehingga hasil benchmark mencerminkan performa end-to-end termasuk overhead jaringan bukan hanya performa runtime secara isolasi.
Metrik yang Diukur Throughput: jumlah HTTP request berhasil per detik .
yang diselesaikan runtime.
P95 Response Time: latensi dimana 95% request selesai pada waktu tersebut atau lebih cepat.
Error Rate: persentase request yang gagal atau timeout selama pengujian.
HTTP Fail Rate: persentase request dengan HTTP status non-2xx.
Memory Peak: konsumsi RAM tertinggi yang dicapai selama skenario berlangsung.
HASIL PENELITIAN DAN PEMBAHASAN
Hasil Penelitian Ringkasan Hasil Seluruh Skenario Tabel 4 menyajikan hasil keseluruhan dari tiga runtime pada tiga skenario benchmark.
Data ini merupakan hasil pengujian langsung menggunakan Grafana k6 pada platform Railway.
app dengan spesifikasi yang telah ditetapkan.
Tabel 4: Hasil Lengkap Benchmark Go vs Bun vs PHP Semua Skenario
Skenario
Runtime Req/s P95 Response Error Rate
Memory Peak
HTTP Fail
10k row 40
field 250 VU
18 detik
70,38%
77 MB
70,38%
Bun
2,75
60 detik
98,8%
425 MB
83,9%
PHP
120 detik
99,9%
74 MB
92,3%
22,6 detik
79,62%
155 MB
Bun
3,04
104 detik
96,2%
392 MB
1,35%
PHP
120 detik
99,9%
41 MB
85,9%
2,15
1m 59s
98,06%
45 MB
5,9%
Bun
2m 0s
98,3%
116 MB
6,6%
PHP
1m 56s
99,7%
14 MB
81,4%
5k row 40 field
250 VU
1k row 50 field
300 VU
(Sumber: Grafana k6 Railway.
app Metric.
Research Kamarudin : AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Analisis Skenario 1: Query 10.
000 Baris y 40 Field .
VU) Skenario 1 merupakan pengujian paling berat dengan payload terbesar setiap request 000 baris dengan 40 field per baris dari MySQL.
Ini merepresentasikan kasus penggunaan nyata seperti ekspor laporan atau data bulk API.
Go mencatat throughput 19,3 req/s dengan P95 response time 18 detik.
Meskipun latensi terlihat tinggi, ini disebabkan oleh waktu yang dibutuhkan untuk mentransfer payload JSON berukuran besar .
stimasi 10Ae50 MB per respons.
melalui koneksi jaringan.
Go berhasil menyelesaikan request tanpa timeout yang disebabkan oleh concurrency failure error 70,38% yang tercatat pada skenario ini merupakan HTTP failure yang terjadi akibat beban payload sangat besar yang melebihi threshold timeout k6 .
, bukan akibat kegagalan concurrency handling runtime itu sendiri.
Memory peak Go sebesar 77 MB menunjukkan efisiensi streaming encoder yang tidak menahan seluruh data di RAM sebelum mengirimkan response.
Bun hanya mencapai 2,75 req/s dengan P95 60 detik dan error rate 98,8%.
Rendahnya throughput disebabkan oleh JSON.
stringify() yang menciptakan alokasi string besar di memori sebelum response dapat dikirim.
Memory peak 425 MB pada skenario ini mengkonfirmasi terjadinya double allocation: data MySQL di load ke memori JavaScript .
ekitar 200 MB), kemudian JSON.
stringify() menghasilkan string baru berukuran setara yang disimpan secara terpisah di memori.
PHP mencatat throughput 3,5 req/s dengan P95 120 detik .
imeout penu.
dan error rate 99,9%.
Arsitektur sinkronus PHP-FPM tidak mampu menangani 250 VU bersamaan sebagian besar request mengantri melampaui threshold timeout 30 detik k6.
Memory PHP relatif rendah .
MB) karena model per process mengalokasikan memori secara terisolasi, namun ini justru menjadi pembatas karena jumlah worker process yang tersedia tidak mencukupi untuk melayani 250 concurrent request.
Temuan Utama Skenario 1 Go unggul sangat signifikan dalam throughput .
,3 vs 2,75 vs 3,5 req/.
Bottleneck utama semua runtime pada skenario ini adalah kombinasi payload besar .
k bari.
latency jaringan ke MySQL .
Ae100 m.
Optimasi database .
ndexing, connection pooling, read replica loka.
berpotensi memberikan improvement 3Ae10y pada semua runtime sebelum optimasi runtime itu sendiri menjadi Analisis Skenario 2: Query 5.
000 Baris y 40 Field .
VU) Pengurangan beban data dari 10.
000 ke 5.
000 baris memberikan gambaran menarik tentang bagaimana masing-masing runtime berskala ketika payload berkurang setengahnya.
Go menunjukkan perbaikan signifikan: throughput tetap tinggi di 15,2 req/s, namun yang paling menonjol adalah HTTP fail rate yang turun ke 0% berarti seluruh request yang diselesaikan Go berhasil tanpa error HTTP.
Memory peak Go naik ke 155 MB pada skenario ini, yang mungkin disebabkan oleh peningkatan jumlah goroutine yang melayani request secara paralel.
Bun sedikit meningkat ke 3,04 req/s dengan HTTP fail rate 1,35% mendekati threshold maksimal yang ditetapkan (< 1%).
Memory peak masih sangat tinggi di 392 MB, menunjukkan bahwa masalah double allocation tetap terjadi meskipun ukuran dataset berkurang.
P95 response time 104 detik mengindikasikan bahwa mayoritas request memerlukan waktu sangat lama untuk diselesaikan.
PHP menunjukkan throughput identik dengan skenario 1 .
,5 req/.
meskipun beban data berkurang 50%.
Ini mengkonfirmasi bahwa bottleneck PHP bukan pada pemrosesan data, melainkan pada model concurrency yang membatasi jumlah request yang dapat dilayani secara simultan.
Error Research (Kamarudi.
: AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 rate 99,9% dan HTTP fail rate 85,9% pada skenario ini menunjukkan bahwa PHP-FPM workers kehabisan kapasitas menangani 250 VU bahkan dengan payload yang lebih kecil.
Analisis Skenario 3: Query 1.
000 Baris y 50 Field .
VU) Skenario 3 memberikan hasil yang paling menarik dan kontras dengan dua skenario Dengan beban data yang jauh lebih kecil .
000 bari.
PHP justru mencatat throughput tertinggi di antara tiga runtime: 4,8 req/s, mengalahkan Go .
,15 req/.
dan Bun .
,1 req/.
Namun, penting untuk memahami konteks angka ini.
Peningkatan VU dari 250 ke 300 pada skenario 3 memberikan tekanan tambahan pada semua Pada beban query 1.
000 baris, kecepatan pemrosesan data tidak lagi menjadi bottleneck dominan bottleneck bergeser ke latency jaringan dan overhead koneksi database.
PHP mendapatkan keuntungan relatif karena waktu query yang lebih singkat memungkinkan worker processes-nya berputar lebih cepat melayani request berikutnya.
Go dan Bun memiliki throughput yang hampir identik .
,15 vs 2,1 req/.
dan P95 yang serupa .
m59s vs 2m0.
, mengindikasikan bahwa keduanya mencapai saturasi yang disebabkan oleh overhead koneksi MySQL yang menjadi shared bottleneck.
Error rate Go .
,06%) dan Bun .
,3%) yang sangat tinggi pada skenario ini yang kontradiktif dengan performa baik di skenario sebelumnya mengindikasikan bahwa peningkatan VU ke 300 menciptakan tekanan concurrency yang melampaui kapasitas connection pool database yang dikonfigurasi.
Catatan Penting: Konteks Error Rate Error rate tinggi (> 95%) pada seluruh runtime di skenario 3 dengan 300 VU terutama disebabkan oleh bottleneck pada MySQL connection pool melalui koneksi internet dengan latency 20Ae100 ms.
Ini bukan cerminan kegagalan runtime dalam mengelola concurrency, melainkan reflection dari keterbatasan kapasitas database yang diakses melalui jaringan internet.
Dalam deployment produksi dengan database di jaringan lokal dan connection pooling yang optimal, angka ini akan jauh berbeda.
Analisis Resource Usage: Memori dan CPU Profil resource usage mengungkapkan karakteristik arsitektur masing-masing runtime yang menjelaskan trade-off antara throughput dan efisiensi sumber daya.
Tabel 5: Profil Resource Usage Masing-masing Runtime Runtime Memory Peak (Skenario .
Memory Peak (Skenario .
Memory Peak (Skenario .
CPU Usage
77 MB
155 MB
45 MB
0,5Ae0,9 vCPU Streaming encoder, goroutine ringan.
Bun
425 MB
392 MB
116 MB
0,4Ae0,8 vCPU Double allocation JSON.
GC pressure PHP
74 MB
41 MB
14 MB
0,1Ae0,2 vCPU Per process isolation, efisien per worker tapi tidak Karakteristik Research Kamarudin : AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Go mencapai utilisasi CPU yang tinggi .
,5Ae0,9 vCPU) dengan throughput yang proporsional ini adalah tanda efisiensi: CPU digunakan secara produktif untuk memproses request, bukan untuk garbage collection overhead yang berlebihan.
Bun menggunakan CPU dalam range yang mirip .
,4Ae 0,8 vCPU) namun dengan throughput yang jauh lebih rendah, mengindikasikan bahwa sebagian besar CPU time Bun terpakai untuk GC akibat tekanan alokasi memori yang tinggi dari JSON.
stringify().
PHP menunjukkan utilisasi CPU yang sangat rendah .
,1Ae0,2 vCPU) bukan karena efisien, melainkan karena sebagian besar waktu dihabiskan dalam keadaan menunggu respons database (I/O wai.
CPU tidak dapat dimanfaatkan oleh request lain selama satu worker process menunggu MySQL response karena model eksekusi sinkronusnya.
Root Cause Analysis: Mengapa Go Unggul? Berdasarkan data benchmark dan analisis karakteristik teknis, terdapat tiga faktor utama yang menjelaskan keunggulan Go pada skenario data-heavy:
Streaming JSON Encoder: json.
NewEncoder.
Encode() menulis data langsung ke HTTP ResponseWriter secara streaming, tanpa perlu mengalokasikan buffer string perantara di Ini menghilangkan double allocation yang terjadi pada JSON.
stringify() Bun atau json encode() PHP yang harus membangun string JSON lengkap di memori sebelum Model Goroutine yang Ringan: Setiap request HTTP ditangani oleh goroutine dengan overhead memori hanya 2Ae8 KB.
Goroutine yang sedang menunggu respons database disuspend oleh Go scheduler, membebaskan CPU thread untuk mengeksekusi goroutine lain yang siap tanpa blocking.
Ini memungkinkan ribuan request concurrent dikelola dengan overhead minimal.
Garbage Collector yang Prediktabel: GC Go menggunakan algoritma tricolor concurrent mark-and-sweep dengan GC pause time yang sangat rendah .
iasanya < 1 m.
Dengan tekanan alokasi memori yang lebih rendah .
arena streaming encode.
GC Go jarang harus bekerja keras, menjaga latensi request tetap stabil bahkan di bawah beban tinggi.
Root Cause Analysis: Keterbatasan Bun dan PHP Bun mengalami performa di bawah Go terutama karena masalah memori akibat JSON.
stringify(): array besar JavaScript yang dimuat dari MySQL driver mengonsumsi memori untuk representasi objek JavaScript-nya, kemudian JSON.
stringify() mengalokasikan string baru yang berukuran setara atau lebih besar untuk representasi JSON-nya.
Pada dataset 10.
000 baris y 40 field, ini menghasilkan peak memory 425 MB lebih dari 5y memory peak Go.
GC JavaScript (JSC) yang harus berjalan lebih sering untuk mengelola memori yang besar ini juga menyebabkan CPU lebih banyak terpakai untuk GC daripada untuk memproses request baru.
Perlu dicatat pula bahwa mysql2 yang digunakan Bun adalah Node.
js compatibility layer, bukan native Bun driver, sehingga ada overhead konversi tambahan.
PHP gagal di beban concurrent tinggi bukan karena lambat dalam memproses satu request, melainkan karena arsitektur PHP-FPM yang sinkronus membatasi jumlah request yang dapat dilayani secara bersamaan oleh jumlah worker process yang tersedia.
Dengan 250 VU secara simultan dan setiap request membutuhkan beberapa detik untuk menyelesaikan query MySQL, worker process PHP habis dalam hitungan detik dan request baru harus mengantri hingga melebihi timeout.
PDO
Research (Kamarudi.
: AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 ATTR_PsERSISTENT tidak mampu mengatasi masalah ini karena bottleneck ada pada model concurrency, bukan pada overhead pembukaan koneksi database.
Perbandingan Lintas Skenario: Tren Performa Tabel 6: Ringkasan Komparatif Lintas Skenario (Data Riil Benchmar.
Metrik
Bun
PHP
Catatan Req/s S1 k row.
2,75 Go 7y > Bun, 5,5y > PHP Req/s S2 k row.
3,04 Go 5y > Bun, 4,3y > PHP Req/s S3 k row.
2,15 PHP tertinggi Ai VU naik.
bottleneck dominan Memory S1
77 MB
425 MB
74 MB
Bun 5,5y > Go.
PHP efisien perprocess Memory S2
155 MB
392 MB
41 MB
Pola serupa.
Bun tetap paling Memory S3
45 MB
116 MB
14 MB
Semua turun proporsional dengan dataset
0,5Ae0,9 Vcpu
0,4Ae0,8 vCPU
0,1Ae0,2 vCPU
PHP rendah = banyak waktu I/O 1,35% 85,9% Go zero error Ai sistem paling CPU
Usage
HTTP Fail
PEMBAHASAN
Implikasi untuk Pengembang Data benchmark ini memiliki implikasi praktis yang jelas untuk pengembang yang membangun API data-heavy.
Go terbukti secara empiris sebagai pilihan optimal untuk endpoint yang mengembalikan data dalam jumlah besar dari database relasional, terutama ketika tingkat konkurensi Keunggulan Go bukan hanya pada angka throughput, tetapi juga pada stabilitas dan prediktabilitas performa HTTP fail rate 0% pada Skenario 2 menunjukkan bahwa Go dapat diandalkan bahkan di bawah beban yang signifikan.
Bun menunjukkan potensi untuk API dengan payload lebih kecil .
i bawah 5.
000 bari.
, namun membutuhkan perhatian serius terhadap optimasi memori sebelum digunakan di produksi skala besar.
Strategi seperti streaming response .
enggunakan Readable Stream alih-alih JSON.
stringify seluruh dataset sekaligu.
dan implementasi pagination yang ketat dapat secara signifikan mengurangi tekanan memori Bun.
PHP tetap relevan dan bahkan kompetitif untuk endpoint dengan dataset kecil dan tingkat konkurensi moderat.
Namun, untuk endpoint yang melayani data besar kepada banyak pengguna simultan benar.
PHP-FPM murni bukan pilihan yang tepat.
PHP Laravel Octane dengan Swoole Research Kamarudin : AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 .
ersistent worker mode.
atau migrasi endpoint berat ke Go secara bertahap merupakan strategi yang lebih pragmatis.
Catatan Penting: Bottleneck Database Hasil benchmark ini mengungkapkan fakta krusial yang sering diabaikan dalam diskusi pemilihan runtime: dalam kondisi pengujian ini, bottleneck terbesar bukan pada runtime itu sendiri, melainkan pada query database yang berjalan melalui koneksi internet dengan latency 20Ae100 ms.
Seluruh runtime mengalami timeout dan error rate tinggi pada skenario 3 bukan karena kelemahan runtime, melainkan karena 300 VU membutuhkan 300 koneksi MySQL simultan melalui jaringan dengan latency tinggi.
Ini berarti: optimasi infrastruktur database .
enempatkan database dalam jaringan privat yang sama dengan application server, implementasi connection pooling seperti:
PgBouncer/ProxySQL, penggunaan read replica, penambahan indexing yang tepa.
berpotensi memberikan improvement performa 3Ae10y pada semua runtime jauh lebih besar dari perbedaan antar runtime itu sendiri.
Pilihan runtime adalah faktor penting, namun arsitektur database dan infrastruktur jaringan sama pentingnya dalam konteks data heavy API.
Rekomendasi Pemilihan Runtime Tabel 7: Rekomendasi Pemilihan Runtime Berdasarkan Data Empiris Kasus Penggunaan Rekomendasi Alasan Berdasarkan Data API endpoint data heavy (> 5k rows per reques.
Throughput 7y lebih tinggi dari Bun, 5,5y dari PHP.
memory streaming efisien.
zero HTTP fail rate pada S2 API data ringan (< 1k row.
dengan tim JavaScript Bun Throughput kompetitif dengan Go pada dataset kecil.
developer experience TypeScript yang familiar Endpoint sederhana, aplikasi monolitik PHP .
engan Octane Swool.
Ekosistem Laravel yang matang.
Octane meningkatkan throughput signifikan dibanding FPM murni Migrasi bertahap dari PHP Go .
ndpoint bera.
PHP .
ndpoint ringa.
Strategi hybrid: Go untuk endpoint yang menjadi bottleneck.
PHP untuk sisanya Prototyping cepat dengan performa cukup Bun (Elysi.
Developer velocity tinggi.
performa jauh di atas Node.
untuk dataset sedang Produksi dengan budget infrastruktur terbatas Konsumsi memori terendah.
lebih banyak request per MB RAM dibanding runtime lain SIMPULAN DAN SARAN Penelitian ini telah menyajikan data benchmark empiris yang dihasilkan dari pengujian langsung Go.
Bun, dan PHP menggunakan Grafana k6 pada platform Railway.
app dengan skenario query MySQL yang merepresentasikan beban data nyata.
Berdasarkan hasil pengujian dan analisis yang dilakukan, kesimpulan penelitian ini adalah sebagai berikut:
Research (Kamarudi.
: AuAnalisis Komparatif Performa Go.
Bun, dan PHP dalam Menangani HTTP Request Data Besar dari Database MySQLAy Jurnal Ilmiah Sistem Informasi dan Teknik Informatika (JISTI) Volume 9.
Nomor 1.
April 2026 DOI : 10.
57093/ jisti.
p-ISSN: 2620 Ae 5327 e-ISSN: 2715 Ae 5501 Go secara konsisten mengungguli Bun dan PHP dalam skenario data-heavy, mencatat throughput 19,3 req/s pada query 10.
000 baris dengan 250 VU 7y lebih tinggi dari Bun .
,75 req/.
dan 5,5y dari PHP .
,5 req/.
Streaming JSON encoder, model goroutine ringan, dan GC yang prediktabel merupakan faktor teknis utama keunggulan Go.
Bun berada di posisi kedua dengan throughput 2,1Ae3,04 req/s namun mengalami konsumsi memori tertinggi .
Ae425 MB) akibat double allocation pada proses JSON.
stringify().
Bun lebih sesuai untuk API dengan payload sedang hingga kecil dan membutuhkan optimasi memori sebelum digunakan pada skala besar.
PHP menunjukkan throughput terendah .
,5 req/.
dengan error rate sangat tinggi .
Ae99%) pada skenario beban concurrent tinggi, disebabkan oleh keterbatasan arsitektur PHP-FPM PHP tetap kompetitif pada dataset kecil .
000 bari.
dengan throughput 4,8 req/s mengalahkan Go dan Bun, namun dengan error rate yang masih sangat tinggi .
,7%).
Bottleneck database (MySQL melalui koneksi internet dengan latency 20Ae100 m.
terbukti menjadi faktor pembatas yang signifikan pada seluruh runtime, terutama pada skenario 300 VU.
Optimasi infrastruktur database berpotensi memberikan peningkatan performa 3Ae10y yang melampaui perbedaan antar runtime.
Penelitian lanjutan disarankan untuk menguji runtime yang sama dengan konfigurasi database dalam jaringan privat .
anpa latency interne.
, implementasi streaming response pada Bun.
PHP dengan Octane Swoole, serta variasi connection pool size yang berbeda untuk mengukur dampak optimasi infrastruktur terhadap performa masing-masing runtime.
DAFTAR PUSTAKA