EBC vs. EDA

[Stefc]

Wenn ich EBC mit EDA (Event-Driven-Architecture) vergleiche, wie
stehen die beiden zueinander.
http://de.wikipedia.org/wiki/Ereignisgesteuerte_Architektur

Ist EBC analog zu EDA oder gibt es Unterschiede wenn ja welche?

Der wichtigste Vorteil einer EDA ist das sie anscheinend nicht
blockiert (z.B.Node.JS). Trifft dieses auch für EBC zu?

mfg stefc

[Ralf Westphal]

EDA ist ein Architekturansatz. EBC denkt nicht notwendig so groß. Deshalb ist EBC zunächst auch rein synchron und lokal (keine verteilte Kommunikation).

Der Flussgedanke ist aber beiden gleich.

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[Stefc]

Hi,

das ging schnell ;)

das Node.JS läuft auch nur in einem Thread wenn ich es richtig
verstanden habe und erreicht durch seinen EDA Ansatz das die
Operationen sich nicht blockieren. d.h. aber auch das Node.JS z.B.
nicht von einem Multi-Core System profitiert erst wenn pro Core eine
eigene Node.JS Instanz existiert wird die CPU voll ausgenutzt.
Andere Server Architekturen stürzen sich auf Multithreading (pro
Request ein neuer Thread mit Threadpooling) mit all seinem Problemen
um Leistung zu erbringen und jetzt kommt Node.JS mit einem anderen
Architekturansatz und alle sind begeistert davon ?!

Ralf wie würdest einen Web-Server Anwendung auf der grünen Wiese
designen der z.B. auf dem gerade von HP vorgestellten Konzeptstudie
2800 ARM Server in einem Server Rack gut skaliert?
Wäre das pro Server eine EBC Hauptplatine (synchron) oder
eine Applikation mit bis zu 2800 Threads ?

Ich vermute fast das ein EBC bzw. EDA Ansatz bei solchen zukünftigen
Hardware Platformen von Vorteil gegenüber den jetzt weit verbreiteten
Multithreading Ansatz wo ich beim Design ständig aufpassen muss das
ich mit der Nebenläufigkeit nicht ins Stolpern komme!

On 7 Nov., 19:35, Ralf Westphal <ra...@ralfw.de> wrote:
> EDA ist ein Architekturansatz. EBC denkt nicht notwendig so groß. Deshalb
> ist EBC zunächst auch rein synchron und lokal (keine verteilte
> Kommunikation).
>
> Der Flussgedanke ist aber beiden gleich.
>

> Am 7. November 2011 19:28 schrieb Stefc <stefan.boet...@googlemail.com>:
>
> > Wenn ich EBC mit EDA (Event-Driven-Architecture) vergleiche, wie
> > stehen die beiden zueinander.
> >http://de.wikipedia.org/wiki/Ereignisgesteuerte_Architektur
>
> > Ist EBC analog zu EDA oder gibt es Unterschiede wenn ja welche?
>
> > Der wichtigste Vorteil einer EDA ist das sie anscheinend nicht
> > blockiert (z.B.Node.JS). Trifft dieses auch für EBC zu?
>
> > mfg stefc
>
> --
> Ralf Westphal - One Man Think Tank
> Hans-Henny-Jahnn-Weg 44
> D-22085 Hamburg
> Germany
> Tel 0170-3200458

> Email i...@ralfw.de

[Ralf Westphal]

Am 7. November 2011 20:01 schrieb Stefc <stefan....@googlemail.com>:

Andere Server Architekturen stürzen sich auf Multithreading (pro
Request ein neuer Thread mit Threadpooling) mit all seinem Problemen
um Leistung zu erbringen und jetzt kommt Node.JS mit einem anderen
Architekturansatz und alle sind begeistert davon ?!

Wenn man an den Einsatz mehrerer Threads denkt, dann sollte man sich fragen, was man will:

1. Latenz verbergen? Eine Datenquelle soll einfach nicht darauf warten, dass die Datensenke mit der Verarbeitung fertig ist. Dazu reicht Multithreading auf einem Kern.

2. Latenz reduzieren? Die Datensenke soll durch den Einsatz von mehreren Threads die Daten schneller verarbeiten. Dazu sind mehrere Kerne nötig, also echte Parallelität.

3. Durchsatz erhöhen? Jetzt können pro Sekunde 1000 Datenpakete verarbeitet werden, in Zukunft sollen es 5000 Datenpakete sein. Während es bei 1. und 2. nur um 1 Datenpaket ging, geht es bei 3. um viele Datenpakete. Dazu sind mehrere Kerne nötig, also echte Parallelität.

 

Ralf wie würdest einen Web-Server Anwendung auf der grünen Wiese
designen der z.B. auf dem gerade von HP vorgestellten Konzeptstudie
2800 ARM Server in einem Server Rack gut skaliert?
Wäre das pro Server eine EBC Hauptplatine (synchron) oder
eine Applikation mit bis zu 2800 Threads ?

Keine Ahnung. Das kommt auf die Anforderungen an. "Web-Server Anwendung" ist so wie "Fahrzeug" - zu allgemein.

Nur eines ist ja aber gewiss: Daten werden umso schneller verarbeitet, je exklusiver ihnen ein Kern/Prozessor zur Verfügung steht.

Das weiß jeder von der eigenen Arbeit. Wer einen Bericht zu schreiben hat, kommt damit schneller voran, wenn er ungestört ist.

2800 Rechner auf einem Haufen verteilen die eingehenden Requests eben auf 2800 Prozessoren statt auf 1 oder 16. Wenn die Requests unabhängig von einander sind, besteht die Chance, dass jeder schneller beantwortet wird.

Indem die Hardware die Parallelisierung vornimmt, habe ich dann vielleicht weniger Mühe bei der Software. Mein Prozess ist dann vielleicht single threaded - und läuft schlicht auf 2800 Prozessoren und alles ist gut.

 

Ich vermute fast das ein EBC bzw. EDA Ansatz bei solchen zukünftigen
Hardware Platformen von Vorteil gegenüber den jetzt weit verbreiteten
Multithreading Ansatz wo ich beim Design ständig aufpassen muss das
ich mit der Nebenläufigkeit nicht ins Stolpern komme!

Auch auf 2800 Prozessoren laufen die Dinge ja nebeneinander. Ob du aufpassen musst oder nicht, hängt nicht davon ab, ob du 1 Prozessor mit Multithreading hast oder 2800. Es hängt von der Aufgabe (bzw. deiner Lösung) ab, ob die Nebenläufigkeit easy ist oder nicht.

Email in...@ralfw.de