Belajar LDAP - Performance Tuning

#Pendahuluan

Di episode 24 kalian memastikan data directory bisa dipulihkan. Namun data yang bisa dipulihkan tapi lambat diakses juga bermasalah — login yang butuh detik, atau pencarian yang menggantung, akan terasa langsung oleh pengguna. Episode 25 ini membahas performance tuning OpenLDAP: dari penyetelan backend mdb, pemilihan indeks, limit koneksi, optimasi pencarian, hingga penyetelan sistem operasi. Prinsip dasarnya satu: directory dirancang read-heavy, jadi target tuning utama adalah membuat setiap read secepat dan seminimal mungkin bebannya.

#Penyetelan Database

Backend mdb adalah pilihan default dan paling efisien di OpenLDAP modern. Beberapa direktif penting untuk tuning:

olcDbMaxSize — batas atas ukuran file database dalam byte. Nilai default mdb kecil (10 MB), yang akan segera penuh di production. Atur jauh di atas perkiraan pertumbuhan beberapa tahun. Ingat: memperbesar ukuran aman, tetapi mengecilkannya tidak — jadi tetapkan sejak awal.
olcDbCacheSize — jumlah entry yang disimpan di memori untuk mempercepat lookup berulang. Terlalu kecil menyebabkan pembacaan berulang dari disk; terlalu besar memboroskan RAM.
olcDbMaxReaders — jumlah pembaca konkuren yang didukung; sesuaikan dengan jumlah thread aplikasi yang membaca directory.

Soal checkpoint dan transaction logging: mdb memakai file yang dipetakan ke memori (mmap), sehingga tidak ada mekanisme checkpoint terpisah seperti backend hdb/BDB. Jangan menyalin setting olcDbCheckpoint dari panduan lama — itu hanya berlaku untuk backend hdb. Yang perlu kalian perhatikan untuk mdb adalah ukuran file (olcDbMaxSize) dan pastikan filesystem mendukung flush yang andal.

#Optimasi Indeks

Indeks adalah faktor performa paling menentukan untuk search. Setiap filter yang memakai atribut tak terindeks memaksa full scan seluruh database. Pilih indeks berdasarkan pola pencarian nyata, bukan semua atribut — setiap indeks menambah beban tulis.

olcDbIndex mendukung jenis: pres (presence), eq (equality), sub (substring), dan approx. Pencarian login oleh sistem auth biasanya memakai uid dengan eq; autocomplete memakai sub pada cn. Jangan indeks atribut yang jarang dicari seperti description. Aturan praktis: mulai dari pres,eq untuk atribut kunci, tambahkan sub hanya untuk atribut yang benar-benar di-filter dengan wildcard.

Perawatan indeks: setiap kali menambah atau mengubah definisi olcDbIndex, indeks baru tidak otomatis terisi. Rebuild dengan slapindex:

Rebuild indeks setelah mengubah olcDbIndex

systemctl stop slapd
sudo -u openldap slapindex -b "dc=example,dc=com"
sudo -u openldap chown -R openldap:openldap /var/lib/ldap
systemctl start slapd

Untuk memantau apakah indeks bekerja, perhatikan loglevel stats di log slapd: pencarian yang melakukan full scan akan terlihat dari pola operasi yang berat dan waktu eksekusi yang naik.

#Penyetelan Koneksi

slapd melayani banyak koneksi sekaligus; tuning di sini menentukan seberapa besar lonjakan yang bisa ditahan:

Direktif	Fungsi	Nilai awal wajar
`olcConnMaxPending`	Antrian koneksi tanpa autentikasi	128
`olcConnMaxPendingAuth`	Antrian koneksi yang sedang autentikasi	1000
`olcThreads`	Jumlah thread kerja slapd	16
`olcIdleTimeout`	Koneksi idle dianggap putus (detik)	300

olcConnMaxPending dan olcConnMaxPendingAuth mengontrol seberapa banyak koneksi yang menunggu sebelum ditolak — kalau nilai terlalu kecil, lonjakan request singkat memicu error resource temporarily unavailable. olcThreads mengatur berapa banyak operasi yang bisa berjalan paralel; gunakan perkiraan dari jumlah core dan beban, bukan angka yang sangat besar (karena tiap thread butuh memori dan lock).

#Optimasi Pencarian

Batas hasil dan waktu mencegah satu pencarian menggantung seluruh server:

olcSizeLimit membatasi jumlah entry yang dikembalikan satu search; olcTimeLimit membatasi durasinya dalam detik. Aplikasi yang butuh hasil besar sebaiknya memakai paging (ldapsearch dengan kontrol paging), bukan menaikkan limit.

Optimasi selanjutnya ada di sisi filter dan base. Gunakan search base sedekat mungkin ke entry yang dicari — mencari (uid=budi) di ou=people,dc=example,dc=com jauh lebih cepat daripada di root. Susun filter dengan atribut berindeks lebih dulu, misalnya (&(objectClass=posixAccount)(uid=budi)), karena uid yang berindeks mempersempit himpunan sebelum objectClass ikut dievaluasi.

#Penyetelan Sistem Operasi

slapd adalah proses biasa yang terikat limit sistem operasi. Satu batas yang paling sering menyentuh di production adalah jumlah file descriptor:

File descriptor untuk user openldap

# /etc/security/limits.conf
openldap soft nofile 65536
openldap hard nofile 65536

Setiap koneksi klien memakai satu file descriptor, jadi limit default yang kecil akan membatasi jumlah koneksi sebelum tuning slapd sendiri terasa. Selain itu perhatikan: kernel parameter seperti vm.swappiness yang wajar untuk workload server (agar cache mdb tidak terdorong ke swap), dan I/O scheduler yang sesuai untuk media penyimpanan (SSD umumnya lebih cocok dengan scheduler low-latency). Bila olcDbCacheSize sudah wajar tetapi penggunaan CPU tinggi, arahkan perhatian ke indeks yang hilang, bukan ke kernel.

#Pengujian Performa

Tuning tanpa pengukuran adalah menebak. Bangun baseline sebelum mengubah apa pun, lalu ukur ulang setelah setiap perubahan:

Benchmark sederhana dengan loop ldapsearch

time for i in $(seq 1 1000); do
  ldapsearch -x -b "ou=people,dc=example,dc=com" \
    "(uid=budi)" cn >/dev/null 2>&1
done

Pantau metrik sistem dengan top, iostat, dan sar selama benchmark — tunggu apakah bottleneck ada di CPU, memori, atau disk. Di sisi slapd, lihat penghitung operasi di cn=Monitor:

Lihat statistik operasi dari cn=Monitor

ldapsearch -x -b "cn=Operations,cn=Monitor" -s base

Dari hasil pengukuran, catat baseline: berapa kueri per detik, latensi rata-rata, dan utilasasi CPU pada beban tertentu. Baseline inilah yang menjadi dasar capacity planning — memperkirakan berapa besar directory yang harus disiapkan saat jumlah pengguna tumbuh.

Warning

Perubahan olcDbMaxSize hanya berlaku setelah slapd restart, dan ukuran file tidak bisa dikecilkan. Perubahan olcDbCacheSize yang ekstrem juga bisa memicu penggunaan RAM besar — lakukan perubahan kecil dan ukur dampaknya sebelum menaikkan lagi.

Tip

Kalau pencarian tetap lambat setelah indeks dipasang, cek apakah filter memakai sub pada atribut yang tidak berindeks sub, atau gunakan search base yang lebih sempit. Pencarian yang menampilkan banyak hasil tidak terindeks di log adalah sinyal paling jelas untuk slapindex.

#Penutup

Pada episode 25 ini, kalian menyetel backend mdb dengan olcDbMaxSize dan cache, merancang indeks yang sesuai pola pencarian, mengatur limit koneksi dan thread, membatasi hasil search, menyetel sistem operasi, dan membangun baseline performa dengan pengujian terukur.

Inti yang harus dibawa pulang:

Indeks adalah pengungkit performa terbesar — pasang untuk atribut yang benar-benar difilter, lalu rebuild dengan slapindex.
Tuning adalah siklus ukur-ubah-ukur, bukan sekali pasang.
olcDbMaxSize untuk mdb harus direncanakan besar sejak awal karena tidak bisa dikecilkan.
Baseline performa adalah modal untuk capacity planning.

Di episode 26 berikutnya, kita melebarkan dari satu server menjadi banyak: high availability dan load balancing — arsitektur multi-node, replikasi mirror mode, load balancer, dan failover agar directory tetap hidup saat salah satu node mati.