SoapUI Yavaş Performans: Nedenleri ve Çözüm Yolları

TL;DR

SoapUI’nin yavaş performansı, JVM başlangıç ​​yükünden, büyük projeler için çok düşük olan varsayılan bellek ayarlarından ve WSDL ayrıştırma gecikmelerinden kaynaklanmaktadır. Belirli düzeltmeler (yığın boyutu ayarlaması, WSDL önbelleğe alma, proje bölme) hızı önemli ölçüde artırabilir. Ekibiniz bu darboğazları tamamen ortadan kaldıran daha hızlı bir araca ihtiyaç duyuyorsa, Apidog bir Java çalışma zamanı olmadan çalışır.

Giriş

SoapUI yavaştır. Birkaç haftadan fazla kullandıysanız, 30 saniyelik başlangıcı, büyük bir WSDL'yi ayrıştırırken yanıt vermeyen kullanıcı arayüzünü veya yüzlerce test adımınız olduğunda sürünerek ilerleyen test çalıştırmasını deneyimlemişsinizdir. Bunlar hata değildir. Bunlar SoapUI'nin nasıl inşa edildiğinin doğal bir sonucudur.

Bu kılavuz, SoapUI'nin yavaş olmasının belirli teknik nedenlerini açıklar, her biri için somut çözümler sunar ve sınırların nerede olduğunu belirtir. Bazı yavaşlıkları düzeltebilirsiniz. Bazılarını ise araç değiştirmeden düzeltemezsiniz.

Temel Neden 1: JVM başlangıç ​​yükü

SoapUI bir Java Swing uygulamasıdır. Her başlattığınızda, bir Java Sanal Makinesi (JVM) başlatır, yüzlerce sınıf dosyasını yükler, Spring framework'ü başlatır, projenizi yükler ve Swing arayüzünü oluşturur. SSD'li modern bir makinede bu işlem 20-60 saniye sürer. Eski donanımlarda ise 90 saniyeyi aşabilir.

Neden böyle olur: Java uygulamaları, yerel uygulamaların ödemediği bir başlangıç ​​maliyeti öderler. JVM'nin yürütme başlamadan önce bayt kodunu yorumlaması veya JIT derlemesi gerekir. Swing UI başlatma da buna eklenir.

Düzeltmeler:

SoapUI'yi açık tutun. En basit çözüm, test çalıştırmaları arasında kapatmamaktır. JVM çalışmaya başladığında, ısınmış kalır.

Hızlı bir disk kullanın. SoapUI'yi dönen bir sabit diskten çalıştırıyorsanız, bir SSD'ye taşıyın. Sınıf yükleme aşaması birçok küçük dosyayı okur ve SSD'ler tam da bu noktada HDD'lerden daha iyi performans gösterir.

Java 8 yerine Java 11 veya 17 kullanın. Daha yeni JVM sürümleri geliştirilmiş başlangıç ​​sürelerine sahiptir. SoapUI'nin soapui.bat (Windows) veya soapui.sh (Linux/Mac) içinde hangi JDK'yı kullanacak şekilde yapılandırıldığını kontrol edin. İlk satır Java ana yolunu ayarlar. Daha yeni bir JDK'ya geçmek başlangıç ​​süresini azaltabilir.

AppCDS'yi (Uygulama Sınıfı Veri Paylaşımı) etkinleştirin. Bu JVM özelliği, sınıf yükleme verilerini önbelleğe alır. Tek seferlik bir kurulum gerektirir ancak sonraki başlangıç ​​sürelerini azaltır. JVM argümanlarınıza -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa ekleyin.

Temel Neden 2: Varsayılan bellek ayarları çok düşük

SoapUI, düşük varsayılan yığın boyutu ayarlarıyla birlikte gelir. Büyük bir proje açmak veya uzun bir test paketini çalıştırmak, JVM'nin çöp toplama üzerinde zaman harcamasına neden olur, bu da uygulamayı duraklatır ve yavaş hissettirir.

Varsayılan ayarlar (soapui.vmoptions veya soapui.bat dosyasından):

-Xms128m
-Xmx768m

Bu, SoapUI'nin 128 MB yığın ile başladığı ve maksimum 768 MB kullanabileceği anlamına gelir. Modern makinelerde 8-32 GB RAM bulunur. SoapUI'yi 768 MB'ta bırakmak, herhangi bir büyük projede sürekli çöp toplama baskısına neden olur.

Düzeltme: Yığın boyutunu artırın

Windows'ta, <SoapUI_Yükleme_Dizini>/bin/SoapUI.vmoptions dosyasını düzenleyin:

-Xms512m
-Xmx2048m

macOS'te, SoapUI.app/Contents/vmoptions.txt dosyasını düzenleyin veya soapui.sh dosyasını bulun:

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

Linux'ta, <SoapUI_Yükleme_Dizini>/bin/soapui.sh dosyasını düzenleyin:

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

Öneriler:

• Boş RAM'iniz varsa -Xms (başlangıç yığını) değerini 512 MB veya daha yüksek olarak ayarlayın. Bu, yavaş yavaş yığın genişlemesini önler.
• -Xmx (maksimum yığın) değerini orta ölçekli projeler için 2 GB, büyük projeler için 4 GB olarak ayarlayın. Mevcut RAM'inizin yarısından fazlasına ayarlamayın.
• Java 9+ kullanıyorsanız -XX:+UseG1GC ekleyin. G1GC, varsayılan çöp toplayıcıya kıyasla duraklama sürelerini azaltır.
• Metaspace'in (sınıf meta verileri) sınırsız büyümesini önlemek için -XX:MaxMetaspaceSize=512m ekleyin.

Düzeltmeyi doğrulama: SoapUI'yi yeniden başlattıktan sonra, Yardım > Sistem Özellikleri iletişim kutusunu açın. Güncellenmiş yığın değerlerini görmelisiniz. SoapUI'nin yeni ayrımı kullandığını onaylamak için görev yöneticisini izleyin.

Temel Neden 3: Büyük proje dosyaları

SoapUI her şeyi tek bir XML dosyasında saklar. Birçok test paketi, büyük istek gövdeleri veya satır içi ikili veriler içeren projeler bu dosyayı şişirir. 10 MB'lık bir proje dosyasını açmak ve kaydetmek, 500 KB'lık bir dosyadan gözle görülür şekilde daha yavaştır.

Bu sorunun belirtileri:

• Kaydettiğinizde (Ctrl+S) SoapUI birkaç saniye duraklar.
• Diskteki proje dosyası birkaç megabayttır.
• SoapUI zaten çalışırken projeyi açmak 10 saniyeden fazla sürer.

Düzeltmeler:

Büyük projeleri bölün. SoapUI, test paketlerini bir dizinde ayrı XML dosyaları olarak depolayan kompozit projeleri destekler. Bunu Proje > Ayarlar > Kompozit Proje'den etkinleştirin. Bu, kısmi yüklemeye ve daha hızlı kaydetmeye olanak tanır.

Kullanılmayan test durumlarını kaldırın. Artık ilgili olmayan test durumlarını arşivleyin veya silin. Betikler ve istek verileri içeren her test durumu, XML boyutunu artırır.

Büyük istek gövdelerini dışsallaştırın. Test adımlarınızda büyük XML veya JSON gövdeleri satır içi kullanılıyorsa, bunları parametreleştirmeyi ve SoapUI'nin dosya tabanlı Veri Kaynağını kullanarak harici dosyalardan yüklemeyi düşünün.

"Çıkışta kaydet" otomatik yedeklemeyi devre dışı bırakın. SoapUI, çıkışta yedek kopyalar oluşturur. Kapatmada ek disk yazmayı önlemek için bunu Tercihler > UI Ayarları'nda devre dışı bırakın.

Temel Neden 4: WSDL ayrıştırma gecikmeleri

SoapUI, WSDL dosyalarına referans veren bir proje açtığında, bu WSDL'leri başlangıçta veya arayüz ağacını genişlettiğinizde yeniden ayrıştırabilir. WSDL'leriniz uzak bir sunucuda barındırılıyorsa veya büyükse (birçok işlem, karmaşık türler), bu ayrıştırma önemli gecikmeler ekler.

Bu sorunun belirtileri:

• Bir arayüzü genişletirken SoapUI donar veya dönen bir gösterge gösterir.
• Testler başlamadan önce bağlantı zaman aşımı hatalarıyla başarısız olur.
• Farklı makineler projeyi farklı hızlarda yükler (ağ bağımlılığı).

Düzeltmeler:

WSDL'leri yerel olarak önbelleğe alın. SoapUI'de, bir arayüze sağ tıklayın > Tanımı Güncelle. Tanım URL'sini, uzak URL yerine WSDL'nin yerel bir dosya kopyasına işaret edecek şekilde değiştirin. Bu, her yüklemede ağ gecikmesini ortadan kaldırır.

Tanım URL'lerini file:// yollarına ayarlayın. WSDL'nin yerel bir kopyasına sahip olduğunuzda, arayüz tanım URL'sini file:///path/to/your/service.wsdl olarak güncelleyin. SoapUI bunu diskten anında yükler.

Tanım otomatik güncellemesini devre dışı bırakın. Tercihler > WS-Güvenlik Ayarları'nda, başlangıçta WSDL yeniden doğrulamayı zorlayan seçeneklerin işaretini kaldırın.

HTTP zaman aşımı ayarlarını artırın. Ağ WSDL'leri yavaş yanıt veriyorsa, Tercihler > HTTP Ayarları'na gidin ve bağlantı zaman aşımını artırın. Bu, SoapUI'nin yavaş bir WSDL sunucusunda süresiz olarak donmasını önler.

Temel Neden 5: Büyük paketlerde test çalıştırma performansı

Yüzlerce test durumu içeren bir test paketini çalıştırmak, özellikle her test adımında karmaşık Groovy betikleri, onaylamalar veya ağ çağrıları olduğunda yavaş olabilir.

Düzeltmeler:

• Paketleri paralel çalıştırın. SoapUI paralel test paketi yürütmeyi destekler. TestSuite çalıştırıcısında, "Test durumlarını eşzamanlı çalıştır" seçeneğini etkinleştirin. SOAP hizmetinizin eşzamanlı bağlantıları işlediğinden emin olun.
• Gereksiz onaylamaları devre dışı bırakın. SoapUI'nin değerlendirdiği her onaylama işlem süresi ekler. Test adımlarınızı denetleyin ve anlamlı bir şey kontrol etmeyen onaylamaları kaldırın.
• Groovy betiklerini optimize edin. Groovy betikleri SoapUI'de yorumlanarak çalışır. Her test adımı için çalışan betiklerde pahalı işlemlerden kaçının (dize ayrıştırma, regex, büyük nesne oluşturma). Paylaşılan mantığı proje düzeyindeki betik kütüphanelerine taşıyın.
• Yanıt süresi onaylamalarını dikkatli kullanın. Yanıt SLA onaylamaları, başarısız olmadan önce tam zaman aşımını bekler. Güvenilmez uç noktalarda uzun zaman aşımı olan sıkı SLA onaylamalarınız varsa, bunlar tüm paketi engelleyebilir.
• Günlük kaydı ayrıntı düzeyini azaltın. SoapUI varsayılan olarak her isteği ve yanıtı günlüğe kaydeder. Büyük paketler için bu G/Ç birikir. Tercihler > HTTP Ayarları'na gidin ve test çalıştırmaları sırasında günlüğe kaydedilenleri azaltın.

Neleri düzeltemezsiniz?

Bazı SoapUI performans sorunları yapısal niteliktedir. Hiçbir ayar değişikliği şunları değiştirmez:

• Swing UI oluşturma. Arayüz, her zaman yerel veya web uygulamasından daha yavaş hissettirecektir. Swing, 2000'lerde son teknolojiydi. Şimdi değil.
• JVM başlangıcı. Bunu azaltabilirsiniz. Ancak tamamen ortadan kaldıramazsınız.
• Tek iş parçacıklı WSDL ayrıştırma. SoapUI, WSDL'leri sıralı olarak ayrıştırır. Çok sayıda içe aktarılan şemaya sahip büyük, karmaşık WSDL'ler zaman alır ve yapılandırılacak paralellik yoktur.
• Bellek yükü. JVM, Swing ve Spring framework birlikte proje boyutundan bağımsız olarak bellek tüketir. Boşta 300-400 MB tipiktir.

Ne zaman başka bir araca geçmeli?

Yukarıdaki düzeltmeleri uygulamanıza rağmen SoapUI iş akışınızı hala engelliyorsa, darboğaz yapılandırma yoluyla düzeltilemeyebilir.

Apidog, bir JVM yerine Node.js istemcisi tarafından desteklenen bir web uygulaması olarak çalışır. Saniyeler içinde açılır. Test yürütme, makinenizde bir Java çalışma zamanı gerektirmez. Birincil darboğazı SoapUI'nin başlangıç ​​süresi ve UI duyarlılığı olan ekipler için, araç değiştirmek sürekli JVM ayarlamasından daha verimlidir.

Dezavantajı: Apidog WSDL ayrıştırmaz. Yeni hizmet entegrasyonu için SoapUI'nin WSDL içe aktarımına bağlıysanız, günlük testleri Apidog'da çalıştırırken o belirli görev için SoapUI'yi kullanılabilir tutmak isteyebilirsiniz.

Sıkça Sorulan Sorular

Büyük bir proje (50+ test paketi) ile SoapUI için önerilen yığın boyutu nedir?Makinenizin 16 GB veya daha fazla RAM'i varsa -Xmx değerini en az 2 GB, ideal olarak 4 GB olarak ayarlayın. Yavaş yavaş yığın genişlemesini önlemek için -Xms değerini 512 MB ile 1 GB arasında ayarlayın. Daha iyi çöp toplama davranışı için -XX:+UseG1GC kullanın.

SoapUI'nin mevcut yığın kullanımını kontrol edebilir miyim?Evet. Yardım > Sistem Özellikleri'ne gidin. Bu, yığın ayarları dahil JVM argümanlarını gösterir. SoapUI günlüğündeki çöp toplama etkinliğini geçici olarak görmek için JVM seçeneklerine -verbose:gc ekleyebilirsiniz.

Daha yeni bir JDK'ya geçmek SoapUI performansını artırır mı?Çoğu durumda evet. Java 11 ve 17'de JVM başlangıç ​​süresi ve çöp toplama, Java 8'e kıyasla iyileşmiştir. Bazı yeni JDK sürümlerinin eski SoapUI sürümleriyle uyumluluk sorunları olabileceğinden, önerilen JDK sürümü için SoapUI'nin sürüm notlarını kontrol edin.

SoapUI neden birkaç saat test çalıştırdıktan sonra yavaşlar?Bellek parçalanması ve çöp toplama yükü zamanla artar. SoapUI'yi kapatıp yeniden açmak JVM durumunu sıfırlar. -Xmx değerini artırmak ve G1GC kullanmak bu bozulmayı geciktirir ancak ortadan kaldırmaz.

SoapUI'yi bir sunucuda (başsız modda) çalıştırmak performansı artırır mı?Evet, bir ölçüde. Başsız mod (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false ve benzeri bayraklar) Swing oluşturma yükünü azaltır. En iyi performans için GUI yerine CI/CD için komut satırı test çalıştırıcısını kullanın.

Apidog, büyük koleksiyonları SoapUI'ye kıyasla nasıl yönetir?Apidog, koleksiyonları bulutta depolar ve isteğe bağlı olarak yükler. Ayrıştırılacak yerel bir XML dosyası yoktur. Test yürütme, JVM başlatma gerektirmeyen yerel bir CLI çalıştırıcısı kullanır.

Çoğu SoapUI performans sorununun çözümleri vardır. Yığın boyutu değişikliği tek başına genellikle anında, görünür bir etki yaratır. Daha karmaşık çözümler denemeden önce buradan başlayın.