28 Des 2025·6 menit
Claude Code untuk investigasi kinerja: alur kerja terukur
Gunakan Claude Code untuk investigasi kinerja dengan loop yang dapat diulang: ukur, bentuk hipotesis, ubah sedikit, dan ukur ulang sebelum release.
Gunakan Claude Code untuk investigasi kinerja dengan loop yang dapat diulang: ukur, bentuk hipotesis, ubah sedikit, dan ukur ulang sebelum release.
Bug performa mengundang tebak-tebakan. Seseorang merasa halaman terasa lambat atau sebuah API timeout, dan langkah tercepat adalah "membersihkan" kode, menambah caching, atau menulis ulang sebuah loop. Masalahnya, "terasa lambat" bukan metrik, dan "lebih bersih" tidak sama dengan lebih cepat.
Tanpa pengukuran, tim menghabiskan jam mengubah hal yang salah. Jalur panas mungkin ada di database, jaringan, atau alokasi tak terduga tunggal, sementara tim memoles kode yang nyaris tidak dieksekusi. Lebih buruk, perubahan yang tampak cerdas bisa membuat performa lebih buruk: logging ekstra di loop ketat, cache yang menambah tekanan memori, atau pekerjaan paralel yang menciptakan kontensi lock.
Tebak-tebakan juga berisiko merusak perilaku. Ketika Anda mengubah kode untuk mempercepatnya, Anda mungkin mengubah hasil, penanganan error, urutan, atau retry. Jika Anda tidak memeriksa kembali kebenaran dan kecepatan bersama-sama, Anda bisa "menang" pada benchmark sambil diam-diam mengirim bug.
Perlakukan performa seperti eksperimen, bukan perdebatan. Loopnya sederhana dan dapat diulang:
Banyak kemenangan berskala kecil: mengurangi 8% pada p95, menurunkan memori puncak 50 MB, atau memangkas satu query database. Itu tetap penting, tetapi hanya jika diukur, diverifikasi, dan dapat diulang.
Ini bekerja terbaik sebagai loop, bukan permintaan satu kali "buat lebih cepat". Loop membuat Anda jujur karena setiap tindakan terkait bukti dan angka yang bisa dipantau.
Urutan yang jelas:
Setiap langkah melindungi Anda dari jenis tipuan diri yang berbeda. Mengukur dulu menghentikan Anda dari "memperbaiki" sesuatu yang bukan masalah nyata. Hipotesis tertulis menghentikan Anda mengubah lima hal sekaligus lalu menebak mana yang berpengaruh. Perubahan minimal mengurangi risiko merusak perilaku atau menambah bottleneck baru. Mengukur ulang menangkap kemenangan plasebo (mis. run lebih cepat karena cache hangat) dan mengekspos regresi.
"Selesai" bukan perasaan. Itu hasil: metrik target bergerak ke arah yang benar, dan perubahan tidak menyebabkan regresi nyata (error, memori lebih tinggi, p95 yang lebih buruk, atau endpoint lain yang melambat).
Mengetahui kapan berhenti adalah bagian dari alur kerja. Berhenti ketika keuntungan menyurut, metrik sudah cukup baik untuk pengguna, atau ide berikutnya memerlukan refactor besar dengan upside kecil. Pekerjaan performa selalu punya biaya peluang; loop membantu Anda menghabiskan waktu di tempat yang memberi hasil.
Jika Anda mengukur lima hal sekaligus, Anda tidak akan tahu apa yang membaik. Pilih satu metrik utama untuk investigasi ini dan anggap yang lain sebagai sinyal pendukung. Untuk banyak masalah user-facing, metrik itu adalah latensi. Untuk pekerjaan batch bisa throughput, waktu CPU, penggunaan memori, atau bahkan biaya cloud per run.
Spesifik tentang skenarionya. "API lambat" terlalu samar. "POST /checkout dengan keranjang tipikal 3 item" bisa diukur. Jaga input stabil supaya angkanya bermakna.
Tuliskan baseline dan detail lingkungan sebelum Anda menyentuh kode: ukuran dataset, tipe mesin, mode build, feature flag, concurrency, dan warmup. Baseline ini adalah jangkar Anda. Tanpanya, setiap perubahan bisa tampak seperti kemajuan.
Untuk latensi, andalkan persentil, bukan hanya rata-rata. p50 menunjukkan pengalaman tipikal, sementara p95 dan p99 menyingkap ekor yang menyakitkan yang dikeluhkan pengguna. Perubahan yang memperbaiki p50 tetapi memperburuk p99 masih bisa terasa lebih lambat.
Putuskan di awal apa arti "bermakna" agar Anda tidak merayakan noise:
Setelah aturan ini ditetapkan, Anda bisa menguji ide tanpa memindahkan tujuan.
Mulailah dengan sinyal termudah yang bisa Anda percaya. Satu timing sekitar sebuah request bisa memberi tahu apakah Anda punya masalah nyata, dan kira-kira seberapa besar. Simpan profiling mendalam hanya saat Anda perlu menjelaskan mengapa lambat.
Bukti yang baik biasanya datang dari campuran sumber:
Gunakan metrik sederhana ketika pertanyaannya adalah "apakah ini lebih lambat, dan seberapa banyak?" Gunakan profiling ketika pertanyaannya adalah "ke mana waktu itu pergi?" Jika p95 latency melambung dua kali lipat setelah deploy, mulai dengan timing dan log untuk mengonfirmasi regresi dan mengerucutkan cakupan. Jika timing menunjukkan sebagian besar delay ada di kode aplikasi (bukan DB), maka profiler CPU atau flame graph dapat menunjuk fungsi tepat yang tumbuh.
Jaga pengukuran tetap aman. Kumpulkan apa yang perlu untuk debug performa, bukan isi pengguna. Prefer agregat (durasi, hitungan, ukuran) daripada payload mentah, dan redaksi identifier secara default.
Noise itu nyata, jadi ambil beberapa sampel dan catat outlier. Jalankan request yang sama 10 sampai 30 kali, dan catat median serta p95 daripada satu run terbaik.
Tuliskan resep uji yang persis agar Anda bisa mengulanginya setelah perubahan: lingkungan, dataset, endpoint, ukuran body request, level concurrency, dan bagaimana Anda menangkap hasil.
Mulailah dengan gejala yang bisa Anda namai: "p95 latency melompat dari 220 ms ke 900 ms saat puncak traffic," "CPU bertahan di 95% pada dua core," atau "memori tumbuh 200 MB per jam." Gejala samar seperti "terasa lambat" memicu perubahan acak.
Selanjutnya, terjemahkan apa yang Anda ukur ke area tersangka. Flame graph mungkin menunjukkan sebagian besar waktu di JSON encoding, trace mungkin menunjukkan jalur panggilan lambat, atau statistik DB mungkin menunjukkan satu query mendominasi total waktu. Pilih area terkecil yang menjelaskan sebagian besar biaya: sebuah fungsi, satu query SQL, atau satu panggilan eksternal.
Hipotesis yang baik satu kalimat, dapat diuji, dan terkait prediksi. Anda meminta bantuan untuk menguji ide, bukan meminta alat membuat semuanya lebih cepat secara ajaib.
Gunakan format ini:
Contoh: "Karena profile menunjukkan 38% CPU di SerializeResponse, membuat buffer baru per request menyebabkan lonjakan CPU. Jika kita reuse buffer, p95 latency harus turun sekitar 10–20% dan CPU turun ~15% pada beban yang sama."
Jujurlah dengan menamai alternatif sebelum menyentuh kode. Mungkin bagian lambat sebenarnya dependency upstream, kontensi lock, perubahan cache miss rate, atau rollout yang menambah ukuran payload.
Tuliskan 2–3 penjelasan alternatif, lalu pilih yang paling didukung bukti. Jika perubahan Anda tidak memindahkan metrik, Anda sudah punya hipotesis berikutnya siap diuji.
Claude paling berguna dalam pekerjaan performa ketika Anda memperlakukannya seperti analis hati-hati, bukan orakel. Ikat setiap saran pada apa yang Anda ukur, dan pastikan setiap langkah bisa dibuktikan salah.
Berikan input nyata, bukan deskripsi samar. Tempel bukti kecil dan fokus: ringkasan profiling, beberapa baris log di sekitar request lambat, rencana query, dan jalur kode spesifik. Sertakan angka "sebelum" (p95 latency, waktu CPU, waktu DB) agar ia tahu baseline Anda.
Minta penjelasan apa yang data tunjukkan dan apa yang tidak didukung. Lalu paksa penjelasan saingan. Prompt yang bernilai diakhiri dengan: "Berikan 2–3 hipotesis, dan untuk masing-masing, jelaskan apa yang bisa memfalsifikasinya." Itu mencegah terpaku pada cerita pertama yang masuk akal.
Sebelum mengubah apa pun, minta eksperimen terkecil yang dapat memvalidasi hipotesis teratas. Buat cepat dan reversible: tambahkan satu timer di sekitar fungsi, aktifkan satu flag profiler, atau jalankan satu query DB dengan EXPLAIN.
Jika Anda ingin struktur ketat untuk output, minta:
Jika ia tidak bisa menyebut metrik spesifik, lokasi, dan hasil yang diharapkan, Anda kembali menebak.
Setelah Anda punya bukti dan hipotesis, lawan dorongan untuk "membersihkan semuanya." Pekerjaan performa paling mudah dipercaya ketika perubahan kode kecil dan mudah di-undo.
Ubah satu hal pada satu waktu. Jika Anda tweak query, menambah caching, dan merombak loop dalam commit yang sama, Anda tidak akan tahu apa yang membantu (atau merugikan). Perubahan single-variable membuat pengukuran berikutnya bermakna.
Sebelum menyentuh kode, tulis angka apa yang Anda harapkan. Contoh: "p95 latency harus turun dari 420 ms ke di bawah 300 ms, dan waktu DB harus turun sekitar 100 ms." Jika hasil meleset, Anda cepat tahu hipotesisnya lemah atau tidak lengkap.
Buat perubahan mudah dibalik:
"Minimal" bukan berarti remeh. Itu berarti fokus: cache satu hasil fungsi mahal, hilangkan satu alokasi berulang di loop ketat, atau hentikan kerja untuk request yang tidak perlu.
Tambahkan timing ringan di sekitar bottleneck tersangka sehingga Anda bisa melihat apa yang berubah. Satu timestamp sebelum dan sesudah panggilan (dilogg atau dikumpulkan sebagai metrik) dapat mengonfirmasi apakah perubahan menyentuh bagian lambat atau sekadar memindahkan waktu ke tempat lain.
Setelah perubahan, jalankan ulang skenario persis yang Anda gunakan untuk baseline: input, lingkungan, dan bentuk beban yang sama. Jika test bergantung pada cache atau warm-up, nyatakan itu (mis. "run pertama cold, berikutnya 5 run hangat"). Kalau tidak, Anda akan "menemukan" perbaikan yang hanya keberuntungan.
Bandingkan hasil menggunakan metrik dan persentil yang sama. Rata-rata bisa menyembunyikan rasa sakit, jadi perhatikan p95 dan p99 latency, plus throughput dan waktu CPU. Jalankan cukup repetisi untuk melihat apakah angka stabil.
Sebelum merayakan, periksa regresi yang tidak muncul di angka utama:
Lalu putuskan berdasarkan bukti, bukan harapan. Jika perbaikan nyata dan Anda tidak memperkenalkan regresi, pertahankan. Jika hasil campur aduk atau noisy, revert dan susun hipotesis baru, atau isolasi perubahan lebih lanjut.
Jika Anda bekerja di platform seperti Koder.ai, mengambil snapshot sebelum eksperimen dapat membuat rollback menjadi satu langkah, yang memudahkan menguji ide-ide berani dengan aman.
Akhirnya, tuliskan apa yang Anda pelajari: baseline, perubahan, angka baru, dan kesimpulan. Catatan singkat ini mencegah putaran berikutnya mengulangi jalan buntu yang sama.
Pekerjaan performa biasanya meleset ketika Anda kehilangan benang antara apa yang Anda ukur dan apa yang Anda ubah. Jaga rantai bukti bersih sehingga Anda bisa mengatakan dengan yakin apa yang membuat lebih baik atau lebih buruk.
Pelaku berulang:
Contoh kecil: sebuah endpoint terlihat lambat, jadi Anda tune serializer karena itu panas di profile. Lalu Anda test ulang dengan dataset lebih kecil dan terlihat lebih cepat. Di produksi p99 malah memburuk karena database masih bottleneck dan perubahan Anda menambah ukuran payload.
Jika Anda menggunakan Claude Code untuk mengusulkan perbaikan, kendalikan outputnya. Minta 1–2 perubahan minimal yang cocok dengan bukti yang sudah dikumpulkan, dan desak rencana re-measure sebelum menerima patch.
Klaim kecepatan runtuh saat test kabur. Sebelum merayakan, pastikan Anda bisa menjelaskan apa yang diukur, bagaimana diukur, dan apa yang diubah.
Mulailah dengan menamai satu metrik dan menulis hasil baseline. Sertakan detail yang mengubah angka: tipe mesin, beban CPU, ukuran dataset, mode build (debug vs release), feature flag, status cache, dan concurrency. Jika Anda tidak bisa merekonstruksi setup besok, Anda tidak punya baseline.
Checklist:
Setelah angkanya tampak lebih baik, lakukan pengecekan regresi cepat. Periksa kebenaran (output sama), error rate, dan timeout. Amati efek samping seperti memori lebih tinggi, spike CPU, startup lebih lambat, atau beban DB bertambah. Perubahan yang memperbaiki p95 tetapi menggandakan memori mungkin merupakan trade-off yang salah.
Sebuah tim melaporkan GET /orders terasa baik di dev, tapi melambat di staging saat beban sedang. Pengguna mengeluh tentang timeout, tapi latensi rata-rata masih terlihat "oke," jebakan klasik.
Pertama, tetapkan baseline. Dengan uji beban stabil (dataset sama, concurrency sama, durasi sama), Anda mencatat:
Sekarang kumpulkan bukti. Trace cepat menunjukkan endpoint menjalankan query utama untuk orders, lalu melakukan loop dan fetch item terkait per order. Anda juga melihat respons JSON besar, tetapi waktu DB mendominasi.
Ubah itu menjadi daftar hipotesis yang bisa diuji:
Minta perubahan minimal yang cocok bukti terkuat: hilangkan satu panggilan N+1 dengan mengambil item dalam satu query yang dipetakan per order ID (atau tambahkan index yang hilang jika query plan menunjukkan full scan). Jaga reversible dan commit terfokus.
Ukur ulang dengan uji beban yang sama. Hasil:
Keputusan: ship perbaikan (menang jelas), lalu mulai siklus kedua fokus pada celah tersisa dan spike CPU, karena DB bukan lagi pembatas utama.
Cara tercepat jadi lebih baik dalam investigasi performa adalah memperlakukan setiap run sebagai eksperimen kecil yang bisa diulang. Saat proses konsisten, hasil lebih mudah dipercaya, dibandingkan, dan dibagikan.
Template satu halaman sederhana membantu:
Tentukan di mana catatan ini disimpan agar tidak hilang. Tempat bersama lebih penting daripada alat sempurna: folder repo di samping service, dokumen tim, atau catatan tiket. Keterlihatan adalah kuncinya. Seseorang harus bisa menemukan "p95 latency spike setelah perubahan caching" beberapa bulan kemudian.
Buat eksperimen aman menjadi kebiasaan. Gunakan snapshot dan rollback mudah supaya Anda bisa mencoba ide tanpa takut. Jika Anda membangun dengan Koder.ai, Planning Mode bisa menjadi tempat nyaman untuk merinci rencana pengukuran, mendefinisikan hipotesis, dan menjaga scope sebelum Anda menghasilkan diff ketat dan mengukur ulang.
Tetapkan ritme. Jangan menunggu insiden. Tambahkan pemeriksaan performa kecil setelah perubahan seperti query baru, endpoint baru, payload lebih besar, atau upgrade dependency. Pemeriksaan baseline 10 menit sekarang bisa menyelamatkan satu hari tebak-tebakan nanti.
Mulailah dengan satu angka yang sesuai dengan keluhan, biasanya p95 latency untuk endpoint dan input tertentu. Catat baseline dalam kondisi yang sama (ukuran data, concurrency, cache hangat/dingin), lalu ubah satu hal dan ukur ulang.
Jika Anda tidak bisa mereproduksi baseline, berarti Anda belum mengukur — Anda sedang menebak.
Baseline yang berguna mencakup:
Tuliskan sebelum mengubah kode agar Anda tidak memindahkan tiang gawang.
Percentil menunjukkan pengalaman pengguna lebih baik daripada rata-rata. p50 adalah pengalaman tipikal, tetapi pengguna mengeluh tentang ekor yang lambat, yaitu p95/p99.
Jika p50 membaik tapi p99 memburuk, sistem bisa terasa lebih lambat walau rata-ratanya tampak lebih baik.
Gunakan timing sederhana/log ketika Anda bertanya “apakah ini lebih lambat dan seberapa banyak?” Gunakan profiling ketika Anda bertanya “ke mana waktu itu pergi?”
Alur praktis: konfirmasi regresi dengan timing permintaan, lalu profile hanya setelah Anda tahu perlambatan itu nyata dan sudah dikecilkan cakupannya.
Pilih satu metrik utama, dan jadikan sisanya sebagai guardrail. Satu set umum adalah:
Ini mencegah Anda “menang” di satu grafik sambil diam-diam menyebabkan timeout, pertumbuhan memori, atau ekor latensi yang lebih buruk.
Tuliskan hipotesis satu kalimat yang terkait bukti dan prediksi:
Jika Anda tidak bisa menyebut bukti dan pergerakan metrik yang diharapkan, hipotesis itu belum dapat diuji.
Buat kecil, fokus, dan mudah dibalik:
Diff kecil membuat pengukuran berikutnya bermakna dan mengurangi kemungkinan Anda merusak perilaku saat mengejar kecepatan.
Jalankan ulang resep uji yang sama persis (input, load, lingkungan, aturan cache). Lalu periksa regresi selain angka utama:
Jika hasil noisy, ambil lebih banyak sampel atau revert dan perketat eksperimen.
Berikan bukti konkret dan paksa agar tetap berbasis uji:
Jika output tidak menyertakan metrik spesifik dan rencana re-test, Anda kembali ke tebak-tebakan.
Berhenti ketika:
Pekerjaan performa punya biaya peluang. Loop (measure → hypothesize → change → re-measure) membantu Anda menghabiskan waktu hanya di tempat yang angka membuktikannya penting.