Performa SoapUI Lambat: Penyebab & Cara Mengatasinya

Inti Masalahnya

Kinerja SoapUI yang lambat disebabkan oleh overhead startup JVM, pengaturan memori default yang terlalu rendah untuk proyek besar, dan keterlambatan parsing WSDL. Perbaikan spesifik (penyetelan ukuran heap, caching WSDL, pemisahan proyek) dapat secara signifikan meningkatkan kecepatan. Jika tim Anda membutuhkan alat yang lebih cepat yang sepenuhnya menghindari hambatan ini, Apidog berjalan tanpa runtime Java.

💡

Apidog adalah platform pengembangan API lengkap dan gratis yang berjalan di browser atau aplikasi desktop ringan, sepenuhnya menghindari overhead JVM dan penyetelan memori. Coba Apidog gratis, tanpa perlu kartu kredit.

tombol

Pengantar

SoapUI lambat. Jika Anda telah menggunakannya selama lebih dari beberapa minggu, Anda pasti pernah mengalami startup 30 detik, UI yang tidak responsif saat mem-parsing WSDL besar, atau eksekusi tes yang sangat lambat ketika Anda memiliki ratusan langkah tes. Ini bukan bug. Ini adalah hasil alami dari cara SoapUI dibangun.

Panduan ini menjelaskan alasan teknis spesifik mengapa SoapUI lambat, memberikan perbaikan konkret untuk setiap masalah, dan menjelaskan di mana batasannya. Beberapa kelambatan dapat Anda perbaiki. Beberapa tidak dapat Anda perbaiki tanpa beralih alat.

Penyebab Utama 1: Overhead Startup JVM

SoapUI adalah aplikasi Java Swing. Setiap kali Anda meluncurkannya, aplikasi ini memulai Java Virtual Machine (JVM), memuat ratusan file kelas, menginisialisasi framework Spring, memuat proyek Anda, dan merender antarmuka Swing. Pada mesin modern dengan SSD, ini membutuhkan waktu 20-60 detik. Pada perangkat keras lama, ini bisa melebihi 90 detik.

Mengapa ini terjadi: Aplikasi Java memiliki biaya startup yang tidak dimiliki aplikasi native. JVM perlu menginterpretasikan atau mengkompilasi bytecode secara JIT sebelum eksekusi dimulai. Inisialisasi UI Swing menambah hal tersebut.

Perbaikan:

Biarkan SoapUI tetap terbuka. Perbaikan paling sederhana adalah tidak menutupnya di antara eksekusi tes. Setelah JVM berjalan, ia akan tetap hangat.

Gunakan disk yang cepat. Jika Anda menjalankan SoapUI dari hard disk yang berputar, pindahkan ke SSD. Fase pemuatan kelas membaca banyak file kecil, dan di sinilah SSD mengungguli HDD.

Gunakan Java 11 atau 17, bukan 8. Versi JVM yang lebih baru memiliki waktu startup yang lebih baik. Periksa JDK mana yang dikonfigurasi untuk digunakan SoapUI di soapui.bat (Windows) atau soapui.sh (Linux/Mac). Baris pertama mengatur jalur home Java. Beralih ke JDK yang lebih baru dapat mengurangi waktu startup.

Aktifkan AppCDS (Application Class Data Sharing). Fitur JVM ini melakukan pra-caching data pemuatan kelas. Ini memerlukan pengaturan satu kali tetapi mengurangi waktu startup berikutnya. Tambahkan -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa ke argumen JVM Anda.

Penyebab Utama 2: Pengaturan Memori Default Terlalu Rendah

SoapUI dilengkapi dengan pengaturan ukuran heap default yang rendah. Membuka proyek besar atau menjalankan test suite yang panjang menyebabkan JVM menghabiskan waktu untuk garbage collection, yang menghentikan sementara aplikasi dan membuatnya terasa lamban.

Pengaturan default (dari soapui.vmoptions atau soapui.bat):

-Xms128m
-Xmx768m

Ini berarti SoapUI dimulai dengan heap 128 MB dan dapat menggunakan maksimum 768 MB. Mesin modern memiliki RAM 8-32 GB. Membiarkan SoapUI pada 768 MB menyebabkan tekanan garbage collection yang konstan pada proyek besar mana pun.

Perbaikan: tingkatkan ukuran heap

Di Windows, edit <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

Di macOS, edit SoapUI.app/Contents/vmoptions.txt atau cari soapui.sh:

JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"

Di Linux, edit <SoapUI_Install>/bin/soapui.sh:

JAVA_OPTS="-Xms512m -Xmx2048m -XX:+UseG1GC"

Rekomendasi:

Atur -Xms (heap awal) ke 512 MB atau lebih tinggi jika Anda memiliki RAM cadangan. Ini menghindari ekspansi heap bertahap.
Atur -Xmx (heap maksimum) ke 2 GB untuk proyek menengah, 4 GB untuk proyek besar. Jangan mengaturnya lebih dari setengah RAM yang tersedia.
Tambahkan -XX:+UseG1GC jika Anda menggunakan Java 9+. G1GC mengurangi waktu jeda dibandingkan dengan garbage collector default.
Tambahkan -XX:MaxMetaspaceSize=512m untuk mencegah metaspace (metadata kelas) tumbuh tanpa batas.

Memverifikasi perbaikan: Setelah memulai ulang SoapUI, buka dialog Help > System Properties. Anda akan melihat nilai heap yang diperbarui. Pantau pengelola tugas untuk mengonfirmasi bahwa SoapUI menggunakan alokasi baru.

Penyebab Utama 3: File Proyek Besar

SoapUI menyimpan semuanya dalam satu file XML. Proyek dengan banyak test suite, badan permintaan besar, atau data biner inline memperbesar ukuran file ini. Membuka dan menyimpan file proyek 10 MB terasa lebih lambat daripada file 500 KB.

Tanda-tanda masalah ini:

SoapUI berhenti selama beberapa detik saat Anda menyimpan (Ctrl+S)
File proyek di disk berukuran beberapa megabyte
Membuka proyek membutuhkan lebih dari 10 detik setelah SoapUI sudah berjalan

Perbaikan:

Pisahkan proyek besar. SoapUI mendukung proyek komposit yang menyimpan test suite sebagai file XML terpisah dalam sebuah direktori. Aktifkan ini di Project > Settings > Composite Project. Ini memungkinkan pemuatan parsial dan penyimpanan yang lebih cepat.
Hapus kasus uji yang tidak digunakan. Arsipkan atau hapus kasus uji yang tidak lagi relevan. Setiap kasus uji dengan skrip dan data permintaan menambah ukuran XML.
Eksternalisasi badan permintaan besar. Jika langkah-langkah uji Anda menggunakan badan XML atau JSON besar secara inline, pertimbangkan untuk memparametrikannya dan memuat dari file eksternal menggunakan DataSource berbasis file SoapUI.
Nonaktifkan cadangan otomatis “save on exit”. SoapUI membuat salinan cadangan saat keluar. Nonaktifkan ini di Preferences > UI Settings untuk menghindari penulisan disk ekstra saat menutup.

Penyebab Utama 4: Keterlambatan Parsing WSDL

Ketika SoapUI membuka proyek yang mereferensikan file WSDL, ia dapat mem-parsing ulang WSDL tersebut saat startup atau ketika Anda memperluas pohon antarmuka. Jika WSDL Anda di-hosting di server jarak jauh atau berukuran besar (banyak operasi, tipe kompleks), parsing ini menambah keterlambatan yang signifikan.

Tanda-tanda masalah ini:

SoapUI berhenti atau menampilkan indikator berputar saat memperluas antarmuka
Tes gagal dengan kesalahan batas waktu koneksi sebelum dimulai
Mesin yang berbeda memuat proyek dengan kecepatan yang berbeda (ketergantungan jaringan)

Perbaikan:

Cache WSDL secara lokal. Di SoapUI, klik kanan pada antarmuka > Update Definition. Ubah URL definisi untuk menunjuk ke salinan file lokal WSDL, bukan URL jarak jauh. Ini menghilangkan latensi jaringan pada setiap pemuatan.
Atur URL definisi ke jalur file://. Setelah Anda memiliki salinan lokal WSDL, perbarui URL definisi antarmuka ke file:///path/to/your/service.wsdl. SoapUI memuat ini dari disk secara instan.
Nonaktifkan pembaruan otomatis definisi. Di Preferences > WS-Security Settings, hapus centang opsi yang memaksa validasi ulang WSDL saat startup.
Tingkatkan pengaturan batas waktu HTTP. Jika WSDL jaringan lambat merespons, buka Preferences > HTTP Settings dan tingkatkan batas waktu koneksi. Ini mencegah SoapUI berhenti tanpa batas waktu pada server WSDL yang lambat.

Penyebab Utama 5: Kinerja Eksekusi Tes pada Suite Besar

Menjalankan test suite dengan ratusan kasus uji bisa lambat, terutama ketika setiap langkah tes memiliki skrip Groovy yang kompleks, assertion, atau panggilan jaringan.

Perbaikan:

Jalankan suite secara paralel. SoapUI mendukung eksekusi test suite paralel. Di TestSuite runner, aktifkan opsi “Run test cases concurrently”. Pastikan layanan SOAP Anda menangani koneksi bersamaan.
Nonaktifkan assertion yang tidak perlu. Setiap assertion yang dievaluasi SoapUI menambah waktu pemrosesan. Audit langkah-langkah tes Anda dan hapus assertion yang tidak memeriksa apa pun yang berarti.
Optimalkan skrip Groovy. Skrip Groovy berjalan diinterpretasikan di SoapUI. Hindari operasi mahal dalam skrip yang berjalan untuk setiap langkah tes (parsing string, regex, pembuatan objek besar). Pindahkan logika bersama ke pustaka skrip tingkat proyek.
Gunakan assertion waktu respons dengan hati-hati. Assertion SLA respons menunggu batas waktu penuh sebelum gagal. Jika Anda memiliki assertion SLA ketat dengan batas waktu lama pada endpoint yang tidak dapat diandalkan, itu dapat memblokir seluruh suite.
Kurangi verbositas logging. SoapUI mencatat setiap permintaan dan respons secara default. Untuk suite besar, I/O ini bertambah. Buka Preferences > HTTP Settings dan kurangi apa yang dicatat selama eksekusi tes.

Apa yang tidak bisa Anda perbaiki

Beberapa masalah kinerja SoapUI bersifat struktural. Tidak ada jumlah penyetelan yang dapat mengubah:

Rendering UI Swing. Antarmuka akan selalu terasa lebih lambat daripada aplikasi native atau web. Swing adalah yang tercanggih di tahun 2000. Sekarang tidak lagi.
Startup JVM. Anda bisa menguranginya. Anda tidak bisa menghilangkannya.
Parsing WSDL satu-threaded. SoapUI mem-parsing WSDL secara berurutan. WSDL yang besar dan kompleks dengan banyak skema yang diimpor membutuhkan waktu, dan tidak ada paralelisme yang dapat dikonfigurasi.
Overhead memori. JVM, Swing, dan framework Spring secara bersama-sama mengonsumsi memori terlepas dari ukuran proyek. 300-400 MB saat idle adalah hal yang biasa.

Kapan harus beralih

Jika Anda telah menerapkan perbaikan di atas dan SoapUI masih menghambat alur kerja Anda, hambatan tersebut mungkin tidak dapat diperbaiki melalui konfigurasi.

Apidog berjalan sebagai aplikasi web yang didukung oleh klien Node.js, bukan JVM. Ini terbuka dalam hitungan detik. Eksekusi tes tidak memerlukan runtime Java di mesin Anda. Untuk tim yang hambatan utamanya adalah waktu startup SoapUI dan responsivitas UI, beralih alat lebih produktif daripada penyetelan JVM yang berkelanjutan.

Komprominya: Apidog tidak mem-parsing WSDL. Jika Anda bergantung pada impor WSDL SoapUI untuk orientasi layanan baru, Anda mungkin ingin tetap menggunakan SoapUI untuk tugas spesifik tersebut sambil menjalankan pengujian sehari-hari di Apidog.

Pertanyaan Umum

Berapa ukuran heap yang direkomendasikan untuk SoapUI dengan proyek besar (50+ test suite)?Atur -Xmx setidaknya 2 GB, idealnya 4 GB jika mesin Anda memiliki RAM 16 GB atau lebih. Atur -Xms ke 512 MB hingga 1 GB untuk menghindari ekspansi heap bertahap. Gunakan -XX:+UseG1GC untuk perilaku garbage collection yang lebih baik.

Bisakah saya memeriksa penggunaan heap SoapUI saat ini?Ya. Buka Help > System Properties. Ini menunjukkan argumen JVM termasuk pengaturan heap. Anda juga dapat menambahkan -verbose:gc ke opsi JVM sementara untuk melihat aktivitas garbage collection di log SoapUI.

Apakah beralih ke JDK yang lebih baru meningkatkan kinerja SoapUI?Dalam kebanyakan kasus, ya. Waktu startup JVM dan garbage collection telah meningkat di Java 11 dan 17 dibandingkan dengan Java 8. Periksa catatan rilis SoapUI untuk versi JDK yang direkomendasikan, karena beberapa versi JDK yang lebih baru memiliki masalah kompatibilitas dengan rilis SoapUI yang lebih lama.

Mengapa SoapUI melambat setelah menjalankan tes selama beberapa jam?Fragmentasi memori dan overhead garbage collection meningkat seiring waktu. Menutup dan membuka kembali SoapUI mengatur ulang status JVM. Meningkatkan -Xmx dan menggunakan G1GC menunda degradasi ini tetapi tidak menghilangkannya.

Apakah menjalankan SoapUI di server (headless) meningkatkan kinerja?Ya, sampai batas tertentu. Mode headless (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false dan flag serupa) mengurangi overhead rendering Swing. Gunakan testrunner baris perintah untuk CI/CD daripada GUI untuk kinerja terbaik.

Bagaimana Apidog menangani koleksi besar dibandingkan dengan SoapUI?Apidog menyimpan koleksi di cloud dan memuatnya sesuai permintaan. Tidak ada file XML lokal untuk diparsing. Eksekusi tes menggunakan CLI runner lokal yang tidak memerlukan inisialisasi JVM.

Sebagian besar masalah kinerja SoapUI memiliki perbaikan. Perubahan ukuran heap saja seringkali memiliki efek langsung dan terlihat. Mulailah dari sana sebelum mencoba solusi yang lebih kompleks.