Hiệu suất cao Tin nhắn JMS

Question

Tôi đọc các trang trình bày từ UberConf năm nay và một trong các diễn giả đang đưa ra lý lẽ rằng Spring JMS thêm chi phí hiệu năng vào hệ thống hàng đợi tin nhắn của bạn, tuy nhiên tôi không thấy bất kỳ bằng chứng nào để hỗ trợ . Người nói cũng làm cho trường hợp điểm-điểm-điểm nhanh hơn phương pháp "xuất bản-đăng ký" truyền thống bởi vì mỗi tin nhắn chỉ được gửi một lần thay vì được phát tới mọi người tiêu dùng.

Tôi tự hỏi nếu bất kỳ gurus tin nhắn Java kinh nghiệm có thể kiểm tra trọng lượng ở đây và làm rõ một vài vấn đề chuyên môn:

• Có thực sự là một hiệu suất trên không phát sinh do sử dụng Spring JMS thay vì chỉ JMS tinh khiết? Nếu vậy, nó được giới thiệu như thế nào và ở đâu? Có cách nào xung quanh nó không?
• Bằng chứng thực tế nào để hỗ trợ P2P nhanh hơn mô hình pub-sub, và nếu có, có trường hợp nào bạn muốn pub-sub qua P2P (tức là tại sao lại chậm hơn?!?)?

Answer 1

1) Chính, chi phí của Spring JMS là sử dụng JmsTemplate để gửi tin nhắn không có cơ chế lưu vào bộ nhớ đệm bên dưới.Về cơ bản, JmsTemplate sẽ làm như sau cho mỗi tin nhắn bạn gửi:

• Tạo kết nối
• Tạo phiên
• Tạo Nhà sản xuất
• Create Message
• Gửi tin nhắn
• Đóng phiên
• Đóng kết nối

này có thể được so sánh với tay mã được viết nơi bạn sử dụng lại điều:

• Tạo kết nối
• Tạo phiên
• Tạo Nhà sản xuất
• Create Message
• Gửi tin nhắn
• Create Message
• Gửi tin nhắn
• Create Message
• Gửi tin nhắn
• Đóng phiên
• Đóng kết nối

Từ việc tạo ra các kết nối, các phiên và nhà sản xuất cần giao tiếp giữa khách hàng và nhà cung cấp JMS và, tất nhiên, phân bổ nguồn lực, nó sẽ tạo ra chi phí khá lớn cho rất nhiều tin nhắn nhỏ.

Bạn có thể dễ dàng tìm hiểu điều này bằng cách lưu vào bộ nhớ cache tài nguyên JMS. Ví dụ, sử dụng mùa xuân CachingConnectionFactory hoặc ActiveMQs PooledConnectionFactory (nếu bạn đang sử dụng ActiveMQ, bạn đã gắn thẻ câu hỏi này).

Nếu bạn đang chạy bên trong một thùng chứa JavaEE đầy đủ, việc gộp/lưu bộ nhớ đệm thường được xây dựng và ngầm định khi bạn truy xuất nhà máy kết nối JNDI của mình.

Khi cập nhật, sử dụng thùng chứa thông báo mặc định vào mùa xuân, có một lớp mỏng vào mùa xuân có thể tăng thêm chi phí, nhưng các khía cạnh chính là bạn có thể tinh chỉnh hiệu suất về mặt đồng thời v.v. This article giải thích rất rõ.

2)

PubSub là mẫu sử dụng, nơi nhà xuất bản không cần biết người đăng ký nào tồn tại. Bạn không thể đơn giản mô phỏng điều đó với p2p. Và, nếu không có bất kỳ bằng chứng nào, tôi sẽ cho rằng nếu bạn muốn gửi một thông điệp giống hệt nhau từ một ứng dụng đến mười ứng dụng khác, thiết lập pub-sub sẽ nhanh hơn gửi tin nhắn mười lần p2p.

Mặt khác, nếu bạn chỉ có một nhà sản xuất và một người tiêu dùng, hãy chọn mẫu P2P có hàng đợi thay vì vì nó dễ quản lý hơn ở một số khía cạnh. P2P (hàng đợi) cho phép cân bằng tải, mà pub/sub không (dễ dàng).

ActiveMQ cũng có phiên bản hybride, VirtualDestinations - chủ yếu là các chủ đề có cân bằng tải.

Việc triển khai thực tế khác nhau bởi các nhà cung cấp khác nhau, nhưng chủ đề và hàng đợi không khác biệt về cơ bản và nên hoạt động với hiệu suất tương tự. Thay vào đó, những gì bạn nên kiểm tra là:

• Tính bền vững? (= chậm hơn)
• Bộ chọn thư? (= chậm hơn)
• Đồng thời?
• Người đăng ký bền? (= Chậm hơn)
• Yêu cầu/trả lời, "đồng bộ" với hàng đợi tạm thời (= overhead = chậm hơn)
• Queue tìm nạp trước (= tác động hiệu quả trong một số khía cạnh)
• Caching

Answer 2

Tôi không gửi tin nhắn guru, tôi muốn bạn không cho tôi chia sẻ suy nghĩ của tôi đây;)

1. Sẽ luôn có overhead, bởi vì bạn có thêm gián tiếp. Thậm chí nó chỉ đơn giản là một cấp độ bổ sung trong ngăn xếp cuộc gọi, nó vẫn còn trên cao. Tuy nhiên, tôi tin rằng chi phí như vậy là tối thiểu. Bạn có thể xem mã nguồn của JmsTemplate. Không có nhiều điều bổ sung do Spring gửi trong khi gửi. JmsTemplate đang làm hầu hết những gì bạn cần làm nếu bạn đang sử dụng JMS. Bạn luôn có thể tranh luận rằng việc kiểm tra thêm và gọi phương thức sâu hơn luôn luôn có nhiều chu kỳ CPU và bộ nhớ hơn. Đúng vậy, nhưng tôi tự hỏi nó có ý nghĩa như thế nào.

2. PubSub và P2P (Chủ đề và hàng đợi trong thuật ngữ JMS) chỉ là hai mô hình khác nhau. Tôi tin rằng họ không thể thay thế lẫn nhau. Bạn không thể có hành vi "gửi một lần và phát sóng tới nhiều người nhận" bằng cách sử dụng Hàng đợi và đồng thời bạn không thể có hành vi được bảo đảm khi sử dụng Chủ đề (trừ khi sử dụng Người đăng ký bền, nhưng đó là một chủ đề khác). Vì vậy, chọn loại phù hợp phụ thuộc vào những gì bạn đang làm, thay vì nói một cách mù quáng rằng P2P vượt trội hơn PubSub (mà tôi tin là không có ý nghĩa)

Answer 3

1) mùa xuân mẫu mở/đóng các kết nối/phiên cho mỗi tin nhắn được gửi/nhận. Đó là lý do tại sao nó chậm hơn. Hầu hết các triển khai JMS hoạt động tốt hơn khi các kết nối/phiên vẫn mở để chúng có thể sử dụng các tối ưu hóa như tìm nạp trước thông báo chưa kể đến việc tránh phải thực hiện tất cả các bit thiết lập/ngắt kết nối.

2) Chủ đề thường chậm hơn nếu chúng đang sao chép/sao chép dữ liệu đến nhiều người tiêu dùng. Đây chỉ là vấn đề vật lý. Nếu 10 megs tin nhắn là hàng đợi được gửi đến hàng đợi, thì chỉ cần 10 megs dữ liệu được truyền đến người tiêu dùng. Trong khi về chủ đề, nếu bạn có 10 người tiêu dùng và bạn gửi 10 megs dữ liệu cho nó, thì 100 megs dữ liệu phải truyền tới người tiêu dùng. Vì vậy, đối với hầu hết các triển khai JMS:

• thêm người tiêu dùng vào một chủ đề chỉ có thể làm chậm tốc độ tiêu thụ của bạn.
• thêm người tiêu dùng vào hàng đợi thường giúp tăng tỷ lệ dequeue.

Answer 4

Bạn đang nói về trang trình bày của Mark Richards? Ông đã đăng mã nguồn cho các tiêu chuẩn của mình, vì vậy bạn thực sự có thể kiểm tra xác nhận của mình về hiệu suất JmsTemplate. Mã điểm chuẩn của anh ta sử dụng CachingConnectionFactory của Spring, và mặc dù bộ nhớ đệm nó vẫn thể hiện một hiệu suất đáng kể với JmsTemplate. Tôi đã thi hành, phân tích và phân tích mã của anh ấy. Câu trả lời ngắn gọn là chi phí từ JmsTemplate là không đáng kể và chênh lệch hiệu suất có thể đo lường trong mã của anh ta phải làm với chế độ gửi đồng bộ hóa async và ActiveMQ của ActiveMQ. Tôi gửi phân tích của tôi ở đây:

JmsTemplate is not evil