Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Nach Azure umziehen - Pro Aufgabe eine neue Worker Roles starten
ravel
myCSharp.de - Member



Dabei seit:
Beiträge: 169

Themenstarter:

Nach Azure umziehen - Pro Aufgabe eine neue Worker Roles starten

beantworten | zitieren | melden

Hi,

ich nutze einen Web Crawler, der momentan auf einem virtuellen Server läuft. Der Web Crawler läuft innerhalb eines Windows-Dienstes, angeschlossen per WCF an eine ASP.NET-Webseite für das Starten und Stoppen der crawl jobs.

Pro crawl job wird momentan ein Backgroundworker innerhalb des Dienstes gestartet, der den crawl job ausführt und die Ergebnisse in eine MongoDB-Datenbank schreibt.

Aus Gründen der Skalierbarkeit, möchte ich gerne nach Azure umziehen.

Ich habe mir gedacht, dass jeder neue crawl job in einer eigenen (WCF-)Worker Role läuft.
Die Worker Role schreibt auch gleich die Ergebnisse des Crawl-Vorgangs in die Datenbank.

Die ASP.NET-Webseite hat einen Dienstverweis auf die WCF-Worker-Role.

Wie starte ich aber für jeden crawl job eine eigene Worker Role?

Vielen Dank
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.927

beantworten | zitieren | melden

Entweder Du machst das als Azure WebJob mit Console Apps oder Du musst eine Queue, zB ServiceBus verwenden, was dann einem Consumer-Producer-Pattern entspricht.

Direkt mehrere Worker Roles würde ich abraten.
Skalieren kannst Du bei einer Queue einfach indem Du einen weiteren Consumer anhängst.
Willst Du wirklich mit dem Overhead leben und für JEDEN Eintrag einzel abarbeiten, dann wäre doch eher Azure Batch was für Dich.
private Nachricht | Beiträge des Benutzers
ravel
myCSharp.de - Member



Dabei seit:
Beiträge: 169

Themenstarter:

beantworten | zitieren | melden

Hi Abt,

vielen Dank für Deine schnelle Antwort.

ich habe mir grade ein einfaches Beispiel zu Azure WebJob mit Console Apps hier http://www.hanselman.com/blog/IntroducingWindowsAzureWebJobs.aspx angesehen. Dort steht "They (WebJobs) are built into Azure Websites and run in the same VM as your Web Sites."

So wie ich das verstehe, habe ich bei Azure wieder eine VM und die Anwedung skaliert auch nur innerhalb dieser VM.
Kann ich irgendwie (automatisch) die Grenzen der VM verlassen und dadurch hoch- und runter-skalieren?

Ich hatte es mir ganz naiv so vorgestellt, dass ich die Jobs einfach an Azure übergebe und dort wird entschieden, wo der Job läuft.

Besten Dank
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.927

beantworten | zitieren | melden

Azure bietet Dir nur Kanäle an, zB Queues aber übernimmt hier nicht die Logik.
Du bist _immer_ an die Grenzen von VMs gebunden.
private Nachricht | Beiträge des Benutzers
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 742

beantworten | zitieren | melden

Ich würde dir auch das Producer-Consumer Pattern empfehlern. Worker Roles sind ja nur virtuelle Machinen mit ein paar Ereichterungen oben drauf, bis diese bereitgestellt sind, geht es gefühlt ewig.

Als Queue kannst du ServiceBus, Queues oder Redis verwenden. Ich empfehle letzteres, weil es am einfachsten zu testen ist. Wenn du Skalieren musst kannst du einfach die Instanzen für deine Worker Role erhöhen. Falls du sehr viele Instanzen brauchst, kannst du auch eine Mini-Instanz für ein paar Euro im Monat verwenden, welche die Queue beobachtet und bei Bedarf Instanzen hoch- oder runterfährt. Allerdings solltest du dich erstmal fragen, ob du skalieren musst. Crawling ist ja in erster Linie IO gebunden, das heißt du musst auf die Ergebnisse der Webrequests warten. Durch den Konsequenten Einsatz von asynchronen Methoden kannst du 1000te von Requests pro Minute durchführen. Ist das Parsing einigermaßen performant, wirst du kaum Skalierungsprobleme haben. Auch MongoDB hat seit Samstag einen asynchronen Treiber, so dass du auch hier keine CPU-Zeit mit Warten verschwenden musst.
private Nachricht | Beiträge des Benutzers