Thay đổi tỷ lệ là một trong những nhân tố quan trọng nhất của một hệ thống khi số lượng người sử dụng và mật độ sử dụng không thể được xác định và ấn định từ trước. Việc tiếp cận đánh giá thay đổi tỷ lệ trong thực thi hệ thống được tiến hành để đánh giá hai nhân tố:
1. Hoạt động của thời gian phản hồi trung bình của hệ thống với tư cách là
một hàm của số lượng khách hàng đồng thời.
2. Hoạt động của thông lượng hệ thống với tư cách là một hàm của số lượng
khách hàng đồng thời.
Môi trường mạng
The Oracle 8i Server Nhập kiểm tra phát sinh từ
khách hàng
Vì mục đích của các phép thử là thiết lập sự am hiểu về hoạt động của hệ thống và giúp xác định tỷ lệ, số lượng người sử dụng đồng thời hoặc số lượng giao dịch được đặt làm phương sai. Tương đương như vậy, số lượng lần thử nghiệm được điều chỉnh theo mỗi tình huống thử nghiệm để thu được lỗi tương ứng chấp nhận được.
Các phép thử nghiệm được tiến hành với 1, 2, 5, 10, 20, 30, 40 và 50 khách hàng liên tiếp phát sinh yêu cầu đối với hệ thống. Số lượng tối đa 50 khách hàng đồng thời sử dụng hệ thống được chọn là trường hợp xấu nhất, với 100 000 người sử dụng hằng ngày và giả rằng việc phân bổ sử dụng trong ngày là không đồng đều. Mỗi một khách hàng thử nghiệm được đưa vào vòng quan sát số lượng lần yêu cầu hệ thống mỗi lượt. Yêu cầu đầu tiên là lấy ra hợp đồng thanh toán để ký kết và yêu cầu thứ hai là để xuất trình xác nhận chữ ký. Thời gian phản hồi của hệ thống được đo đạc và báo cáo riêng biệt đối với mỗi yêu cầu.
Phân tích thống kê được tiến hành trên kết quả thử nghiệm để xác định ưu điểm của hệ thống. Nếu không thể đạt được khoảng tin cậy 95% đối với mẫu chọn đầu tiên thì tập hợp mẫu sẽ được tăng lên. Phân phối Student T [15] được lựa chọn để đánh giá việc thực hiện khoảng tin cậy, bởi phương sai và phân phối của tập hợp là ẩn số. Kết quả ban đầu cho thấy phân phối không lệch. Dựa trên định lý giới hạn trung tâm, với một số lượng mẫu lớn thì trung bình của phân phối mẫu là phân phối chuẩn với trung bình bằng trung bình của tập hợp và độ lệch chuẩn bằng với độ lệch chuẩn của tập hợp chia cho căn bậc hai của số lượng mẫu [15]. Định lý giới hạn trung tâm cho phép can thiệp vào trung bình của bất kỳ phân phối nào khi kích thước mẫu đủ lớn. Bảng 9 minh hoạ quá trình lựa chọn phương sai và kích thước mẫu cuối cùng cho việc thử nghiệm.
Phép thử nghiệm Số lượng khách hàng liên tiếp Số lượng lần/khách hàng Kết quả mẫu tập hợp 1. 1 1000 1000 2. 2 1000 2000 3. 5 1000 5000 4. 10 1000 10000 5. 20 100 2000 6. 30 100 3000 7. 40 100 4000 8. 50 100 5000
Bảng 9- Việc lựa chọn phương sai cho thử nghiệm
Tóm tắt kết quả thử nghiệm được trình bày tại Bảng 10 Phép thử nghiệm Thời gian phản hồi trung bình (Mili giây?) Độ lệch chuẩn (Mili giây) Lỗi tương đương Yêu cầu thông lượng/giây 1 276 54 1.2% 3.6 2 297 60 0.9% 6.7 3 404 91 0.6% 12.4 4 564 144 0.5% 17.7 5 1077 262 1.1% 18.6
7 1988 362 0.6% 20.1
8 2613 616 0.7% 19.1
Bảng 10- Tóm tắt kết quả thử nghiệm
Dựa trên kết quả thử nghiệm được minh họa tại Bảng 10, ta có thể vẽ ra biểu đồ trong Hình 15 và Hình 16
Mối tƣơng quan giữa thời gian phản hồi và tải trọng
Trục hoành: Số lượng khách hàng đồng thời Trục tung: Thời gian phản hồi trung bình (Mili giây)
Hình 15 – Kết quả thử nghiệm – thời gian phản hồi
Trên dải số lượng khách hàng đồng thời từ 1 đến 50, hệ thống dường như biểu hiện một thời gian phản hồi trung bình có tính chất tuyến tính tăng dần. Độ dốc của đường cong trở nên dốc hơn trong khoảng 40 và 50 khách hàng đồng thời. Tuy nhiên, điều này là hoàn toàn tự nhiên – mọi hệ thống đều đạt được mức tải
trọng khi mà hoạt động được quan sát bởi một người sử dụng duy nhất bắt đầu giảm đột ngột. Trong hệ thống này, đặc điểm này dường như tồn tại ở đâu đó phía trên nhưng gần với mức 50 người sử dụng đồng thời.
Thông lƣợng của Hệ thống thanh toán di động
Trục hoành: Số lượng khách hàng đồng thời Trục tung: Số lượng yêu cầu/Giây
Hình 16 – Kết quả thử nghiệm – Thông lượng
Thông lượng của hệ thống cho thấy hoạt động có tính thay đổi tỷ lệ rất rõ rệt – thông lượng tăng nhanh cho tới mức 10 người sử dụng đồng thời và tiếp tục tăng cho tới mức 40 người. Ở mức 50 người sử dụng đồng thời, hệ thống đã đạt tới trạng thái bão hòa và thông lượng bắt đầu giảm dần. Rõ ràng là quan sát này phù hợp với quan sát được thực hiện trước đó – hệ thống bắt đầu tắc nghẽn tại đâu đó
lớn hơn mức 50 người sử dụng đồng thời một chút. Trước khoảng đó, sự gia tăng thời gian phản hồi cảm nhận bởi một người sử dụng duy nhất là hợp lý và tuyến tính với tư cách là một hàm tải trọng.
Cùng với việc tiến hành thử nghiệm hoạt động thực tế, một số thử nghiệm khác cũng được thực hiện để tạo lập một ý tưởng về cấu hình hợp lý cho hệ thống và các vướng mắc có thể gặp phải khi hoạt động. Tuy nhiên, các thử nghiệm này không được nghiên cứu kỹ lưỡng theo phương pháp thống kê như mô tả trên đây nên chúng chỉ có tính chất tham khảo. Dưới đây là một số nhận xét và các quan sát ghi nhận được.
Nhận xét về các thử nghiệm hoạt động của hệ thống
Trong quá trình thử nghiệm, việc giám sát hoạt động vận hành hệ thống được quan sát. Quan sát chung cho thấy, với một số lượng nhỏ khách hàng sử dụng đồng thời thì tải trọng đối với hệ thống CPU máy chủ là thấp. Với một khách hàng đồng thời tải trọng giữ ổn định ở mức 15%, với 5 khách hàng đồng thời, tải trọng tăng lên khoảng 65% và với 10 hoặc hơn khách hàng đồng thời thì tải trọng liên tục ở mức vượt quá 95%.
Thử nghiệm tại các kết nối cơ sở dữ liệu chung với các kích thước khác nhau cũng được tiến hành. Với 50 khách hàng đồng thời, khi kích thước liên kết cơ sở dữ liệu chung không bị khống chế, kết quả cho thấy rất rõ ràng rằng hệ thống chỉ có thể sử dụng tối đa 25 kết nối một lúc. Số lượng trung bình các kết nối đồng thời được sử dụng gần tới 10. Mặt khác, kết quả cũng cho thấy khi kích thước của cơ sở dữ liệu chung bị khống chế ở mức 5 liên kết với 10 khách hàng đồng thời thì tải trọng của hệ thống giảm từ (khoảng 90% trong trường hợp không bị khống chế) xuống còn 35%.
Ảnh hƣởng của việc truy cập cơ sở dữ liệu tới tổng thời gian phản hồi
Một giả thuyết cho rằng việc truy cập cơ sở dữ liệu có ảnh hưởng tiềm tàng tới thời gian phản hồi. Với mục đích thử nghiệm, một lớp giao diện cơ sở dữ liệu có chức năng giữ hồ sơ thanh toán trong bộ nhớ được thực hiện. Thử nghiệm với hệ thống được chạy với chỉ một khách hàng đồng thời. Kết quả cho thấy, thời gian phản hồi trung bình là 40Mili giây, là một bước cải tiến đột phá so với thời gian phản hồi 276 Mili giây thu được với việc thực hiện một cơ sở dữ liệu hợp lý. Với việc thực hiện bộ nhớ lưu trú của kho hồ sơ thanh toán, tải trọng CPU đạt mức 100% trong quá trình thử nghiệm. Nói cách khác, phần lớn thời gian để xử lý yêu cầu được sử dụng để đợi phản hồi cơ sở dữ liệu.
KẾT LUẬN
1 Những kết quả đạt đƣợc
Trong phần này, kết quả của luận văn được so sánh với các mục tiêu đề ra tại phần 2.1, Các tiêu chí thiết kế. Những sai lệch có thể có được phân tích và nghiên cứu kỹ lưỡng. Về mặt tổng thể sẽ là phân tích các kết quả và đánh giá hiệu quả công việc.
a) Khảo cứu
Về mặt chức năng
Có thể nói rằng, tất cả các tiêu chí đều được đáp ứng, ngoại trừ tiêu chí liên quan tới giao diện bên ngoài cho việc phát hành hóa đơn và xác minh tín dụng và chữ ký. Giao diện phát hành hóa đơn và xác minh tín dụng tồn tại trong hệ thống, mặc dù chúng được thực hiện để tương tác với bất kỳ hệ thống hiện có nào trong phạm vi của luận văn này. Việc xác minh chữ ký cũng có một số tồn tại – các đặc trưng của chữ ký WIM hiện đều được hỗ trợ hoàn toàn. Các thuật toán dạng đường cong elip không được hỗ trợ, mặc dù trong diễn đàn WAP có quy định rõ ràng rằng chúng là một phần của tiêu chuẩn.
Nhìn chung, các yêu cầu chức năng đều được đáp ứng tốt – không có độ lệch thực tế nào từ các yêu cầu ngoài việc không thực sự hợp lý hoặc thực tế để đạt được hoặc cố gắng đạt được một giải pháp hoàn hảo.
Về mặt kỹ thuật
Các yêu cầu kỹ thuật trong việc thực hiện hệ thống được nêu ra tại phần 2.1.2 cũng được đáp ứng hoàn toàn.
Về tính bảo mật
Các yêu cầu về tính bảo mật được nêu trong phần 2.1.3 được đáp ứng hoàn toàn. Việc xác minh tính đáp ứng hoàn toàn của tất cả các yêu cầu bảo mật là rất khó khăn, không thể thực hiện được. Đáp ứng các tiêu chí được phân tích trong phần này được thực hiện bằng cách thảo luận việc đưa ra các quyết định và các phương pháp giảm nhẹ nguy cơ bảo mật. Phần thảo luận dưới đây trình bày cho từng yêu cầu trong số ba yêu cầu bảo mật then chốt.
1. Yêu cầu ngăn chặn các thực thể không được ủy quyền tiếp cận hệ thống và
dữ liệu của hệ thống được đáp ứng ở hai mức độ - thiết kế kiến trúc và thực hiện.
2. Cơ chế được mô tả trên đây cũng đã đáp ứng phần lớn tiêu chí bảo mật thứ
hai với yêu cầu không cho phép truy cập vào nguồn dữ liệu của hệ thống thông qua các giao diện cụ thể.
Có hai phương pháp liên lạc với Hệ thống thanh toán di động – phương pháp thứ nhất xuất phát từ hệ thống thương mại và phương pháp thứ hai là từ thiết bị WAP.
Bên cạnh các yêu cầu bảo mất được quy định trực tiếp trên đây, tất nhiên còn có những tiêu chí bảo mật ngầm cho các bộ phận chủ chốt chung làm nền tảng cho giải pháp. Trong luận văn này, việc bảo mật được cung cấp bởi MeT dựa trên cơ cấu giao dịch di động được đưa ra như một căn cứ - với giả thiết rằng việc quản lý chính, việc phát hành chứng nhận và quá trình ký kết vốn đã được bảo mật. Đương nhiên, nếu một trong các yếu tố đó bị xâm hại thì nền tảng cho toàn bộ cơ sở bảo mật của hệ thống sẽ bị sụp đổ.
Hệ thống đáp ứng các yêu cầu được đặt ra cho khả năng thay đổi tỷ lệ hợp lý. Trong dải tải trọng thử nghiệm, hệ thống được chia tỷ lệ rất tốt. Hệ thống sẽ hỗ trợ linh hoạt tới mức 864000 giao dịch một ngày trên phần cứng được sử dụng cho việc thử nghiệm. Con số này vượt xa con số 100000 người sử dụng được đề ra trong tiêu chí đánh giá thiết kế.
Hoạt động của hệ thống
Hoạt động của hệ thống được ghi nhận bởi từng cá nhân người sử dụng – nó là một nhân tố quan trọng làm nên tính tiện lợi toàn diện của hệ thống. Dựa trên các kết quả thử nghiệm được sử dụng trong việc xác định tỷ lệ, hoạt động của hệ thống có thể được phân tích và nhìn chung, hoạt động của hệ thống là rất tốt. Hoạt động của hệ thống vẫn tốt một cách đáng ngạc nhiên bất chấp tính phức tạp của từng giao dịch riêng biệt và với thực tế là hệ thống dựa trên môi trường Java thuần túy.
Tính chất mô đun
Với những hiểu biết hiện tại, hệ thống được cơ cấu theo phương pháp mô đun. Tuy nhiên, không thể chứng minh điều này một cách thuyết phục.
Một số bộ phận của hệ thống, giống như những phần khác có liên quan tới xác minh chứng nhận và chữ ký được tách rời khỏi phần còn lại của hệ thống. Chúng được tạo chung và do đó có thể được sử dụng và phát triển độc lập khỏi phần còn lại của hệ thống với điều kiện giao diện vẫn phải được tôn trọng. Phương pháp tiếp cận này mang lại các mảng phần mềm có thể tái sử dụng và có thể được sử dụng trong nhiều dự án khác nhau không kể đến các lĩnh vực ứng dụng đặc biệt.
Bảo trì hệ thống
Bảo trì hệ thống được thực hiện theo hai hướng – một là bảo trì hàng ngày và quản trị hệ thống, và hai là bảo trì chương trình, tức là chương trình được trao đổi, ấn định và cập nhật dễ dàng như thế nào.
2 Các hƣớng phát triển hệ thống
Chúng tôi sẽ tiếp tục phát triển hệ thống quy mô hơn, cụ thể là phát triển theo các hướng sau:
a) Mô hình dữ liệu và nhân tố của hệ thống
Hiện tại hệ thống được xây dựng xoay quanh tư tưởng của một thương nhân, trên thực tế là một sự thâm nhập vào một trong số bảng cơ sở dữ liệu của hệ thống. Những người sử dụng không đăng ký – mô hình PKI, khi việc ủy quyền đăng ký của bên thứ ba tiến hành việc chứng nhận đã được thông qua và theo sát một cách chính xác.
Tuy nhiên, để khiến cho người sử dụng có cảm giác thoải mái và thân thiện hơn, việc có một số thống tin về số lượng người sử dụng sẵn có trên hệ thống là rất có lợi – khái niệm về một người sử dụng đã đăng ký hoặc một giao diện dữ liệu người sử dụng nên được áp dụng. Nếu người sử dụng đăng ký vào hệ thống, khái niệm về tài khoản người sử dụng phải được đề cấp đến. Để giúp cho việc quản lý tài khoản và thực hiện đăng ký được đơn giản và dễ dàng, người chi trả và thương nhân có thể chỉ đóng vai trò thực thể đăng ký trong mô hình dữ liệu mới của hệ thống. Điều này có thể mang lại rất nhiều các chức năng mong muốn mới, chẳng hạn như chức năng thanh toán đồng đẳng.
b) Các công cụ quản trị
Phiên bản hiện tại của hệ thống không bao gồm bất kỳ giao diện quản trị nào cho thương nhân, người chi trả hoặc người điều khiển hệ thống thanh toán. Những chức năng này có thể được thực hiện dễ dàng nhằm mang lại độ minh bạch hơn cho hệ thống và giúp cho việc quản lý và bảo trì hằng ngày trở nên dễ dàng hơn. Một bảng quản trị trên cơ sở web nơi mà có thể xem và soạn thảo thông tin đăng ký và lịch sử giao dịch có thể là phù hợp nhất với mục đích của thương nhân và người chi trả đẵ đăng ký. Bảng quản trị của người điều khiển hệ thống thanh toán có thể dựa trên cơ sở web hoặc dựa trên ứng dụng khách hàng trên cơ sở Java.
c) Kích hoạt thanh toán bằng WAP PUSH
Hệ thống nên được tích hợp đối với WAP Push Proxy Gateway, ví dụ như Nokia Activ Alert. Điều này cho phép gửi đi các tin nhắn Service Indication WAP PUSH tới người chi trả được xác nhận để kích hoạt quy trình thanh toán. Điều này sẽ loại bỏ việc nhập mã tham chiếu thanh toán và do đó khiến cho quy trình thanh toán trở nên nhanh chóng và dễ dàng hơn đáng kể. Việc tích hợp tính năng vào máy chủ thanh toán chắc chắn sẽ có ý nghĩa hơn việc phó thác nó cho thương nhân.
d) Các giao diện
Để việc tích hợp được nhanh chóng và dễ dàng hơn, hệ thống có thể kết hợp