Load Testing Aplikasi Absensi Karyawan Saat Jam Masuk Kerja

Pukul 07.55 WIB adalah "jam keramat" bagi manajemen operasional perusahaan dan kampus di Indonesia. Dalam rentang waktu singkat 15 hingga 20 menit, ratusan bahkan ribuan pengatur jadwal, dosen, staf, dan pekerja mencoba mengakses aplikasi absensi karyawan secara bersamaan untuk melakukan clock-in. Jika sistem tidak dirancang untuk menangani lonjakan lonjakan lalu lintas (traffic spike) ini, aplikasi akan melambat, menampilkan eror 504 Gateway Timeout, atau bahkan lumpuh total (crash).

Masalah ini bukan sekadar kendala teknis kecil. Ketika sistem absensi mati pada jam masuk kerja, dampaknya langsung terasa pada ketertiban operasional, perhitungan kompensasi, hingga tingkat kepercayaan pengguna terhadap tim IT atau penyedia solusi digital yang Anda tunjuk.

---

Mengapa Aplikasi Absensi Karyawan Sering Lumpuh di Jam Masuk Kerja?

Banyak pemilik bisnis dan pengelola kampus berasumsi bahwa server berkapasitas sedang sudah cukup untuk menangani 1.000 pengguna. Logikanya: "User kita hanya 1.000 orang, kenapa server seharga Rp 2.000.000 per bulan masih down?"

Penyebab utamanya adalah pola penggunaan yang tidak merata. Tidak seperti platform e-commerce di mana pengguna datang dan pergi sepanjang hari, sistem absensi menerima beban hampir 80% dari total pengguna harian dalam kurun waktu 10–15 menit menjelang batas jam masuk.

Secara teknis, kemacetan ini biasanya dipicu oleh tiga faktor utama:

1. Pemrosesan Data Berat dalam Waktu Bersamaan Sistem absensi modern tidak hanya mencatat waktu, tetapi juga memverifikasi koordinat GPS (geofencing), memproses swafoto (selfie), dan menjalankan alur pengenalan wajah (face recognition). Semua proses ini membutuhkan pemrosesan CPU dan memori yang tinggi.
2. Keterbatasan Sambungan Database (Database Connection Pool Exhaustion) Ketika 500 pengguna menekan tombol clock-in pada detik yang sama, aplikasi mencoba membuka 500 koneksi bersamaan ke database. Jika batas konfigurasi database hanya 100 koneksi, sisanya akan masuk dalam antrean (queue) hingga batas waktu habis (timeout).
3. Ukuran Berkas Gambar yang Tidak Dioptimalkan Jika pengguna mengunggah foto absensi berukuran 5 MB langsung dari kamera smartphone tanpa kompresi di sisi klien (client-side compression), bandwidth server akan dengan cepat habis hanya untuk menerima transfer berkas.

---

Berapa Kerugian Finansial Akibat Sistem Absensi yang Crash?

Mari kita hitung dengan skenario nyata pada perusahaan dengan 1.000 karyawan dan rata-rata gaji Rp 6.000.000 per bulan (sekitar Rp 35.000 per jam per karyawan).

Jika aplikasi absensi mati selama 30 menit pada jam masuk kerja:

• Waktu kerja yang hilang: $1.000 \text{ karyawan} \times 0.5 \text{ jam} = 500 \text{ jam kerja}$.
• Kerugian biaya langsung: $500 \text{ jam} \times \text{Rp } 35.000 = \mathbf{\text{Rp } 17.500.000}$ dalam satu pagi saja.

Di luar angka tersebut, ada biaya tidak terlihat: tim HR terpaksa memproses absensi secara manual, antrean fisik menumpuk di depan gerbang atau pos satpam, dan produktivitas awal hari terganggu secara signifikan.

---

Apa Itu Load Testing dan Bagaimana Cara Kerja Simulasinya?

Load testing adalah metode pengujian beban di mana kita mensimulasikan ratusan hingga ribuan pengguna virtual (virtual users) yang mengakses aplikasi secara bersamaan. Tujuan utamanya adalah menemukan batas maksimal kemampuan sistem sebelum aplikasi diluncurkan (go-live) atau digunakan secara massal.

Berbeda dengan functional testing yang hanya menguji apakah tombol absensi berfungsi, load testing menguji sejauh mana sistem bertahan saat diserbu pengguna.

Contoh Script Simulasi Menggunakan k6

Sebagai gambaran bagi tim teknis Anda, pengujian beban dapat dilakukan menggunakan alat populer seperti k6 atau Apache JMeter. Berikut adalah contoh skrip sederhana menggunakan k6 untuk mensimulasikan 500 pengguna yang melakukan clock-in dalam rentang waktu 1 menit:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 100 }, // Naik ke 100 pengguna dalam 30 detik
    { duration: '1m', target: 500 },  // Melonjak ke 500 pengguna bersamaan
    { duration: '30s', target: 0 },   // Turun kembali ke 0
  ],
  thresholds: {
    http_req_duration: ['p(95)<2000'], // 95% request harus selesai di bawah 2 detik
    http_req_failed: ['rate<0.01'],    // Tingkat eror harus di bawah 1%
  },
};

export default function () {
  const url = 'https://api.absensi-kampus.ac.id/v1/clock-in';
  const payload = JSON.stringify({
    user_id: 'USR-8921',
    latitude: -6.2088,
    longitude: 106.8456,
    photo_base64: 'data:image/jpeg;base64,...', // simulasi gambar
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer token-simulasi-123',
    },
  };

  const res = http.post(url, payload, params);

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 2s': (r) => r.timings.duration < 2000,
  });

  sleep(1);
}

Dari hasil simulasi di atas, tim pengembang dapat melihat metrik utama:

• Response Time (p95/p99): Berapa lama mayoritas pengguna menunggu hingga proses absensi berhasil.
• Error Rate: Berapa persen permintaan yang gagal akibat server overload.
• Throughput (RPS): Berapa banyak Request Per Second yang sanggup dilayani oleh infrastruktur saat ini.

---

Strategi Arsitektur: Solusi Hemat Tanpa Beli Server Mahal

Banyak organisasi mengira solusi dari masalah ini adalah langsung menyewa server terbesar di penyedia cloud dengan biaya belasan juta Rupiah per bulan. Padahal, sering kali masalahnya terletak pada arsitektur aplikasi yang kurang efisien.

Berikut adalah strategi teknis yang ramah anggaran untuk mengoptimalkan sistem absensi:

1. Gunakan Pemrosesan Asinkron (Asynchronous Processing)

Jangan paksa pengguna menunggu proses face recognition atau ekstraksi metadata foto selesai di tempat.

• Pola Lama: User klik submit -> Server proses foto + AI -> Simpan DB -> Kirim response (memakan waktu 3–5 detik per orang).
• Pola Asinkron: User klik submit -> Simpan foto sementara di Message Queue seperti RabbitMQ atau Redis -> Kirim respons "Absensi Diterima" (memakan waktu < 0,5 detik). Proses validasi wajah dilakukan di latar belakang (background worker).

2. Kompresi Foto di Sisi Klien (Client-Side Compression)

Manfaatkan daya proses smartphone pengguna untuk mengecilkan foto sebelum dikirim ke server. Foto berukuran 4 MB bisa dikompres menjadi 150 KB di aplikasi mobile tanpa mengurangi kualitas visual untuk verifikasi HR. Ini menghemat penggunaan bandwidth server hingga 95%.

3. Terapkan Caching untuk Data Statis

Data seperti nama kantor, radius koordinat lokasi kerja, dan jadwal kerja harian tidak perlu selalu ditarik dari database utama (relational DB). Simpan data ini di in-memory cache seperti Redis agar akses data jauh lebih cepat.

---

Checklist Sebelum Go-Live untuk Manajemen dan Tim IT

Sebelum Anda meluncurkan aplikasi absensi baru atau memperbarui sistem yang ada, pastikan vendor atau tim internal Anda telah melewati pemeriksaan berikut:

• Uji Beban Puncak: Jalankan simulasi dengan beban minimal 1,5 kali lipat dari total jumlah karyawan/mahasiswa aktif.
• Batas Waktu Toleransi: Pastikan response time rata-rata di bawah 2 detik pada saat beban puncak.
• Rencana Skalabilitas Auto (Auto-scaling): Konfigurasikan instance cloud (seperti AWS, Google Cloud, atau Cloud Provider lokal) agar dapat menambah kapasitas CPU secara otomatis saat traffic melonjak jam 07.30 WIB dan mengecil kembali di jam 09.00 WIB untuk menghemat biaya operational.
• Skenario Graceful Degradation: Jika sistem mengalami kendala beban ekstrim, pastikan aplikasi memiliki fitur darurat (misalnya: mematikan sementara fitur verifikasi wajah dan beralih ke absensi berbasis GPS saja) agar fungsi utama pencatatan waktu tetap berjalan.

---

Langkah Selanjutnya

Mengembangkan sistem digital untuk bisnis atau kampus memerlukan perencanaan matang yang mempertimbangkan tidak hanya tampilan antarmuka, tetapi juga ketahanan infrastruktur di saat-saat krusial.

Jika Anda sedang berencana membangun atau memperbarui sistem informasi operasional, pastikan untuk melakukan audit performa dan load testing sejak tahap pengembangan. Tinjau kembali arsitektur sistem Anda bersama tim pengembang atau konsultan teknologi berpengalaman untuk memastikan aplikasi dapat melayani pengguna dengan cepat, stabil, dan efisien setiap harinya.

Baca juga: Jasa optimasi kecepatan website