Để thực hiện mô phỏng yêu cầu của ngƣời dùng, chúng ta sử dụng công cụ đo tự động Apache Jmeter[5]. Apache Jmeter cho phép giả lập số lƣợng ngƣời dùng với số lƣợng tùy ý, tạo các test case theo ý muốn và lƣu lại các kết quả đo (throughput, response time) với độ chính xác caọ Apache Jmeter là phần mềm mã nguồn mở, viết 100% bằng ngôn ngữ Java, đƣợc thiết kế để thực hiện các phép kiểm thử chức năng cũng nhƣ đo hiệu năng theo mô hình Client/Server. Jmeter có thể đƣợc sử dụng để kiểm thử của những tài nguyên tĩnh và động nhƣ các file, Servlet, Perl, các đối tƣợng Java, CSDL và truy vấn, máy chủ FTP…Nó cũng đƣợc dùng để mô phỏng tải lớn trên máy chủ, mạng hoặc các đối tƣợng để kiểm thử khả năng chịu đựng bền bỉ, hay phân tích hiệu năng khi thực hiện những tải khác nhaụ Jmeter cung cấp giao diện đồ họa để ngƣời dùng dễ dàng phân tích và so sánh hiệu năng khi thực hiện phép thử.
Jmeter cho phép kiểm thử trên nhiều loại ứng dụng thông qua việc hỗ trợ giao thức nhƣ: các ứng dụng Web qua giao thức http, https, giao thức SOAP, CSDL thông qua JDBC, LDAP, JMS, Web Servicẹ Jmeter cung cấp giao diện đồ họa thân thiện nên ngƣời dùng có thể dễ dàng tạo các kịch bản mà không mất nhiều thời gian tìm hiểụ Ngƣời dùng cũng có thể dễ dàng tùy biến, cấu hình để tạo nên các kịch bản kiểm thử
khác nhaụ Jmeter hỗ trợ đầy đủ nền tảng đa luồng, cho phép các phép lấy mẫu đồng thời thực hiện bởi nhiều luồng trên nhiều chức năng khác nhaụ Chính nhờ công nghệ này mà Jmeter có thể thực hiện đo trên số lƣợng không giới hạn ngƣời dùng cũng nhƣ ứng dụng. Ngoài ra Jmeter còn có khả năng thực hiện kiểm thử trên nhiều máy chủ, để mô phỏng việc sử dụng thật trong thực tế. Trong mô hình này, Jmeter đƣợc cài đặt trên nhiều máy trạm để thực hiện kiểm thử, một máy trạm sẽ thực hiện việc cấu hình thông số đo cũng nhƣ lấy kết quả về để tổng hợp và phân tích. Để việc mô phỏng ngƣời dùng thực đƣợc chính xác, Jmeter còn cung cấp đối tƣợng Timer để ngƣời đo có thể tùy biến “Think time” theo một cách ngẫu nhiên để mô phỏng thời gian “suy nghĩ” của ngƣời dùng thực.
Hình 3.4Kết quả đo bằng Jmeter
Jmeter cung cấp kết quả đo chính xác với nhiều thông số đo nhƣ: số mẫu đo, thời gian phản hồi (trung bình, nhỏ nhất, lớn nhất), throughput (số object xử lý trong 1s), tỉ lệ lỗị Đặc biệt, Jmeter hỗ trợ hiển thị kết quả ngay dƣới dạng biểu đồ giúp ngƣời dùng có thể sử dụng ngay kết quả để phân tích mà không cần qua bƣớc xử lý trung gian. Để xây dựng một test case cho dịch vụ Web, chúng ta cần thực hiện các bƣớc sau đây:
Bước 1: Thêm ngƣời dùng (virtual users):
Sử dụng đối tƣợng ThreadGroup để cấu hình bao nhiêu ngƣời dùng và số lƣợng là bao nhiêụ Chọn Test Plan, chuột phải và chọn menu Ađ, chọn Threads(users) =>Ađ ThreadGroup. Tiếp theo ta cần cấu hình số lƣợng ngƣời dùng, giả sử ta cần giả lập 5 ngƣời dùng, mỗi ngƣời gửi 4 yêu cầu, 5 ngƣời dùng sẽ khởi động hệ thống và gửi yêu cầu tại cùng một thời điểm, ta có cấu hình nhƣ hình dƣới đây:
Hình 3.5 Cấu hình ngƣời dùng sử dụng Thread Group
Bước 2: Tạo đối tƣợng gửi yêu cầu WebService: sử dụng menu Ađ --> Sampler -- >WebService(SOAP) Request để thêm một đối tƣợng WebService(SOAP) Request. Sau đó, sửa đổi các trƣờng textbox nhƣ sau:
Trƣờng Name: Ví dụ đặt là “ODE While” để chỉ gọi Webservice của ứng dụng dịch vụ Web mô phỏng tác vụ While
WSDL URL: Đƣa đƣờng dẫn WSDL của ứng dụng Dịch vụ Web và click “Load WSDL”, ví dụ: http://localhost:8080/ode/processes/WhileSamplẻwsdl. Sau khi click, Web Methods của WebService sẽ xuất hiện. Tiếp tục click nút Configure, các thông tin của Dịch vụ Web sẽ đƣợc điền vào các ô textbox. WebService Message: Đƣa message gửi cho WebServicẹ Ngoài ra có thể chỉ
đến đƣờng dẫn file XML chứa sẵn message cần gửị
Bảng 3.3 Thông điệp gửi yêu cầu đến Dịch vụ Web
<soapenv:Envelope XMLns:q0="http://www.examplẹorg/While_OS" XMLns:soapenv="http://schemas.XMLsoap.org/soap/envelope/" XMLns:xsd="http://www.w3.org/2001/XMLSchema" XMLns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header></soapenv:Header> <soapenv:Body> <q0:request>welcome !</q0:request> </soapenv:Body> </soapenv:Envelope>
Hình 3.6Cấu hình phép thử với dịch vụ Web
Bước 3: Tạo đối tƣợng Timer để cấu hình Think Time
Từ đối tƣợng Thread Group, chọn Ađ=> Timers => Gaussian Random Timer. Chúng ta sẽ cấu hình thời gian “Think time” của ngƣời dùng thay đổi theo xác xuất Gaussian với giá trị trung bình là 1000ms (1s) và độ lệch chuẩn là 500ms(0.5s).
Bước 4: Thêm đối tƣợng Listener để hiển thị kết quả:
Từ đối tƣợng Thread Group, chọn Ađ -> Listener -> Aggregate Report.Để chạy công cụ Jmeter, click vào nút Start trên thanh công cụ. Sau khi thực hiện xong, nút Start sẽ chuyển lại màu xanh và kết quả sẽ đƣợc lƣu lại trong màn hình Aggregate Report. 3.3 Thực hiện đo
Để đo các ứng dụng Dịch vụ Web, chúng ta thực hiện các bƣớc sau đây:
Bật các trình xử lý BPEL trên các “máy chủ”, đã deploy sẵn các ứng dụng dịch vụ Web. Để cô lập môi trƣờng, chúng ta sẽ chỉ bật một trình xử lý ở tại một thời điểm.
Khởi động Jmeter trên máy trạm (nối cáp chéo).
Tạo kịch bản trên Jmeter gửi yêu cầu đến máy chủ. Jmeter sẽ ghi lại thời gian phản hồi theo 3 thông số: thời gian phản hồi trung bình, nhỏ nhất và lớn nhất. Tăng dần số lƣợng ngƣời dùng đồng thời từ 1,2… 500.
Các ứng dụng dịch vụ Web đƣợc triển khai trên các trình xử lý BPEL Apache ODE, ActiveVOS, Oracle BPEL Process Manager chạy trên máy tính có hệ điều hành phiên bản Window 7 Professional 32 bit có cấu hình: Intel Dual Core T9400 2.53 GHz, 3 GB RAM. Phần mềm Apache JMeter chạy trên máy tính khác có hệ điều hành phiên bản Window 7 Professional 32 bit với cấu hình: Intel Dual Core E8400 3.00 GHz, 3 GB
RAM. Hai máy chủ đƣợc kết nối với nhau trực tiếp để cô lập môi trƣờng, đảm bảo tính khách quan của kết quả đọ Trong hình 3.7 mô tả cấu hình môi trƣờng đo gồm có 1 máy chủ chạy Apache Jmeter, 1 máy chủ chạy dịch vụ Web cho tác vụ cần đo và 1 máy chủ chạy dịch vụ Web ngoàị Máy chủ chạy dịch vụ Web ngoài “HelloWorld” chỉ sử dụng cho dịch vụ Web BPEL_Invoke mô phỏng tác vụ Invoke.
Hình 3.7Mô hình đo hiệu năng của trình xử lý BPEL
Với mỗi ứng dụng trên một trình xử lý BPEL, chúng ta sẽ thực hiện đo đạc nhiều lần, ở nhiều mức độ ngƣời sử dụng đồng thờị Số lƣợng ngƣời dùng đồng thời là một yếu tố quan trọng ảnh hƣởng đến hiệu năng hệ thống. Chúng ta sẽ tăng dần số lƣợng ngƣời dùng đồng thời theo thứ tự từ 1,2… 500 để đánh giá sự thay đổi khi tải của hệ thống tăng từ thấp đến caọ Số lƣợng ngƣời dùng có ý nghĩa quan trọng đối với hiệu năng vì nó sẽ cho thấy khả năng mở rộng (scalability) của các trình xử lý BPEL. Với mỗi đợt đo tƣơng ứng với một số lƣợng ngƣời dùng, chúng ta sẽ thực hiện đo nhiều lần và lấy trung bình để tăng độ tin cậy của kết quả đọ Ngoài ra, để tăng tính chính xác của việc mô phỏng, chúng ta sẽ cấu hình “think time” để mô phỏng các yêu cầu giống nhƣ môi trƣờng thật – “think time” là thời gian tính từ lúc ngƣời dùng nhận kết quả của yêu cầu thứ nhất đến lúc gửi yêu cầu thứ hai – cho các yêu cầu đo đạc. Do thời gian này thƣờng không cố định nên ta sẽ dùng xác suất với độ lệch chuẩn là 1s (1000ms) và biên độ dao động là 0.5s (500ms) – tức là ngƣời dùng sau khi gửi yêu cầu sẽ chờ đợi khoảng 1s trƣớc khi gửi yêu cầu tiếp theọ Tham số này đƣợc cấu hình dựa trên đối tƣợng Gaussian Random Timer của Apache Jmeter.
Đối tƣợng Listener của Jmeter sẽ có nhiệm vụ lắng nghe kết quả trả về và ghi lại thời gian phản hồi kết quả. Để tăng độ chính xác của kết quả đo, chúng ta sẽ thực hiện đo nhiều lần và lấy kết quả trung bình.
3.4 So sánh và đánh giá hiệu năng từ kết quả đo đạc
3.4.1 Đánh giá hiệu năng các trình xử lý
Oracle BPEL Process Manager (adsbygoogle = window.adsbygoogle || []).push({});
Hình 3.9Biểu đồ thời gian trả về trung bình của Oracle BPEL Process Manager Khi chạy các phép thử trên trình xử lý cho thấy, các phép thử đều thành công với Oracle BPEL Process Manager, khi số lƣợng user tăng dần từ 1 đến 500, mà không phát sinh một lỗi nàọ Khi tăng số lƣợng ngƣời dùng kết nối đồng thời lên dần thì thời gian trả về có tăng thêm nhƣng vẫn đảm bảo không vƣợt quá thời gian timeout (30s). Nhƣ vậy có thể khẳng định trình xử lý Oracle BPEL có khả năng đáp ứng đƣợc cùng lúc 500 ngƣời dùng đồng thờị
So sánh kết quả của 2 tác vụ Flow và FlowDep thì tác vụ FlowDep có thời gian trả về trung bình khoảng >2000ms, trong khi tác vụ Flow chỉ có thời gian trả về trung bình <1600ms. Nguyên nhân là do trong tác vụ Flow, các luồng thực hiện song song, còn tác vụ FlowDep thì luồng này phải đợi kết quả luồng kia nên chậm hơn. Tuy nhiên, khi số lƣợng ngƣời dùng lớn (500) thì sự sai khác này không đáng kể.
ActiveVOS
Bảng 3.4 Bảng thống kê tỉ lệ lỗi của ActiveVOS
Số người dùng While Flow FlowDep Seauence If-Else Invoke
1..100 0% 0% 0% 0% 0% 0%
200 38.17% 0% 0% 0% 0% 0%
500 87.13% 0% 0% 0% 0% 59.74%
Hình 3.10Biểu đồ thời gian trả về trung bình của ActiveVOS
Nhìn vào biểu đồ thời gian xử lý trung bình các tác vụ của ActiveVOS có thể thấy khi số lƣợng user từ 1-25 thì thời gian phản hồi có sự khác nhau không đáng kể. Khi số lƣợng ngƣời dùng lớn hơn 25 thì thời gian phản hồi tăng nhanh rõ rệt, và bắt đầu xuất hiện lỗi (đƣợc thể hiện bằng các vòng tròn nhỏ). Với số lƣợng ngƣời dùng nhỏ, tác vụ Flow thực hiện nhanh hơn FlowDep (Flow và FlowDep có cùng nghiệp vụ), tuy nhiên khi đạt đến 200 ngƣời dùng thì chúng nhƣ nhau và khi 500 thì thời gian phản hồi của Flow lại lâu hơn FlowDep.
Nhìn chung, các tác vụ mà trình xử lý ActiveVOS thực hiện đều vƣợt qua tất cả các phép thử, chỉ có tác vụ Invoke có đến 59.74% trƣờng hợp lỗi khi có 500 ngƣời dùng đồng thời, và tác vụ While có 38.17% tỉ lệ lỗi khi có 200 ngƣời dùng đồng thời kết nốị Lỗi thông báo “Retrying transaction to save journal entry” có nghĩ là tại thời điểm đó, giao dịch không thể thực hiện đƣợc và bị trả lại (rollback). Kiểm tra tải của hệ thống tại thời điểm có lỗi đều chiếm 100%CPU của máy chủ.Các tác vụ khác nhƣ
Flow, FlowDep, Sequence, If có thời gian trả về vƣợt quá 30s nhƣng không có thông báo lỗi, mà chỉ do hệ thống nghẽn và trả về kết quả chậm. Khi có 500 ngƣời dùng kết nối đồng thời, tài nguyên hệ thống gần nhƣ đƣợc sử dụng hết.
Nhƣ vậy, ta đánh giá trình xử lý OS cho phép nhiều nhất 500 ngƣời dùng kết nối gửi yêu cầu đồng thời, với tác vụ While và Invoke chỉ cho tối đa 200 ngƣời dùng. Tác vụ FlowDep cũng trả về kết quả chậm hơn so với tác vụ Flow, điều này tƣơng tự nhƣ kết quả với trình xử lý Oracle BPEL Process Manager. Giữa tác vụ FlowDep và tác vụ Sequence, kết quả trả về có sự khác nhau nhƣng không đáng kể.
Apache ODE
Hình 3.11Biểu đồ thời gian trả về trung bình của Apache ODE Bảng 3.5Bảng thống kê tỉ lệ lỗi của Apache ODE
#Users While Flow FlowDep Sequence If-Else Invoke
Tăng ngƣời
dùng từ 1..10 0% 0% 0% 0% 0% 0%
25 34.57% 100.00% 98% 98% 68% 45%
Các tác vụ trên trình xử lý Apache ODE không vƣợt qua đƣợc tất cả các phép thử, hầu nhƣ các tác vụ đều gặp lỗi ở mức 25 ngƣời dùng đồng thời kết nốị Với 25 ngƣời dùng gửi yêu cầu đồng thời thì với 1-2 lƣợt request đầu tiên, các yêu cầu đều đƣợc đáp ứng, tuy nhiên đến lƣợt yêu cầu tiếp theo thì phát sinh ra các ngoại lệ (exception). Ví dụ với tác vụ While thì khi có 25 user đồng thời gửi yêu cầu đến thì có đến 34.57% lỗi, còn ví
dụ Invoke thì có tỉ lệ lỗi là 45% (đƣợc thể hiện trên hình 3.12 bằng các vòng tròn nhỏ). Nhƣ vậy có thể khẳng định trình xử lý Apache ODE chỉ có thể phục vụ tối đa không quá 25 ngƣời dùng đồng thờị
Kiểm tra tải của máy chủ tại thời điểm bị lỗi thì thấy tài nguyên máy chủ (CPU, Mem) đều dƣới 50%, chứng tỏ nguyên nhân lỗi không phải do thiếu tài nguyên. Phân tích các mã lỗi trả về cho thấy các lỗi đều liên quan đến Database, khi trình xử lý Apache ODE không thể ghi vào CSDL do có tranh chấp tài nguyên (deadlock), dẫn đến không trả về kết quả cho ngƣời dùng. Những giao dịch mà trình xử lý không thể ghi vào trong CSDL sẽ đƣợc trả lại(rollback) và đƣợc lập lịch thực thi trong tƣơng laị Khi khởi động lại trình xử lý, các yêu cầu này tiếp tục đƣợc xử lý lại, gây nghẽn cho các yêu cầu mới gửi đến. Chỉ khi xóa thông tin của các yêu cầu đƣợc gửi đến trong CSDL thì Apache ODE mới ngừng thực hiện chúng.
3.4.2 So sánh thời gian xử lý của các trình BPEL
Tiếp theo, chúng ta sẽ lần lƣợt so sánh thời gian xử lý của các trình BPEL khi thực hiện cùng một tác vụ cụ thể: While, Flow, FlowDep, Sequence, If-else, Invokẹ
While
Hình 3.12 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ While Nhìn chung, tác vụ While trên Oracle cho thời gian phản hồi trung bình nhanh hơn so với ActiveVOS và ActiveVOS nhanh hơn so với ODẸ Với số lƣợng ngƣời dùng càng lớn thì sự khác biệt này càng rõ ràng.
Hình 3.13So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Flow So sánh thời gian phản hồi trung bình của tác vụ Flow với số lƣợng ngƣời dùng đồng thời nhỏ (<=10) trên các trình xử lý BPEL có thể thấy thời gian trên các trình xử lý có sự khác nhau không đáng kể. Trình xử lý Oracle BPEL Process Manager có thời gian phản hồi ổn định nhất cho dù số lƣợng ngƣời dùng tăng từ 1 đến 500 ngƣời dùng.
FlowDep
Hình 3.14So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ FlowDep Với số lƣợng user đồng thời <200, thời gian trả về của các trình xử lý ActiveVOS và Oracle không có sự khác nhau nhiềụ Với 500 thì xu hƣớng tăng của ActiveVOS trở nên tuyên tính.
Sequence (adsbygoogle = window.adsbygoogle || []).push({});
Hình 3.15So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Sequence Với số lƣợng ngƣời dùng <10, cả 3 trình xử lý có thời gian trả về không khác nhau nhiềụ Với số lƣợng ngƣời dùng từ 10 đến 500, có sự thay đổi về mức độ tăng: ActiveVOS gần nhƣ có thời gian trả về tăng tuyến tính với độ dốc cao, trong khi Oracle BPEL Process Manager chỉ thay đổi một chút. Điều đó chứng tỏ trình xử lý Oracle BPEL luôn giữ đƣợc sự ổn định ngay cả khi số lƣợng ngƣời dùng đồng thời đạt đến 500.
IF-Else
Với số lƣợng ngƣời dùng <10, thời gian trả về của 3 trình xử lý là nhƣ nhaụ Từ 25 ngƣời dùng trở lên chỉ còn ActiveVOS và Oracle tiếp tục có khả năng xử lý, tuy nhiên ActiveVOS có thời gian trả về lớn hơn nhiều so với Oraclẹ Biểu đồ cho thấy xu hƣớng tăng của ActiveVOS max và ActiveVOS avg gần nhƣ tuyến tính với độ dốc caọ
Invoke
Hình 3.17So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Invoke So sánh tác vụ If và tác vụ Invoke: Với số lƣợng ngƣời dùng nhỏ và vừa (1-100) thì thời gian trả về giữa các trình xử lý không có sự khác biệt. Nhƣ vậy so với các tác vụ khác thì thời gian mà ActiveVOS xử lý tiệm cận với Oracle cao hơn (đến mức 100 users, trong khi các tác vụ khác mới chỉ 25 user đã có sự thay đổi). Tuy nhiên với phép