Potrzebuję nawiązać dwukierunkową komunikację między wydawcą a subskrybentem. Ma to ułatwić frontendową aplikację MVC3 definiującą subskrypcję z filtrem korelacji, a następnie umieszczając wiadomość w temacie. Wreszcie kontroler MVC3 wywołuje BeginReceive() na SubscriptionClient i czeka na odpowiedź.Magistrala usług Azure - dwukierunkowe wyzwanie dotyczące wydajności komunikacji
Wydaje się, że problem polega na utworzeniu i usunięciu tych obiektów subskrypcji. Narzut jest ogromny i spowalnia działanie aplikacji. Nie wspominając o różnych ograniczeniach do obejścia, takich jak nie więcej niż 2000 subskrypcji w temacie.
Jaka jest najlepsza praktyka dla ustanowienia tego rodzaju dwukierunkowej komunikacji między Wydawcą a subskrybentem? Chcemy, aby aplikacja MVC3 opublikowała komunikat, a następnie czekała na odpowiedź na ten dokładny komunikat (za pośrednictwem właściwości CorrelationId i CorrelationFilter). Pamięć podręczna NamespaceManager i MessagingFactory jest już buforowana, ponieważ są one również zbyt drogie, pod względem zasobów, a także dlatego, że zostaliśmy poinformowani, że usługa Service Bus używa jawnego modelu udostępniania, w którym oczekuje się, że przed rozpoczęciem tworzenia większości tych rzeczy będzie uruchamiany podczas uruchamiania roli.
To stawia nas przed wyzwaniem polegającym na korelacji żądania i odpowiedzi, a także na olbrzymim obciążeniu związanym z tworzeniem i usuwaniem subskrypcji. Czy istnieje lepsza praktyka? Czy powinniśmy przechowywać pamięć podręczną subskrybentów SubscriptionClients i zamieniać filtr za każdym razem? Co robią inni? Potrzebuję przepustowości żądań od 5 do 10 tysięcy żądań MVC3 na sekundę w klastrze ról internetowych. Już używamy AsyncController i stosujemy asynchroniczny BeginReceive() na SubscriptionClient. Wydaje się, że jest to tworzenie i usuwanie Subskrypcji przez tysiące osób, które dławią system w tym momencie.
UPDATE1: oparciu o wielkiej zaleceń podanych tutaj, zaktualizowaliśmy to rozwiązanie, aby utrzymać pamięci podręcznej obiektów SubscriptionClient na każdej instancji roli internetowej. Ponadto przeszliśmy na podejście zorientowane na sesję MessageSession.
Jednak nadal nie jest to skalowanie. Wydaje się, że AcceptMessageSession() jest bardzo kosztowną operacją. Czy obiekty MessageSession powinny być również buforowane i ponownie używane? Czy każdy otwarty obiekt MessageSession zużywa połączenie z magistralą usług? Jeśli tak, czy jest to wliczane do kwoty równoczesnego połączenia subskrypcji?
Wielkie dzięki. Myślę, że się tam dostaliśmy. Większość przykładowego kodu w sieci pokazuje: Utwórz temat(), następnie CreateSubscription(), następnie CreateSubscriptionClient(), następnie BeginReceive() na kliencie, a następnie odrzuć wszystkie obiekty. Mogę tylko powiedzieć, że gdybyś zrobił to w prawdziwym życiu, twój serwer zostałby zmiażdżony, a ty miałbyś max na połączenia w krótkim czasie.
Musimy przez to przesłać tysiące żądań na sekundę i jest oczywiste, że obiekty te muszą być buforowane i ponownie wykorzystywane w dużym stopniu. Czy MessageSession jest kolejnym elementem do buforowania? Będzie miło się z tym bawić, ponieważ będziemy musieli wdrożyć mechanizm liczenia odwołań, w którym można podać tylko jedno odwołanie do MessageSession na raz, ponieważ dotyczy to żądania/odpowiedzi specyficznej dla żądania HTTP, a my nie możemy mieć innego subskrybenci korzystający jednocześnie z obiektów MessageSession.
Update2: OK, to nie jest możliwe, aby cache MessageSession do ponownego użycia, gdyż tylko żyć tak długo, jak LockDuration od abonamentu. To jest bummer, ponieważ maksymalna LockDuration to 5 minut. Wygląda na to, że mają krótki czas publikacji pub/sub, a nie długotrwałe procesy rozproszone. Wygląda na to, że musimy powrócić do odpytywania tabel Azure.
STRESZCZENIE/KOMENTARZ Staraliśmy się budować na magistrali usług ze względu na skalę potencjalnych i jego trwałość i dostawczych semantyki. Wydaje się jednak, że są wśród nich sytuacje, które nie są do nich dostosowane. Część wydawnicza działa świetnie, a rywalizacja z klientami na zapleczu jest świetna, ale posiadanie frontowego żądania czeka na określoną, pojedynczą odpowiedź konsumenta, w ogóle nie skaluje się, ponieważ MessageSessions trwa zbyt długo, aby Utwórz za pomocą AcceptMessageSession() lub BeginAcceptMessageSession() i ponieważ nie są one odpowiednie do buforowania.
Jeśli ktoś ma alternatywny widok, bardzo chciałbym go usłyszeć.
Brzmi jak coś, z czym ZeroMQ jest dobre. http://www.zeromq.org/ –
Dzięki za link. To wygląda bardzo interesująco. –
OK, to bardzo stare pytanie, ale widzę, że obecnie istnieje metoda 'RenewLock' na sesjach, więc może teraz są one buforowalne. –