Đố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
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à 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
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 thử từ 200 ngƣời dùng trở lên thì có sự khác biệt: ODE không thực hiện đƣợc, ActiveVOS thực hiện đƣợc nhƣng thời gian trả về khá lớn (>21s), chỉ có Oracle BPEL Process Manager là có thời gian trả về nhỏ (<5s).
Kết luận: Qua các số liệu đo đạc và phân tích ở trên, chúng ta có thể thấy đƣợc sự khác biệt giữa hiệu năng của các trình xử lý BPEL. Đánh giá thời gian trả về của các trình xử lý, khi số lƣợng ngƣời dùng nhỏ (<25) thì thời gian không có sự khác biệt đáng kể, tuy nhiên, khi số lƣợng ngƣời dùng đồng thời ở tăng cao (>=200), thì chỉ có trình xử lý ActiveVOS và Oracle là trả về đƣợc kết quả, trong đó Oracle vẫn giữ đƣợc sự ổn định, còn ActiveVOS thì có xu hƣớng tăng cao tuyến tính (Với tác vụ Sequence và If-else thì từ 50 ngƣời dùng đã có sự khác biệt). Một yếu tố nữa thể hiện sự khác biệt về hiệu năng là khả năng hỗ trợ ngƣời dùng đồng thời, với Apache ODE chỉ hỗ trợ tối đa 25 ngƣời dùng, ActiveVOS hỗ trợ tối đa 500 ngƣời dùng, còn Oracle Active OS thì vẫn có thể phục vụ hơn 500 ngƣời dùng đồng thờị Lỗi trên Apache chỉ ra chức năng ghi vào CSDL không thể đáp ứng đƣợc số lƣợng ngƣời dùng lớn, dẫn đến nghẽn
trình xử lý và các yêu cầu không đƣợc xử lý. Oracle BPEL Process Manager hoạt động trên nền CSDL Oracle (phiên bản Express 11G), nên việc đọc ghi của trình xử lý đƣợc quản lý rất tốt, cho dù số lƣợng giao dịch rất lớn.
3.5 So sánh các yếu tố kỹ thuật khác
Bên cạnh yêu tố hiệu năng là tiêu chí kỹ thuật quan trọng nhất đánh giá một trình xử lý, còn có các yếu tố khác ảnh hƣởng đến việc lựa chọn một trình xử lý BPEL, ví dụ nhƣ: quá trình cài đặt đơn giản hay phức tạp, trình thiết kế BPEL có dễ dùng hay không, thời gian khởi động, lƣợng tài nguyên tiêu tốn, khả năng kiểm soát lỗi . Bảng sau so sánh các tính năng kỹ thuật khác của các trình xử lý BPEL.
Bảng 3.6Bảng so sánh các tính năng kỹ thuật của các trình xử lý BPEL
Yếu tố Apache ODE ActiveVOS Oracle
Cài đặt Cài đặt đơn giản, chỉ cần cài đặt Apache Tomcat và copy file ODẸwar
Cài đặt đơn giản theo từng bƣớc hƣớng dẫn
Cài đặt phức tạp, qua nhiều công đoạn, đòi hỏi ngƣời có kinh nghiệm làm việc với các sản phẩm Oracle: Oracle Database, SOA Trình thiết kế BPEL Eclipse + plugin do Apache phát triển. Dễ sử dụng, tuy nhiên một số thao tác không rõ ràng (ví dụ Assign)
Phát triển dựa trên Eclipse, có các mô đun riêng để hỗ trợ tạo ứng dụng dịch vụ Web. Dễ sử dụng Cung cấp công cụ Jdeveloper. Rất dễ sử dụng
Khởi động Thời gian khởi động nhanh do chỉ nạp duy nhất 1 gói ODẸwar. ~11s
Thời gian khởi động lâu hơn ODE mặc dù cùng sử dụng trên nền Tomcat, do phải nạp rất nhiều các thƣ viện khi khởi động. ~ 111s
Thời gian khởi động rất lâụ Cần khởi động Database, Web Server và SOA server. Time ~8.30 phút Giao diện quản trị
Giao diện quản trị đơn giản nhƣng ít thông tin giám sát. Không hỗ trợ kiểm thử các ứng dụng trên giao diện quản trị.
Giao diện quản trị đầy đủ thông tin. Không hỗ trợ kiểm thử các ứng dụng trên giao diện quản trị.
Giao diện thông tin đầy đủ. Hỗ trợ kiểm thử các ứng dụng ngay trên giao diện Web..
Tài nguyên sử dụng Sử dụng tài nguyên nhỏ. CPU ~ 10%, Bộ nhớ ~150MB Sử dụng tài nguyên nhỏ. CPU ~ 10%, Bộ nhớ ~ 450 MB Dùng tài nguyên khá lớn, bao gồm cả CSDL và Web Server Thông báo lỗi Các lỗi phát sinh ra nhiều và khó kiểm soát, không có các thông báo lỗi cụ thể.
Lỗi thông báo ngắn gọn và đầy đủ.
Lỗi thông báo ngắn gọn và đầy đủ.
Khả năng kiểm soát lỗi
Khi bị lỗi, trình xử lý bị treo và không thể tiếp tục thực hiện yêu cầụ Chỉ khi hủy hết các yêu cầu (trong CSDL), trình xử lý mới hoạt động bình thƣờng.
Khi bị quá tải không gây ra hiện tƣợng treọ Khi dừng yêu cầu, hệ thống hoạt động bình thƣờng và có thể phục vụ các yêu cầu khác. Hệ thống chạy ổn định Tổng kết chương
Trong chƣơng này, chúng ta đã sử dụng công cụ mô phỏng ngƣời dùng gửi yêu cầu đến các dịch vụ Web chạy trên các trình xử lý BPEL và đo thời gian phản hồị Kết quả đo phản ánh chính xác năng lực thực thi của từng trình xử lý trên các tác vụ của ngôn ngữ BPEL (If-else, While, Flow, Sequence, Invoke). Những đánh giá, so sánh rút ra từ kết quả đo trên từng tác vụ cụ thể có thể đƣợc áp dụng để dự đoán thời gian phản hồi của các dịch vụ Web phức hợp (gồm nhiều tác vụ) chạy trên các trình xử lý.
KẾT LUẬN
Nhƣ chúng ta đã thấy, công nghệ dịch vụ Web là chìa khóa của giải pháp SOA, đem đến khả năng tích hợp dễ dàng và linh hoạt từ các hệ thống ứng dụng có sẵn đến các hệ thống mớị Việc nghiên cứu, đo đạc hiệu năng các trình xử lý BPEL là một nhiệm vụ quan trọng để giúp ngƣời dùng có những đánh giá và lựa chọn trình xử lý phù hợp. Sau một thời gian tìm tòi, nghiên cứu, luận văn đã thu đƣợc một số kết quả quan trọng. Về lý thuyết, luận văn đã nêu ra tổng quan của kiến trúc hƣớng dịch vụ, trong đó đi sâu vào công nghệ dịch vụ Web dùng để hiện thực hóa kiến trúc này cho phép kết hợp (orchestration) các dịch vụ đơn lẻ và các hệ thống ứng dụng thành một quy trình nghiệp vụ đầy đủ. Luận văn cũng đã mô tả tổng quan về các tác vụ của ngôn ngữ thực thi tiến trình nghiệp vụ WS-BPEL 2.0 qua đó thấy đƣợc tầm quan trọng và ảnh hƣởng của chúng đối với quy trình nghiệp vụ mà nó mô tả.
Luận văn đã tìm hiểu kiến trúc chung của BPEL và đi sâu vào tìm hiểu kiến trúc của từng trình xử lý BPEL cụ thể Apache ODE, ActiveVOS, Oracle BPEL Process Manager. Việc tìm hiểu những kiến trúc này giúp ngƣời đọc có thể hiểu rõ hơn về các thành phần cũng nhƣ mô hình hoạt động của các tiến trình BPEL.
Trong phần thực nghiệm, luận văn đã triển khai việc đo hiệu năng trên các trình xử lý. Các ứng dụng dịch vụ Web đƣợc tạo ra cho từng tác vụ, sau đó đƣợc triển khai trên từng trình xử lý đƣợc cài đặt theo cấu hình mặc định. Quá trình đo đạc đƣợc thực hiện hàng trăm lần với hàng chục nghìn mẫu dữ liệu đảm bảo tính chính xác, khách quan và độ tin cậy của dữ liệu đọ Việc phân tích, đánh giá dữ liệu đo đem lại những kết quả quan trọng nhƣ: khi so sánh hiệu năng giữa các trình xử lý, Apache ODE có hiệu năng thấp nhất và phục vụ đƣợc ít ngƣời dùng nhất (tối đa 25 ngƣời dùng), ActiveVOS có hiệu năng trung bình (tối đa 500 ngƣời dùng), còn Oracle BPEL Process Manager có hiệu năng tốt và ổn định nhất cho dù số lƣợng ngƣời dùng có vƣợt quá 500. Quá trình thực nghiệm cũng đƣa ra những kinh nghiệm khi tạo ra tiến trình BPEL nhƣ dùng tác vụ Flow nhanh hơn so với FlowDep để tận dụng khả năng thực hiện song song của trình xử lý. Luận văn cũng đƣa cho ngƣời dùng những khuyến cáo cần thiết về những yếu tố kỹ thuật khác khi lựa chọn một trình xử lý BPEL cho bài toán của mình.
Trong thời gian ngắn thực hiện, mặc dù đã cố gắng nghiên cứu và tìm hiểu, tuy nhiên luận văn vẫn còn nhiều thiếu sót. Để đạt đƣợc kết quả đo rộng rãi và chính xác hơn, trong thời gian tới, tác giả luận văn sẽ tiếp tục thực hiệnbài toán đo đạc trên các nền tảng khác nhƣ:
Hệ điều hành khác: Linux, Unix (hiện tại mới chỉ thử nghiệm trên Window 7)
Máy chủ ứng dụng và CSDL khác: Apache Tomcat, WebLogic, CSDL Oracle, Derbỵ Cài đặt các trình xử lý trên cùng máy chủ ứng dụng và cơ sở dữ liệụ