SoapUI ทำงานช้า: สาเหตุและวิธีแก้ไข

สรุป

ประสิทธิภาพที่ช้าของ SoapUI เกิดจากค่าใช้จ่ายในการเริ่มต้น JVM, การตั้งค่าหน่วยความจำเริ่มต้นที่ต่ำเกินไปสำหรับโปรเจกต์ขนาดใหญ่ และความล่าช้าในการแยกวิเคราะห์ WSDL. การแก้ไขเฉพาะจุด (การปรับแต่งขนาดฮีป, การแคช WSDL, การแบ่งโปรเจกต์) สามารถปรับปรุงความเร็วได้อย่างมีนัยสำคัญ. หากทีมของคุณต้องการเครื่องมือที่เร็วกว่าและหลีกเลี่ยงปัญหาคอขวดเหล่านี้ทั้งหมด Apidog สามารถทำงานได้โดยไม่ต้องใช้ Java runtime.

💡

Apidog เป็นแพลตฟอร์มพัฒนา API แบบครบวงจรฟรี ที่ทำงานบนเบราว์เซอร์หรือแอปเดสก์ท็อปขนาดเล็ก ซึ่งช่วยหลีกเลี่ยงค่าใช้จ่าย JVM และการปรับแต่งหน่วยความจำทั้งหมด. ลองใช้ Apidog ฟรี ไม่ต้องใช้บัตรเครดิต.

button

บทนำ

SoapUI ทำงานช้า หากคุณเคยใช้งานมานานกว่าสองสามสัปดาห์ คุณคงเคยพบกับการเริ่มต้นโปรแกรมที่ใช้เวลา 30 วินาที, UI ที่ไม่ตอบสนองขณะแยกวิเคราะห์ WSDL ขนาดใหญ่, หรือการทดสอบที่ทำงานเชื่องช้าเมื่อคุณมีขั้นตอนการทดสอบหลายร้อยขั้นตอน. นี่ไม่ใช่ข้อผิดพลาด แต่เป็นผลลัพธ์ตามธรรมชาติของวิธีการสร้าง SoapUI.

คู่มือนี้จะอธิบายเหตุผลทางเทคนิคเฉพาะที่ทำให้ SoapUI ช้า, ให้แนวทางแก้ไขที่เป็นรูปธรรมสำหรับแต่ละปัญหา และอธิบายข้อจำกัดต่างๆ. ความช้าบางส่วนคุณสามารถแก้ไขได้ แต่บางส่วนคุณไม่สามารถแก้ไขได้หากไม่เปลี่ยนไปใช้เครื่องมืออื่น.

สาเหตุที่ 1: ค่าใช้จ่ายในการเริ่มต้น JVM

SoapUI เป็นแอปพลิเคชัน Java Swing. ทุกครั้งที่คุณเปิดใช้งาน มันจะเริ่มต้น Java Virtual Machine (JVM), โหลดไฟล์คลาสหลายร้อยไฟล์, เริ่มต้น Spring framework, โหลดโปรเจกต์ของคุณ และเรนเดอร์อินเทอร์เฟซ Swing. บนเครื่องที่ทันสมัยพร้อม SSD, ขั้นตอนนี้ใช้เวลา 20-60 วินาที. บนฮาร์ดแวร์ที่เก่ากว่า อาจใช้เวลากว่า 90 วินาที.

เหตุผลที่เกิด: แอปพลิเคชัน Java มีค่าใช้จ่ายในการเริ่มต้นที่แอปพลิเคชันเนทีฟไม่มี. JVM จำเป็นต้องตีความหรือคอมไพล์ JIT bytecode ก่อนที่จะเริ่มดำเนินการ. การเริ่มต้น UI ของ Swing ก็เพิ่มภาระเข้าไปด้วย.

วิธีแก้ไข:

เปิด SoapUI ทิ้งไว้. วิธีแก้ไขที่ง่ายที่สุดคืออย่าปิดมันระหว่างการรันทดสอบ. เมื่อ JVM ทำงานอยู่ มันก็จะคงสถานะพร้อมใช้งาน.

ใช้ดิสก์ที่เร็ว. หากคุณกำลังรัน SoapUI จากฮาร์ดดิสก์แบบจานหมุน ให้ย้ายไปติดตั้งบน SSD. ขั้นตอนการโหลดคลาสจะอ่านไฟล์ขนาดเล็กจำนวนมาก ซึ่งเป็นจุดที่ SSD มีประสิทธิภาพเหนือกว่า HDD อย่างเห็นได้ชัด.

ใช้ Java 11 หรือ 17 แทน 8. JVM เวอร์ชันใหม่กว่ามีการปรับปรุงเวลาเริ่มต้นให้ดีขึ้น. ตรวจสอบว่า SoapUI กำหนดค่าให้ใช้ JDK เวอร์ชันใดใน soapui.bat (Windows) หรือ soapui.sh (Linux/Mac). บรรทัดแรกจะเป็นการกำหนดค่า Java home path. การเปลี่ยนไปใช้ JDK เวอร์ชันใหม่กว่าสามารถลดเวลาเริ่มต้นได้.

เปิดใช้งาน AppCDS (Application Class Data Sharing). คุณสมบัติ JVM นี้จะแคชข้อมูลการโหลดคลาสล่วงหน้า. ต้องมีการตั้งค่าเพียงครั้งเดียว แต่จะช่วยลดเวลาเริ่มต้นในครั้งถัดไป. เพิ่ม -XX:+UseAppCDS -XX:SharedArchiveFile=soapui.jsa ลงในอาร์กิวเมนต์ JVM ของคุณ.

สาเหตุที่ 2: การตั้งค่าหน่วยความจำเริ่มต้นต่ำเกินไป

SoapUI มาพร้อมกับการตั้งค่าขนาดฮีปเริ่มต้นที่ต่ำ. การเปิดโปรเจกต์ขนาดใหญ่หรือการรันชุดทดสอบที่ยาวนาน ทำให้ JVM ใช้เวลาในการเก็บขยะ (garbage collection) ซึ่งจะหยุดการทำงานของแอปพลิเคชันชั่วคราวและทำให้รู้สึกเชื่องช้า.

การตั้งค่าเริ่มต้น (จาก soapui.vmoptions หรือ soapui.bat):

-Xms128m
-Xmx768m

นี่หมายความว่า SoapUI เริ่มต้นด้วยฮีปขนาด 128 MB และสามารถใช้ได้สูงสุด 768 MB. เครื่องคอมพิวเตอร์สมัยใหม่มี RAM ขนาด 8-32 GB. การปล่อยให้ SoapUI ใช้เพียง 768 MB ทำให้เกิดแรงกดดันจากการเก็บขยะอย่างต่อเนื่องกับโปรเจกต์ขนาดใหญ่ใดๆ.

วิธีแก้ไข: เพิ่มขนาดฮีป

บน Windows ให้แก้ไข <SoapUI_Install>/bin/SoapUI.vmoptions:

-Xms512m
-Xmx2048m

บน macOS ให้แก้ไข SoapUI.app/Contents/vmoptions.txt หรือค้นหา soapui.sh:

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

บน Linux ให้แก้ไข <SoapUI_Install>/bin/soapui.sh:

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

คำแนะนำ:

ตั้งค่า -Xms (ฮีปเริ่มต้น) เป็น 512 MB หรือสูงกว่า หากคุณมี RAM เหลือเฟือ. ซึ่งจะช่วยหลีกเลี่ยงการขยายฮีปแบบค่อยเป็นค่อยไป.
ตั้งค่า -Xmx (ฮีปสูงสุด) เป็น 2 GB สำหรับโปรเจกต์ขนาดกลาง, 4 GB สำหรับโปรเจกต์ขนาดใหญ่. อย่าตั้งค่าเกินครึ่งหนึ่งของ RAM ที่คุณมี.
เพิ่ม -XX:+UseG1GC หากคุณใช้ Java 9+. G1GC ช่วยลดเวลาหยุดชั่วคราวเมื่อเทียบกับ garbage collector เริ่มต้น.
เพิ่ม -XX:MaxMetaspaceSize=512m เพื่อป้องกันไม่ให้ metaspace (ข้อมูลเมตาของคลาส) เติบโตอย่างไม่มีขอบเขต.

การตรวจสอบการแก้ไข: หลังจากรีสตาร์ท SoapUI ให้เปิดกล่องโต้ตอบ Help > System Properties. คุณควรเห็นค่าฮีปที่อัปเดตแล้ว. ตรวจสอบตัวจัดการงาน (task manager) เพื่อยืนยันว่า SoapUI กำลังใช้การจัดสรรใหม่.

สาเหตุที่ 3: ไฟล์โปรเจกต์ขนาดใหญ่

SoapUI เก็บทุกอย่างไว้ในไฟล์ XML ไฟล์เดียว. โปรเจกต์ที่มีชุดทดสอบจำนวนมาก, เนื้อหาคำขอขนาดใหญ่ หรือข้อมูลไบนารีที่ฝังอยู่ จะทำให้ไฟล์นี้มีขนาดใหญ่ขึ้น. การเปิดและบันทึกไฟล์โปรเจกต์ขนาด 10 MB จะช้ากว่าไฟล์ขนาด 500 KB อย่างเห็นได้ชัด.

สัญญาณของปัญหานี้:

SoapUI หยุดชั่วคราวหลายวินาทีเมื่อคุณบันทึก (Ctrl+S)
ไฟล์โปรเจกต์บนดิสก์มีขนาดหลายเมกะไบต์
การเปิดโปรเจกต์ใช้เวลามากกว่า 10 วินาที หลังจาก SoapUI เริ่มทำงานอยู่แล้ว

วิธีแก้ไข:

แบ่งโปรเจกต์ขนาดใหญ่. SoapUI รองรับ composite projects ที่จัดเก็บชุดทดสอบเป็นไฟล์ XML แยกต่างหากในไดเรกทอรี. เปิดใช้งานคุณสมบัตินี้ได้ที่ Project > Settings > Composite Project. ซึ่งช่วยให้สามารถโหลดบางส่วนและบันทึกได้เร็วขึ้น.

ลบเคสทดสอบที่ไม่ได้ใช้. เก็บถาวรหรือลบเคสทดสอบที่ไม่เกี่ยวข้องอีกต่อไป. เคสทดสอบแต่ละรายการที่มีสคริปต์และข้อมูลคำขอจะเพิ่มขนาดไฟล์ XML.

แยกเนื้อหาคำขอขนาดใหญ่ออกมา. หากขั้นตอนการทดสอบของคุณใช้เนื้อหา XML หรือ JSON ขนาดใหญ่แบบฝังในตัว ให้พิจารณาใช้พารามิเตอร์และโหลดจากไฟล์ภายนอกโดยใช้ DataSource แบบไฟล์ของ SoapUI.

ปิดใช้งานการสำรองข้อมูลอัตโนมัติ “save on exit”. SoapUI จะสร้างสำเนาสำรองเมื่อปิดโปรแกรม. ปิดใช้งานสิ่งนี้ได้ที่ Preferences > UI Settings เพื่อหลีกเลี่ยงการเขียนข้อมูลลงดิสก์เพิ่มเติมเมื่อปิดโปรแกรม.

สาเหตุที่ 4: ความล่าช้าในการแยกวิเคราะห์ WSDL

เมื่อ SoapUI เปิดโปรเจกต์ที่อ้างอิงไฟล์ WSDL มันสามารถแยกวิเคราะห์ WSDLs เหล่านั้นใหม่เมื่อเริ่มต้น หรือเมื่อคุณขยายโครงสร้างอินเทอร์เฟซ. หาก WSDLs ของคุณโฮสต์อยู่บนเซิร์ฟเวอร์ระยะไกลหรือมีขนาดใหญ่ (การทำงานจำนวนมาก, ประเภทที่ซับซ้อน), การแยกวิเคราะห์นี้จะเพิ่มความล่าช้าอย่างมีนัยสำคัญ.

สัญญาณของปัญหานี้:

SoapUI ค้างหรือไม่ตอบสนอง หรือแสดงตัวบ่งชี้การโหลดเมื่อขยายอินเทอร์เฟซ
การทดสอบล้มเหลวด้วยข้อผิดพลาดการหมดเวลาการเชื่อมต่อก่อนที่จะเริ่ม
เครื่องคอมพิวเตอร์ที่แตกต่างกันโหลดโปรเจกต์ด้วยความเร็วที่แตกต่างกัน (ขึ้นอยู่กับเครือข่าย)

วิธีแก้ไข:

แคช WSDLs แบบโลคอล. ใน SoapUI ให้คลิกขวาที่อินเทอร์เฟซ > Update Definition. เปลี่ยน URL ของคำจำกัดความให้ชี้ไปยังสำเนาไฟล์ WSDL ในเครื่องแทน URL ระยะไกล. ซึ่งช่วยลดความหน่วงของเครือข่ายในการโหลดแต่ละครั้ง.

ตั้งค่า URL ของคำจำกัดความเป็นเส้นทาง file://. เมื่อคุณมีสำเนา WSDL ในเครื่องแล้ว ให้อัปเดต URL คำจำกัดความของอินเทอร์เฟซเป็น file:///path/to/your/service.wsdl. SoapUI จะโหลดจากดิสก์ได้ทันที.

ปิดใช้งานการอัปเดตคำจำกัดความอัตโนมัติ. ใน Preferences > WS-Security Settings ให้ยกเลิกการเลือกตัวเลือกที่บังคับให้ WSDL ตรวจสอบความถูกต้องใหม่เมื่อเริ่มต้น.

เพิ่มการตั้งค่า HTTP timeout. หาก WSDLs บนเครือข่ายตอบสนองช้า ให้ไปที่ Preferences > HTTP Settings และเพิ่ม connection timeout. ซึ่งจะป้องกันไม่ให้ SoapUI ค้างเป็นเวลานานบนเซิร์ฟเวอร์ WSDL ที่ช้า.

สาเหตุที่ 5: ประสิทธิภาพการรันทดสอบบนชุดทดสอบขนาดใหญ่

การรันชุดทดสอบที่มีเคสทดสอบหลายร้อยรายการอาจช้า โดยเฉพาะอย่างยิ่งเมื่อแต่ละขั้นตอนการทดสอบมีสคริปต์ Groovy ที่ซับซ้อน, การยืนยัน (assertions), หรือการเรียกใช้เครือข่าย.

วิธีแก้ไข:

รันชุดทดสอบแบบขนาน. SoapUI รองรับการดำเนินการชุดทดสอบแบบขนาน. ใน TestSuite runner ให้เปิดใช้งานตัวเลือก “Run test cases concurrently”. ตรวจสอบให้แน่ใจว่าบริการ SOAP ของคุณรองรับการเชื่อมต่อพร้อมกัน.

ปิดใช้งานการยืนยันที่ไม่จำเป็น. การยืนยันแต่ละรายการที่ SoapUI ประเมินจะเพิ่มเวลาประมวลผล. ตรวจสอบขั้นตอนการทดสอบของคุณและลบการยืนยันที่ไม่ได้ตรวจสอบสิ่งที่มีความหมาย.

ปรับปรุงสคริปต์ Groovy ให้เหมาะสม. สคริปต์ Groovy ทำงานแบบตีความใน SoapUI. หลีกเลี่ยงการดำเนินการที่มีค่าใช้จ่ายสูงในสคริปต์ที่ทำงานสำหรับทุกขั้นตอนการทดสอบ (การแยกวิเคราะห์สตริง, regex, การสร้างอ็อบเจกต์ขนาดใหญ่). ย้ายตรรกะที่ใช้ร่วมกันไปยังไลบรารีสคริปต์ระดับโปรเจกต์.

ใช้การยืนยันเวลาตอบสนองอย่างระมัดระวัง. การยืนยัน Response SLA จะรอจนกว่าจะหมดเวลาที่กำหนดทั้งหมดก่อนที่จะล้มเหลว. หากคุณมีการยืนยัน SLA ที่เข้มงวดพร้อมกับค่าหมดเวลาที่ยาวนานบนปลายทางที่ไม่น่าเชื่อถือ สิ่งเหล่านี้อาจบล็อกชุดทดสอบทั้งหมดได้.

ลดความละเอียดของการบันทึก (logging). โดยค่าเริ่มต้น SoapUI จะบันทึกทุกคำขอและการตอบกลับ. สำหรับชุดทดสอบขนาดใหญ่ การทำงาน I/O นี้จะเพิ่มขึ้น. ไปที่ Preferences > HTTP Settings และลดสิ่งที่ถูกบันทึกระหว่างการรันทดสอบ.

สิ่งที่คุณไม่สามารถแก้ไขได้

ปัญหาประสิทธิภาพของ SoapUI บางอย่างเป็นโครงสร้างพื้นฐาน. การปรับแต่งเท่าใดก็ไม่สามารถเปลี่ยนแปลงสิ่งเหล่านี้ได้:

การเรนเดอร์ Swing UI. อินเทอร์เฟซจะรู้สึกช้ากว่าแอปพลิเคชันเนทีฟหรือเว็บแอปเสมอ. Swing เป็นเทคโนโลยีที่ล้ำสมัยในปี 2000 แต่ไม่ใช่ในปัจจุบัน.
การเริ่มต้น JVM. คุณสามารถลดได้ แต่ไม่สามารถกำจัดมันได้.
การแยกวิเคราะห์ WSDL แบบเธรดเดียว. SoapUI แยกวิเคราะห์ WSDLs ตามลำดับ. WSDLs ขนาดใหญ่และซับซ้อนที่มีหลาย schema ที่นำเข้าจะใช้เวลา, และไม่มีการกำหนดค่าสำหรับการทำงานแบบขนาน.
ค่าใช้จ่ายหน่วยความจำ (Memory overhead). JVM, Swing, และ Spring framework ใช้หน่วยความจำร่วมกันโดยไม่คำนึงถึงขนาดของโปรเจกต์. การใช้หน่วยความจำ 300-400 MB ขณะอยู่เฉยๆ เป็นเรื่องปกติ.

เมื่อไหร่ที่ควรเปลี่ยนไปใช้เครื่องมืออื่น

หากคุณได้ใช้วิธีแก้ไขข้างต้นแล้ว แต่ SoapUI ยังคงเป็นอุปสรรคต่อขั้นตอนการทำงานของคุณ ปัญหาคอขวดอาจไม่สามารถแก้ไขได้ด้วยการกำหนดค่า.

Apidog ทำงานเป็นเว็บแอปพลิเคชันที่สนับสนุนโดยไคลเอ็นต์ Node.js ไม่ใช่ JVM. มันเปิดได้ในไม่กี่วินาที. การรันทดสอบไม่จำเป็นต้องมี Java runtime บนเครื่องของคุณ. สำหรับทีมที่มีปัญหาคอขวดหลักคือเวลาเริ่มต้นของ SoapUI และการตอบสนองของ UI, การเปลี่ยนเครื่องมือจะมีประสิทธิภาพมากกว่าการปรับแต่ง JVM อย่างต่อเนื่อง.

ข้อแลกเปลี่ยน: Apidog ไม่แยกวิเคราะห์ WSDL. หากคุณต้องพึ่งพาการนำเข้า WSDL ของ SoapUI สำหรับการเริ่มต้นบริการใหม่ คุณอาจต้องการเก็บ SoapUI ไว้สำหรับงานเฉพาะนั้น ในขณะที่ทำการทดสอบประจำวันใน Apidog.

คำถามที่พบบ่อย (FAQ)

ขนาดฮีปที่แนะนำสำหรับ SoapUI ที่มีโปรเจกต์ขนาดใหญ่ (50+ ชุดทดสอบ) คือเท่าไร? ตั้งค่า -Xmx เป็นอย่างน้อย 2 GB, หรือ 4 GB จะดีที่สุดหากเครื่องของคุณมี RAM 16 GB ขึ้นไป. ตั้งค่า -Xms เป็น 512 MB ถึง 1 GB เพื่อหลีกเลี่ยงการขยายฮีปแบบค่อยเป็นค่อยไป. ใช้ -XX:+UseG1GC เพื่อประสิทธิภาพการเก็บขยะที่ดีขึ้น.

ฉันสามารถตรวจสอบการใช้งานฮีปปัจจุบันของ SoapUI ได้หรือไม่? ได้. ไปที่ Help > System Properties. ซึ่งจะแสดงอาร์กิวเมนต์ JVM รวมถึงการตั้งค่าฮีป. คุณยังสามารถเพิ่ม -verbose:gc ในตัวเลือก JVM ชั่วคราวเพื่อดูกิจกรรมการเก็บขยะในบันทึกของ SoapUI ได้.

การเปลี่ยนไปใช้ JDK เวอร์ชันใหม่กว่าช่วยปรับปรุงประสิทธิภาพของ SoapUI ได้หรือไม่? ในกรณีส่วนใหญ่, ได้. เวลาเริ่มต้นของ JVM และการเก็บขยะได้รับการปรับปรุงใน Java 11 และ 17 เมื่อเทียบกับ Java 8. ตรวจสอบบันทึกการเผยแพร่ของ SoapUI สำหรับเวอร์ชัน JDK ที่แนะนำ เนื่องจาก JDK เวอร์ชันใหม่บางเวอร์ชันอาจมีปัญหาความเข้ากันได้กับ SoapUI เวอร์ชันเก่ากว่า.

ทำไม SoapUI ถึงทำงานช้าลงหลังจากรันการทดสอบไปสองสามชั่วโมง? การแยกส่วนของหน่วยความจำ (memory fragmentation) และค่าใช้จ่ายในการเก็บขยะ (garbage collection overhead) จะเพิ่มขึ้นตามกาลเวลา. การปิดและเปิด SoapUI ใหม่จะรีเซ็ตสถานะ JVM. การเพิ่ม -Xmx และการใช้ G1GC จะช่วยชะลอการเสื่อมถอยนี้ แต่ไม่สามารถกำจัดมันได้.

การรัน SoapUI บนเซิร์ฟเวอร์ (headless) ช่วยปรับปรุงประสิทธิภาพหรือไม่? ได้, ในระดับหนึ่ง. โหมด Headless (-Dorg.uncommons.watchmaker.swing.SwingEvolutionMonitor=false และแฟล็กที่คล้ายกัน) ช่วยลดค่าใช้จ่ายในการเรนเดอร์ Swing. ใช้ command-line testrunner สำหรับ CI/CD แทน GUI เพื่อประสิทธิภาพที่ดีที่สุด.

Apidog จัดการกับคอลเลกชันขนาดใหญ่เมื่อเทียบกับ SoapUI อย่างไร? Apidog จัดเก็บคอลเลกชันในคลาวด์และโหลดตามความต้องการ. ไม่มีไฟล์ XML ในเครื่องให้แยกวิเคราะห์. การรันการทดสอบใช้ CLI runner ในเครื่องที่ไม่ต้องการการเริ่มต้น JVM.

ปัญหาประสิทธิภาพของ SoapUI ส่วนใหญ่มีวิธีแก้ไข. การเปลี่ยนแปลงขนาดฮีปเพียงอย่างเดียวมักจะมีผลทันทีและเห็นได้ชัด. เริ่มต้นที่นั่นก่อนที่จะลองใช้วิธีแก้ไขที่ซับซ้อนกว่า.