Problemy z połączeniem MongoDB na platformie Azure

Kilka tysięcy żądań na minutę to duży obciążenia, a jedynym sposobem, aby zrobić to dobrze, jest kontrolowanie i ograniczanie maksymalnej liczby wątków, które mogą być uruchomione w dowolnym momencie.

Ponieważ nie ma zbyt wielu informacji o tym, jak to zaimplementowałeś. Omówię kilka możliwych okoliczności.

Czas na eksperymenty...

Stałe:

• Elementy do przetworzenia:
  • 50 na sekundę lub innymi słowy...
  • 3000 na minutę i jeszcze jeden sposób, by na to spojrzeć...
  • 180 000 na godzinę

Zmienne:

• Szybkości przesyłania danych:

  • Ilość danych, które możesz przesłać na sekundę, będzie odgrywać rolę bez względu na to, co robimy, a to będzie się różnić w ciągu dnia w zależności od pory dnia.

    Jedyne, co możemy zrobić, to wysłać więcej żądań z różnych procesorów, aby rozłożyć ciężar ruchu, który wysyłamy z powrotem.

• Moc przetwarzania:

  • Zakładam, że masz to w WebJobs w przeciwieństwie do tego, że jest to zakodowane w witrynie MVC. Jest wysoce nieefektywny i nie nadaje się do celu, który próbujesz osiągnąć. Używając WebJob możemy kolejkować elementy pracy do przetworzenia przez inne WebJobs . Kolejka chodzi o Kolejka Azure Pamięć .

Problemy:

• Próbujemy wykonać 50 transakcji na sekundę, więc każda transakcja powinna zostać wykonana w czasie poniżej 1 sekundy, jeśli korzystaliśmy z 50 wątków. Nasz 45-sekundowy czas na przerwę w tym momencie nie ma sensu.
• Oczekujemy, że 50 wątków będzie działać jednocześnie, a wszystkie zostaną ukończone w mniej niż sekundę, co sekundę, na jednym procesorze. (Przesadzam w tym miejscu, tylko po to, żeby coś powiedzieć... ale wyobraź sobie, że co sekundę pobierasz 50 plików tekstowych. Przetwarzam je, a następnie próbuję wysłać z powrotem do współpracownika w nadziei, że będą nawet gotowi do złap to)
• Musimy mieć logikę ponawiania próby, jeśli po 3 próbach element nie zostanie przetworzony, należy go umieścić z powrotem w kolejce. Idealnie byłoby dać serwerowi więcej czasu na odpowiedź niż tylko jedna sekunda na każdą awarię, powiedzmy, że daliśmy mu 2 sekundy przerwy na pierwszą awarię, potem 4 sekundy, potem 10, to znacznie zwiększy szanse na to, że będziemy się utrzymywać / pobieranie potrzebnych nam danych.
• Zakładamy zakładanie że nasz MongoDb może obsłużyć taką liczbę żądań na sekundę. Jeśli jeszcze tego nie zrobiłeś, zacznij szukać sposobów na skalowanie tego problemu, problem nie polega na tym, że jest to MongoDb, warstwa danych mogła być czymkolwiek, ale na tym, że wysyłamy taką liczbę żądań z jedno źródło, które będzie najbardziej prawdopodobną przyczyną twoich problemów.

Rozwiązanie:

1. Skonfiguruj WebJob i nazwij go EnqueueJob . To WebJob będzie miał tylko jeden cel, kolejkowanie elementów pracy do przetworzenia w Queue Storage .
2. Utwórz Queue Storage Container o nazwie WorkItemQueue , ta kolejka będzie działać jako wyzwalacz do następnego kroku i rozpocznie nasze operacje skalowania.
3. Utwórz kolejne WebJobs o nazwie DequeueJob . To WebJob będzie miał również jeden jedyny cel, aby usunąć z kolejki elementy pracy z WorkItemQueue i wyślij żądania do Twojego magazynu danych.
4. Skonfiguruj DequeueJob rozkręcić się po umieszczeniu elementu w WorkItemQueue , uruchom 5 oddzielnych wątków w każdym i gdy kolejka nie jest pusta, usuń elementy robocze dla każdego wątku i spróbuj wykonać usunięte zadanie.
   1. Spróbuj 1, jeśli się nie powiedzie, poczekaj i spróbuj ponownie.
   2. Spróbuj 2, jeśli się nie powiedzie, poczekaj i spróbuj ponownie.
   3. Próba 3, jeśli się nie powiedzie, umieść element z powrotem w kolejce do WorkItemQueue
5. Skonfiguruj swoją witrynę tak, aby automatycznie skalowała się do x liczby procesorów (zwróć uwagę, że Twoja witryna i zadania internetowe korzystają z tych samych zasobów)

Oto krótki 10-minutowy film który zawiera przegląd, jak wykorzystać miejsca do przechowywania kolejek i zadania sieciowe.

Edytuj:

Innym powodem, dla którego możesz otrzymywać te błędy, mogą być również dwa inne czynniki, ponownie spowodowane tym, że znajduje się w aplikacji MVC...

Jeśli kompilujesz aplikację za pomocą DEBUG zastosowano atrybut, ale naciskam RELEASE zamiast tego możesz napotkać problemy z powodu ustawień w pliku web.config , bez DEBUG atrybut, aplikacja internetowa ASP.NET uruchomi żądanie przez maksymalnie 90 sekund, jeśli żądanie potrwa dłużej, usunie żądanie.

Aby zwiększyć limit czasu do ponad 90 sekund będziesz musiał zmienić [httpRuntime][3] właściwość w Twoim web.config ...

<!-- Increase timeout to five minutes -->
<httpRuntime executionTimeout="300" />

Inną rzeczą, o której musisz pamiętać, są ustawienia limitu czasu żądania przeglądarki> aplikacji internetowej, powiedziałbym, że jeśli nalegasz na utrzymywanie kodu w MVC, zamiast wyodrębniania go i umieszczania w WebJob może użyć następującego kodu, aby uruchomić żądanie do Twojej aplikacji internetowej i przesunąć limit czasu żądania.

string html = string.Empty;
string uri = "http://google.com";
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
request.Timeout = TimeSpan.FromMinutes(5);

using (HttpWebResponse response = (HttpWebResonse)request.GetResponse())
using (Stream stream = response.GetResponseStream())
using (StreamReader reader = new StreamReader(stream))
{
    html = reader.ReadToEnd();
}