SoapUI Chậm: Nguyên Nhân và Cách Khắc Phục

Tóm tắt

Hiệu suất chậm của SoapUI xuất phát từ việc khởi động JVM tốn tài nguyên, cài đặt bộ nhớ mặc định quá thấp cho các dự án lớn và độ trễ khi phân tích cú pháp WSDL. Các biện pháp khắc phục cụ thể (tinh chỉnh kích thước heap, bộ nhớ đệm WSDL, chia tách dự án) có thể cải thiện đáng kể tốc độ. Nếu nhóm của bạn cần một công cụ nhanh hơn để loại bỏ hoàn toàn những nút thắt này, Apidog chạy mà không cần môi trường thực thi Java.

💡

Apidog là một nền tảng phát triển API tất cả trong một miễn phí, chạy trên trình duyệt hoặc ứng dụng máy tính để bàn nhẹ, giúp loại bỏ hoàn toàn chi phí khởi động JVM và việc tinh chỉnh bộ nhớ. Hãy dùng thử Apidog miễn phí, không cần thẻ tín dụng.

Tải ứng dụng

Giới thiệu

SoapUI chạy chậm. Nếu bạn đã sử dụng nó trong vài tuần, bạn chắc hẳn đã trải qua cảnh khởi động mất 30 giây, giao diện người dùng không phản hồi khi phân tích cú pháp một tệp WSDL lớn, hoặc quá trình chạy thử nghiệm ì ạch khi bạn có hàng trăm bước kiểm thử. Đây không phải là lỗi. Đây là kết quả tự nhiên của cách SoapUI được xây dựng.

Hướng dẫn này giải thích các lý do kỹ thuật cụ thể khiến SoapUI chậm, đưa ra các biện pháp khắc phục cụ thể cho từng vấn đề và giải thích giới hạn của chúng. Một số vấn đề về độ chậm bạn có thể khắc phục. Một số khác thì không thể nếu không chuyển đổi công cụ.

Nguyên nhân gốc 1: Chi phí khởi động JVM

SoapUI là một ứng dụng Java Swing. Mỗi khi bạn khởi chạy, nó bắt đầu một Máy ảo Java (JVM), tải hàng trăm tệp lớp (class files), khởi tạo framework Spring, tải dự án của bạn và hiển thị giao diện Swing. Trên một máy tính hiện đại có ổ SSD, việc này mất từ 20-60 giây. Trên phần cứng cũ hơn, có thể vượt quá 90 giây.

Tại sao điều này xảy ra: Các ứng dụng Java phải chịu một chi phí khởi động mà các ứng dụng gốc (native applications) không có. JVM cần phải thông dịch hoặc biên dịch JIT bytecode trước khi quá trình thực thi bắt đầu. Việc khởi tạo giao diện người dùng Swing càng làm tăng thêm chi phí này.

Các biện pháp khắc phục:

Giữ SoapUI mở. Cách khắc phục đơn giản nhất là không đóng nó giữa các lần chạy thử nghiệm. Một khi JVM đang chạy, nó sẽ giữ trạng thái "nóng" (warm).

Sử dụng ổ đĩa nhanh. Nếu bạn đang chạy SoapUI từ một ổ cứng HDD, hãy chuyển nó sang ổ SSD. Giai đoạn tải lớp (class-loading) đọc nhiều tệp nhỏ, đây chính là lúc SSD vượt trội hơn HDD.

Sử dụng Java 11 hoặc 17 thay vì 8. Các phiên bản JVM mới hơn đã cải thiện thời gian khởi động. Kiểm tra xem SoapUI được cấu hình để sử dụng JDK nào trong soapui.bat (Windows) hoặc soapui.sh (Linux/Mac). Dòng đầu tiên thiết lập đường dẫn Java home. Chuyển sang JDK mới hơn có thể giảm thời gian khởi động.

Bật AppCDS (Application Class Data Sharing). Tính năng JVM này lưu trước bộ nhớ đệm dữ liệu tải lớp (class loading data). Nó yêu cầu thiết lập một lần nhưng giảm thời gian khởi động các lần tiếp theo. Thêm -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa vào các đối số JVM của bạn.

Nguyên nhân gốc 2: Cài đặt bộ nhớ mặc định quá thấp

SoapUI đi kèm với cài đặt kích thước heap mặc định thấp. Việc mở một dự án lớn hoặc chạy một bộ kiểm thử dài khiến JVM phải dành thời gian cho việc thu gom rác (garbage collection), điều này làm tạm dừng ứng dụng và khiến nó trở nên ì ạch.

Cài đặt mặc định (từ soapui.vmoptions hoặc soapui.bat):

-Xms128m
-Xmx768m

Điều này có nghĩa là SoapUI khởi động với 128 MB heap và có thể sử dụng tối đa 768 MB. Các máy tính hiện đại có 8-32 GB RAM. Việc để SoapUI ở mức 768 MB gây áp lực thu gom rác liên tục đối với bất kỳ dự án lớn nào.

Khắc phục: tăng kích thước heap

Trên Windows, chỉnh sửa <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

Trên macOS, chỉnh sửa SoapUI.app/Contents/vmoptions.txt hoặc tìm soapui.sh:

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

Trên Linux, chỉnh sửa <SoapUI_Install>/bin/soapui.sh:

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

Khuyến nghị:

Đặt -Xms (heap ban đầu) thành 512 MB hoặc cao hơn nếu bạn có đủ RAM. Điều này tránh việc mở rộng heap dần dần.
Đặt -Xmx (heap tối đa) thành 2 GB cho các dự án vừa, 4 GB cho các dự án lớn. Không đặt nó vượt quá một nửa RAM khả dụng của bạn.
Thêm -XX:+UseG1GC nếu bạn đang sử dụng Java 9 trở lên. G1GC giảm thời gian tạm dừng so với bộ thu gom rác mặc định.
Thêm -XX:MaxMetaspaceSize=512m để ngăn metaspace (siêu dữ liệu lớp) phát triển không giới hạn.

Xác minh khắc phục: Sau khi khởi động lại SoapUI, mở hộp thoại Help > System Properties. Bạn sẽ thấy các giá trị heap đã được cập nhật. Theo dõi trình quản lý tác vụ (task manager) để xác nhận SoapUI đang sử dụng phân bổ mới.

Nguyên nhân gốc 3: Tệp dự án lớn

SoapUI lưu trữ mọi thứ trong một tệp XML duy nhất. Các dự án có nhiều bộ kiểm thử, các phần thân yêu cầu lớn hoặc dữ liệu nhị phân nội tuyến sẽ làm tệp này phình to. Việc mở và lưu một tệp dự án 10 MB chậm hơn đáng kể so với tệp 500 KB.

Dấu hiệu của vấn đề này:

SoapUI tạm dừng vài giây khi bạn lưu (Ctrl+S)
Tệp dự án trên đĩa có kích thước vài megabyte
Mở dự án mất hơn 10 giây sau khi SoapUI đã chạy

Các biện pháp khắc phục:

Chia tách các dự án lớn. SoapUI hỗ trợ các dự án tổng hợp (composite projects) lưu trữ các bộ kiểm thử dưới dạng các tệp XML riêng biệt trong một thư mục. Bật tính năng này trong Project > Settings > Composite Project. Điều này cho phép tải từng phần và lưu nhanh hơn.
Xóa các trường hợp kiểm thử không sử dụng. Lưu trữ hoặc xóa các trường hợp kiểm thử không còn liên quan. Mỗi trường hợp kiểm thử với tập lệnh và dữ liệu yêu cầu đều làm tăng kích thước XML.
Ngoại hóa các phần thân yêu cầu lớn. Nếu các bước kiểm thử của bạn sử dụng các phần thân XML hoặc JSON lớn nội tuyến, hãy cân nhắc tham số hóa chúng và tải từ các tệp bên ngoài bằng cách sử dụng DataSource dựa trên tệp của SoapUI.
Tắt tính năng tự động sao lưu "lưu khi thoát". SoapUI tạo các bản sao lưu khi thoát. Vô hiệu hóa điều này trong Preferences > UI Settings để tránh ghi đĩa thêm khi đóng.

Nguyên nhân gốc 4: Độ trễ khi phân tích cú pháp WSDL

Khi SoapUI mở một dự án tham chiếu đến các tệp WSDL, nó có thể phân tích lại các tệp WSDL đó khi khởi động hoặc khi bạn mở rộng cây giao diện. Nếu các tệp WSDL của bạn được lưu trữ trên một máy chủ từ xa hoặc có kích thước lớn (nhiều thao tác, kiểu phức tạp), việc phân tích này sẽ thêm vào độ trễ đáng kể.

Dấu hiệu của vấn đề này:

SoapUI bị treo hoặc hiển thị biểu tượng quay tròn khi mở rộng một giao diện
Các kiểm thử thất bại với lỗi hết thời gian kết nối trước khi chúng bắt đầu
Các máy khác nhau tải dự án với tốc độ khác nhau (phụ thuộc vào mạng)

Các biện pháp khắc phục:

Lưu WSDL vào bộ đệm cục bộ. Trong SoapUI, nhấp chuột phải vào một giao diện > Update Definition. Thay đổi URL định nghĩa để trỏ đến một bản sao tệp WSDL cục bộ thay vì URL từ xa. Điều này loại bỏ độ trễ mạng mỗi khi tải.
Đặt URL định nghĩa thành đường dẫn file://. Khi bạn đã có một bản sao WSDL cục bộ, hãy cập nhật URL định nghĩa giao diện thành file:///path/to/your/service.wsdl. SoapUI tải cái này từ đĩa ngay lập tức.
Tắt cập nhật định nghĩa tự động. Trong Preferences > WS-Security Settings, bỏ chọn các tùy chọn buộc xác thực lại WSDL khi khởi động.
Tăng cài đặt thời gian chờ HTTP. Nếu các WSDL trên mạng phản hồi chậm, hãy vào Preferences > HTTP Settings và tăng thời gian chờ kết nối. Điều này ngăn SoapUI bị treo vô thời hạn trên máy chủ WSDL chậm.

Nguyên nhân gốc 5: Hiệu suất chạy thử nghiệm trên các bộ kiểm thử lớn

Chạy một bộ kiểm thử với hàng trăm trường hợp kiểm thử có thể chậm, đặc biệt khi mỗi bước kiểm thử có các tập lệnh Groovy phức tạp, xác nhận (assertions), hoặc các cuộc gọi mạng.

Các biện pháp khắc phục:

Chạy các bộ kiểm thử song song. SoapUI hỗ trợ thực thi bộ kiểm thử song song. Trong trình chạy TestSuite, bật tùy chọn "Run test cases concurrently". Đảm bảo dịch vụ SOAP của bạn xử lý các kết nối đồng thời.
Tắt các xác nhận không cần thiết. Mỗi xác nhận mà SoapUI đánh giá đều làm tăng thời gian xử lý. Kiểm tra các bước kiểm thử của bạn và loại bỏ các xác nhận không kiểm tra bất kỳ điều gì có ý nghĩa.
Tối ưu hóa các tập lệnh Groovy. Các tập lệnh Groovy chạy được thông dịch trong SoapUI. Tránh các thao tác tốn kém trong các tập lệnh chạy cho mọi bước kiểm thử (phân tích chuỗi, biểu thức chính quy, tạo đối tượng lớn). Chuyển logic dùng chung sang các thư viện tập lệnh cấp dự án.
Sử dụng xác nhận thời gian phản hồi một cách cẩn thận. Các xác nhận SLA phản hồi sẽ chờ đến hết thời gian chờ trước khi thất bại. Nếu bạn có các xác nhận SLA chặt chẽ với thời gian chờ dài trên các điểm cuối không đáng tin cậy, chúng có thể chặn toàn bộ bộ kiểm thử.
Giảm chi tiết ghi log. SoapUI mặc định ghi log mọi yêu cầu và phản hồi. Đối với các bộ kiểm thử lớn, việc đọc/ghi này tăng lên đáng kể. Vào Preferences > HTTP Settings và giảm những gì được ghi log trong quá trình chạy thử nghiệm.

Những gì bạn không thể khắc phục

Một số vấn đề về hiệu suất của SoapUI mang tính cấu trúc. Không có lượng tinh chỉnh nào có thể thay đổi được:

Hiển thị giao diện người dùng Swing. Giao diện sẽ luôn chậm hơn so với ứng dụng gốc hoặc ứng dụng web. Swing là công nghệ tiên tiến vào năm 2000. Bây giờ thì không.
Khởi động JVM. Bạn có thể giảm nó. Bạn không thể loại bỏ nó.
Phân tích cú pháp WSDL đơn luồng. SoapUI phân tích cú pháp WSDL theo trình tự. Các tệp WSDL lớn, phức tạp với nhiều lược đồ được nhập mất thời gian và không có khả năng cấu hình song song.
Chi phí bộ nhớ. JVM, Swing và framework Spring cùng nhau tiêu thụ bộ nhớ bất kể kích thước dự án. Mức 300-400 MB khi không hoạt động là điển hình.

Khi nào nên chuyển đổi

Nếu bạn đã áp dụng các biện pháp khắc phục trên mà SoapUI vẫn cản trở quy trình làm việc của bạn, thì nút thắt cổ chai có thể không thể khắc phục được thông qua cấu hình.

Apidog chạy dưới dạng ứng dụng web được hỗ trợ bởi một client Node.js, không phải JVM. Nó mở trong vài giây. Việc thực thi kiểm thử không yêu cầu môi trường thực thi Java trên máy của bạn. Đối với các nhóm mà nút thắt chính là thời gian khởi động của SoapUI và khả năng phản hồi của giao diện người dùng, việc chuyển đổi công cụ sẽ hiệu quả hơn là liên tục tinh chỉnh JVM.

Đánh đổi: Apidog không phân tích cú pháp WSDL. Nếu bạn phụ thuộc vào tính năng nhập WSDL của SoapUI để tích hợp dịch vụ mới, bạn có thể muốn giữ SoapUI cho tác vụ cụ thể đó trong khi thực hiện kiểm thử hàng ngày trong Apidog.

Câu hỏi thường gặp

Kích thước heap khuyến nghị cho SoapUI với một dự án lớn (hơn 50 bộ kiểm thử) là bao nhiêu?Đặt -Xmx ít nhất là 2 GB, lý tưởng là 4 GB nếu máy của bạn có 16 GB RAM trở lên. Đặt -Xms từ 512 MB đến 1 GB để tránh việc mở rộng heap dần dần. Sử dụng -XX:+UseG1GC để có hiệu suất thu gom rác tốt hơn.

Tôi có thể kiểm tra việc sử dụng heap hiện tại của SoapUI không?Có. Vào Help > System Properties. Điều này hiển thị các đối số JVM bao gồm cài đặt heap. Bạn cũng có thể thêm -verbose:gc vào các tùy chọn JVM tạm thời để xem hoạt động thu gom rác trong nhật ký của SoapUI.

Việc chuyển sang JDK mới hơn có cải thiện hiệu suất của SoapUI không?Trong hầu hết các trường hợp, có. Thời gian khởi động JVM và việc thu gom rác đã được cải thiện trong Java 11 và 17 so với Java 8. Kiểm tra ghi chú phát hành của SoapUI để biết phiên bản JDK được khuyến nghị, vì một số phiên bản JDK mới hơn có thể có vấn đề tương thích với các bản phát hành SoapUI cũ hơn.

Tại sao SoapUI lại chậm lại sau khi chạy kiểm thử vài giờ?Phân mảnh bộ nhớ và chi phí thu gom rác tăng lên theo thời gian. Đóng và mở lại SoapUI sẽ đặt lại trạng thái JVM. Việc tăng -Xmx và sử dụng G1GC làm trì hoãn sự suy giảm này nhưng không loại bỏ hoàn toàn.

Chạy SoapUI trên máy chủ (headless) có cải thiện hiệu suất không?Có, ở một mức độ nào đó. Chế độ headless (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false và các cờ tương tự) giảm chi phí hiển thị Swing. Sử dụng công cụ chạy kiểm thử dòng lệnh cho CI/CD thay vì giao diện người dùng đồ họa (GUI) để có hiệu suất tốt nhất.

Apidog xử lý các bộ sưu tập lớn như thế nào so với SoapUI?Apidog lưu trữ các bộ sưu tập trên đám mây và tải chúng theo yêu cầu. Không có tệp XML cục bộ nào cần phân tích cú pháp. Việc thực thi kiểm thử sử dụng một trình chạy CLI cục bộ không yêu cầu khởi tạo JVM.

Hầu hết các vấn đề về hiệu suất của SoapUI đều có cách khắc phục. Riêng việc thay đổi kích thước heap thường mang lại hiệu quả rõ rệt ngay lập tức. Hãy bắt đầu từ đó trước khi thử các giải pháp phức tạp hơn.