Sebuah eksperimen pengujian beban terbaru yang meneliti berapa banyak permintaan HTTP per detik yang dapat ditangani oleh satu mesin telah memicu diskusi komunitas tentang pilihan penyimpanan database, connection pooling, dan batas sesungguhnya dari perangkat keras modern. Pengujian menggunakan setup dasar dengan PostgreSQL yang berisi lebih dari satu juta record dan mengukur performa di berbagai profil beban.
Konfigurasi Database:
- PostgreSQL dengan 1+ juta record
- Hikari Connection Pool : 10 koneksi awal, dapat diperluas hingga 20
- External DigitalOcean Block Storage (bukan filesystem lokal)
- Batas koneksi default PostgreSQL : ~100 koneksi
Konfigurasi Penyimpanan Database Menimbulkan Pertanyaan
Setup pengujian menggunakan block storage eksternal untuk database daripada penyimpanan filesystem lokal, yang menarik perhatian banyak developer. Pilihan ini secara signifikan berdampak pada performa karena block storage memperkenalkan latensi jaringan untuk setiap operasi database. Anggota komunitas menunjukkan bahwa menggunakan apapun selain filesystem lokal untuk database umumnya tidak disarankan untuk aplikasi yang kritis terhadap performa.
Namun, lingkungan cloud sering memerlukan trade-off ini. Block storage menyediakan keandalan dan persistensi data ketika instance dapat gagal kapan saja, sementara penyimpanan lokal menawarkan performa yang lebih baik tetapi berisiko kehilangan data. Ketegangan fundamental antara performa dan keandalan ini membentuk banyak keputusan arsitektural dalam aplikasi modern.
Keterbatasan Connection Pool Menjadi Terlihat
Pengujian mengungkap bottleneck dalam penanganan koneksi database, dengan setup menggunakan Hikari Connection Pool yang dikonfigurasi untuk 10 koneksi awal yang dapat diperluas hingga 20. Analisis komunitas menunjukkan bahwa ukuran connection pool yang relatif kecil ini kemungkinan membatasi performa sebelum mencapai batas perangkat keras yang sebenarnya.
Batas koneksi default PostgreSQL sekitar 100 koneksi bersamaan seharusnya memberikan ruang yang cukup ketika di-pool dengan benar. Diskusi menyoroti bahwa dengan ribuan permintaan potensial per detik, ukuran connection pool menjadi kritis untuk menghindari bottleneck buatan.
Perspektif Perangkat Keras Menantang Asumsi
Pengujian menggambarkan mesin 8-CPU, 16GB RAM sebagai besar, yang mendapat kritik dari developer yang familiar dengan kemampuan perangkat keras modern. Mesin konsumen high-end hari ini dapat mendukung 512GB RAM, sementara sistem enterprise dapat mencapai 20+ terabyte memori dan ratusan core.
Mesin besar hari ini memiliki 20+ TB RAM dan ratusan core. Bahkan mesin konsumer top-end dapat memiliki 512GB RAM!
Gap perspektif ini menunjukkan bahwa banyak aplikasi dapat berkembang jauh melampaui asumsi saat ini dengan hanya mengupgrade ke mesin tunggal yang lebih powerful daripada mengadopsi arsitektur terdistribusi yang kompleks.
Konfigurasi Mesin Uji:
- Mesin kecil: 4 core CPU, memori 4 GiB
- Mesin menengah: 4 vCPU, memori 4 GiB
- Mesin besar: 8 vCPU, memori 4 GiB
- Mesin "besar sekali": 8 CPU, memori 16 GB
Keterbatasan Metodologi Pengujian
Pendekatan load testing menggunakan pembatasan rate buatan dalam kode klien, yang diidentifikasi oleh beberapa anggota komunitas sebagai berpotensi menyimpangkan hasil. Pengujian sengaja membatasi permintaan per detik daripada mengukur throughput maksimum yang berkelanjutan, membuatnya sulit untuk menentukan batas performa yang sesungguhnya.
Selain itu, menjalankan aplikasi dan database pada mesin yang sama menciptakan kontention sumber daya yang tidak akan ada dalam deployment produksi yang tipikal. Meskipun ini menguji sistem lengkap di bawah keterbatasan sumber daya, ini tidak mengisolasi performa application server dari performa database.
Eksperimen menunjukkan bahwa mesin tunggal dapat menangani beban yang substansial, tetapi angka-angka spesifik mungkin tidak mencerminkan konfigurasi yang dioptimalkan. Untuk banyak aplikasi yang saat ini menggunakan arsitektur microservices kompleks untuk menangani hanya beberapa permintaan per detik, bahkan hasil konservatif ini menunjukkan bahwa solusi yang lebih sederhana bisa mencukupi.
Referensi: Load Testing: how many HTTP requests/second can a Single Machine handle?