Viết các mã tuyệt vời với các API P8 FileNet của IBM,
Phần 2: Thám thính công việc của chính bạn
Giới thiệu
Nếu bạn đang sử dụng các API của P8, thì nhiều khả năng là bạn tham gia vào việc viết các ứng
dụng mức doanh nghiệp. Nếu bạn tham gia vào việc viết các ứng dụng mức doanh nghiệp, thì
sớm hay muộn, hiệu năng cũng sẽ trở thành mục cao nhất trong danh sách ưu tiên của bạn. Ngay
cả khi hiệu năng đã rất tuyệt trong môi trường phát triển cô lập của bạn, thì đôi khi vẫn rất khó
để dự đoán những gì sẽ xảy ra khi ứng dụng của bạn được triển khai dưới áp lực tải thực tế của
nhiều người sử dụng. Các bài viết tới sẽ bàn về một số kỹ thuật mã hóa cụ thể để có hiệu năng tốt
nhất. Bài viết này đặt nền tảng cho việc đó bằng cách bàn về một số công cụ và kỹ thuật để biết
bạn đang đưa lên mạng những dữ liệu gì. Nó có vẻ như tạm thời chệch hướng khỏi những điều
căn bản thiết thực khi mã hóa, nhưng bạn sẽ có các thông tin có giá trị khi bạn đọc các bài viết
tới của loạt bài viết này và khi bạn phát triển các ứng dụng của riêng mình.
Đối với rất nhiều ứng dụng, có hai nhân tố then chốt điều khiển hiệu năng:
Trước hết, hiệu suất tổng thể thường bị chi phối bởi số lượng các cuộc gọi mạng mà các
ứng dụng khách của bạn gọi vào các máy chủ P8. Tùy thuộc vào bạn hỏi ai, các cuộc gọi
mạng có thể là: cuộc gọi khứ hồi (R/Ts), gọi thủ tục từ xa (RPCs), truy cập máy chủ và
nhiều tên tương tự khác. Tất cả những tên gọi khác nhau ấy đều cùng chỉ một việc: mạng
đường ống dính líu đến việc truyền yêu cầu từ máy khách đến máy chủ và việc máy chủ
tính toán và truyền về đáp ứng. Trong môi trường phát triển, cuộc gọi RPC có thể chỉ cần
vài chục hoặc vài trăm mili giây. Thực vậy, hiếm khi một cuộc gọi RPC của P8 cần đến
một phần đáng kể của một giây trong một môi trường cô lập. Trong môi trường chịu tải
đầy đủ, khoảng thời gian này tăng nhanh vì phải ganh đua với nhau trên mạng, tại máy
chủ và trong một số trường hợp, tại máy khách. Khi mọi thứ bị khuyếch đại, việc loại bỏ
hoặc giảm quá tải đến hết mức có thể là đáng công làm. Đối với hai công việc riêng biệt
cần phải được thực hiện trên máy chủ P8, thì luôn rẻ hơn (ngoại trừ các trường hợp khó
khăn thực sự) nếu bạn có thể thực hiện chúng bằng một RPC duy nhất thay vì hai RPC.
Thứ hai, hiệu năng bị ảnh hưởng bởi số lượng dữ liệu – tức là số lượng byte – thực sự
được truyền đi trên mạng trong một cuộc gọi RPC. Đây không chỉ là vấn đề của bộ định
tuyến mạng có thể xử lý các bit nhanh như thế nào. Các dữ liệu được truyền đi càng
nhiều, thì các API trình khách và các đối tác máy chủ của chúng càng cần phải làm việc
nhiều hơn để lắp ráp và diễn giải các yêu cầu. Trong môi trường P8, hầu như kích thước
của các yêu cầu luôn luôn chỉ là một phần nhỏ của kích thước của các đáp ứng, vì vậy
việc cố gắng để điều chỉnh kích thước các yêu cầu hiếm khi đáng công. Việc điều chỉnh
kích thước của các đáp ứng RPC thường có thể có tác động đáng kể về hiệu năng, và nó
luôn đáng được ít nhất là nghiên cứu.
Bài viết này chỉ bàn về một số điều, chúng sẽ giúp bạn có nhận thức về những gì mà ứng dụng
của bạn đang làm ở cả hai lĩnh vực đó.
Công cụ dò tìm trên mạng giúp bạn tra tìm dữ liệu ở mức thấp đang truyền trên mạng.
Mặc dù nghe có vẻ phức tạp, nhưng các công cụ hiện đại trong lĩnh vực này khá dễ vận
hành, và chúng có thể làm đơn giản việc khoan sâu vào các vùng cụ thể.
Bằng cách ghi nhật ký API Java nội dung của P8, bạn có thể lệnh cho API cho bạn biết
những gì nó đang thực hiện tại các điểm khác nhau. Đây là một kỹ thuật tốt để đánh giá
cả về số lượng và kích thước của các RPC.
Bạn có thể sử dụng cá thể ObjectDumper trong mã phát triển của riêng bạn để chụp
nhanh những gì có ở bên trong một đối tượng API của P8. Đây là việc hữu ích để đánh
giá số lượng dữ liệu mà một đối tượng đang chuyên chở ở sau hậu trường và cũng để thấy
sự khác biệt của các hoạt động khác nhau với dữ liệu đó.
Sử dụng công cụ dò vết trên mạng mạng
Trình thám thính (sniffer) là gì?
Dò vết trên mạng có hàm ý chung là việc bắt giữ các dữ liệu thô truyền trên mạng. Các công cụ
này đôi khi được gọi là bộ phân tích mạng, bộ thám thính mạng (được đặt theo tên của ông
Sniffer - nhà phân tích mạng), hoặc là bộ thám thính gói. Các bộ thám thính ban đầu là các bộ
phận chuyên dùng của thiết bị độc lập có thể được gắn kết vật lý tới một phân đoạn mạng. Các
thiết bị như vậy vẫn còn tồn tại, nhưng hiện nay có các phần mềm tương đương với chúng để sử
dụng hàng ngày. Mặc dù công dụng chính ban đầu của các bộ thám thính là để chẩn đoán các
vấn đề mạng ở mức độ khá thấp, đôi khi chúng cũng có thể được sử dụng rất hiệu quả để có được
bức tranh về truyền thông giữa các thành phần của một ứng dụng phân tán. Dò vết trên mạng
nghe có vẻ là một chủ đề phức tạp và khó nắm bắt cho bất kỳ ai, trừ các chuyên gia, nhưng nó rất
dễ tiếp cận đối với các nhà phát triển trung bình. Các công cụ có sẵn ngày nay thường có giao
diện người dùng tốt và tài liệu hướng dẫn khá dễ hiểu.
Bên cạnh việc bắt và phân tích luồng lưu thông mạng đang hoạt động, các trình thám thính cũng
có thể được sử dụng để ghi lưu các luồng lưu thông thành một tệp tin hoặc để đọc tệp tin các
luồng lưu thông đã được ghi lưu. Tệp tin như vậy thường được gọi là các tệp tin nắm bắt. Có các
định dạng tệp tin bắt luồng lưu thông theo chuẩn thực tế của ngành công nghiệp, do vậy nhiều cơ
hội (nhưng không dám chắc) rằng một tệp tin bắt luồng lưu thông do một ứng dụng thám thính
tạo ra có thể đọc được bằng một trình thám thính khác.
Nếu bạn chưa có công cụ dò vết trên mạng, thì bằng việc tìm kiếm Web theo bất kỳ một thuật
ngữ nào đề cập ở trên sẽ nhận được một số lựa chọn thay thế phổ biến, bao gồm các công cụ mã
nguồn mở hoặc miễn phí. Nhằm mục đích minh họa, bài viết này sử dụng Wireshark, một trình
thám thính mã nguồn mở mạnh mẽ và phổ biến có sẵn tại trang Wireshark.org. Wireshark phiên
bản 1.0.5 được sử dụng cho bài viết này, nhưng nếu bạn sử dụng phiên bản cũ hơn hoặc một
công cụ hoàn toàn khác, thì các khái niệm được thảo luận vẫn có thể áp dụng được và bạn không
gặp rắc rối nào. Mục tiêu của bài viết không phải là giúp bạn trở thành một chuyên gia về bất kỳ
công cụ thám thính cụ thể nào. Thay vào đó, bài viết này cung cấp cho bạn một cái nhìn lướt qua
các khả năng để bạn có thể tự mình tiếp tục khám phá.
Bắt giữ kết quả dò vết trên mạng
Mục đích chính của trình thám thính (sniffer) phần mềm là lắng nghe luồng lưu thông qua chồng
giao thức nối mạng trên một máy tính mà không can thiệp vào luồng lưu thông đó. Điều này
không hoàn toàn giống như lắng nghe chính trên mạng, nhưng cũng gần như thế nếu nói về
những gì bạn sẽ làm. Bởi vì trình thám thính cũng là một chương trình chạy trên máy tính, điều
đầu tiên bạn phải nghĩ đến là bạn sẽ chạy nó trên máy tính nào. Đôi khi điều này bị chi phối về
mặt chức năng bởi những điều bạn đang cố gắng để kiểm tra. Trình thám thính chỉ nhìn thấy
những thứ theo quan điểm của máy tính đang chạy nó, và nó thường không thể nhìn thấy lưu
thông mạng giữa hai hoặc nhiều máy tính khác. Thực vậy, trong nhiều trường hợp phức tạp hơn,
đôi khi cần phải chạy trình thám thính trên nhiều máy tính cùng một lúc để các hoạt động có thể
tương quan với nhau. Tuy nhiên, điều đó không cần thiết cho kịch bản này, bởi vì bạn chỉ phải
theo dõi các cuộc gọi điểm tới điểm. Sự lựa chọn của bạn rút lại chỉ còn là máy tính nơi mà API
máy khách của bạn đang chạy hoặc là máy tính nơi mà máy chủ P8 đang chạy. Giả sử bạn có
quyền truy cập như nhau vào cả hai máy tính, thì việc chạy nó trên máy tính khách của bạn có ý
nghĩa hơn. Điều đó cho phép bạn tránh các hỗn loạn nhỏ của các yêu cầu từ các máy khách khác
nếu máy chủ P8 của bạn được chia sẻ. Nếu máy chủ P8 của bạn không được chia sẻ hoặc có rất ít
hoạt động trên đó, thì sự lựa chọn chỉ là vấn đề sao cho tiện cho bạn mà thôi. Đối với các loại tác
vụ thường nhật trong kịch bản của bài viết này, thì trình thám thính phần mềm nói chung đặt
thêm một tải công việc tối thiểu lên máy chạy nó. Bài viết này giả sử bạn đang chạy trình thám
thính trên máy khách, nhưng nếu không phải như vậy thì cũng khá dễ thấy bạn phải làm khác đi
những gì.
Giả sử bạn có một ứng dụng đang chạy và muốn quan sát và điều chỉnh các nhân tố liên quan
đến hiệu năng được mô tả ở trên. Nếu bạn chưa có ứng dụng của mình và chỉ muốn có một ứng
dụng đơn giản để chạy để xem các kỹ thuật trong bài viết này làm việc như thế nào, thì bạn có
thể tải về ứng dụng mẫu HelloDocument tại bài viết đầu tiên của loạt bài viết này. Có một số lưu
ý mà bạn nên xem xét khi chạy một trình thám thính cùng với ứng dụng của bạn:
Hãy sử dụng truyền tải WSI thay vì truyền tải EJB. Truyền tải WSI sử dụng các XML
được truyền bằng cách sử dụng HTTP. Mặt khác, truyền tải EJB sử dụng các định dạng
và giao thức quyết định bởi máy chủ ứng dụng đang được sử dụng. Nói chung, truyền tải
EJB sử dụng các định dạng nhị phân nén hoặc ngắn gọn. Các định dạng này rất tuyệt vời
cho truyền thông khách/chủ, nhưng chúng khó xử lý khi giám sát luồng lưu thông mạng
một cách trực quan.
Đừng sử dụng kiểu bảo vệ TLS/SSL trên các kết nối của bạn. Chính vì mục đích của nó,
bảo vệ TLS/SSL làm cho không thể nhìn vào bên trong luồng lưu thông đón bắt được.
Ngay cả nếu một bên thứ ba nghe toàn bộ cuộc đối thoại thiết lập kết nối TLS/SSL, thì nó
sẽ không thể giải mã được luồng lưu thông được bảo vệ tiếp nối sau. Trình thám thính
không có bất kỳ sức mạnh huyền diệu nào để nhìn xuyên qua tấm màn che TLS/SSL.
Chạy không có bảo vệ TLS/SSL sẽ để lộ luồng lưu thông và các mật khẩu chưa mã hóa
cho những kẻ nghe lén tiềm năng, vì vậy bạn sẽ muốn sử dụng thông tin và các tài khoản
không nhạy cảm trong khi bạn chạy các thử nghiệm về trình thám thính của mình. Bởi vì
nhiều khả năng là bạn làm điều này trong một môi trường phát triển hoặc thử nghiệm,
nên rất dễ dàng để thu xếp.
Nếu như còn chưa đủ rõ ràng, những điểm nêu trên kết hợp cùng nhau có nghĩa là URI kết nối
của Máy nội dung của bạn phải là một URI HTTP (không phải là HTTPS và không phải là URI
không HTTP).
Cách làm chung là bật trình thám thính lên, chạy ứng dụng, tắt trình thám thính và phân tích
luồng lưu thông mạng. Hình 1 cho thấy bắt đầu phiên đón bắt. Mỗi dòng trong cửa sổ trên cùng
là một gói tin IP đơn lẻ đã đón bắt được. Trong thuật ngữ của trình thám thính, các gói còn được
gọi là khung tin. Chỉ là nói nhẹ đi khi nói rằng đây là một màn hình phức tạp và bận rộn với
người còn bỡ ngỡ. Đâu là dữ liệu đáng chú ý của RPC P8 mà bạn đang tìm? Trên thực tế, chúng
không có trong hình 1. Hình 1 cho thấy chưa đầy một giây đầu tiên của hoạt động mạng, thậm
chí chưa đủ thời gian để đổi sang cửa sổ khác và nhìn thấy ứng dụng của bạn đã bắt đầu.
Hình 1. Thông tin dò vết trên mạng dạng thô, chưa được lọc