"Echtzeit"-Darstellung von Daten im Browser

[Jan-Benedict Glaw]

On Sun, 2007-09-09 01:58:23 +0200, Dominik Echterbruch <news_de at crosslight.de> wrote:
> Maximilian Wilhelm schrieb:
> > > > Das hängt alles davon ab, wie viel Zeit Du brauchst, um die Daten
> > > > aufzubereiten.  Grundsätzlich kann man das aber mit Hardware, load
> > > 9> balancern und round robin DNS erschlagen.
> > 
> > > Daß das möglich ist, bestreite ich nicht. Aber es sollte halt möglichst 
> > > effizient sein. Schließlich sind wir hier nicht bei Microsoft ;)
> > > Deshalb suche ich nach einer Möglichkeit, die Last möglichst niedrig zu 
> > > halten. Würde Geld keine Rolle spielen, wäre es einfach.
> > 
> > Dein Argument gegen Poor-mans-LoadBalancing ist?
> 
> Warum soll ich mich um Loadbalancing kümmern, wenn es durch reinen 
> Planungsaufwand im Vorfeld gar nicht nötig ist?

In der Größenordnung ist das vermutlich eben nicht mehr durch eine
Kiste machbar, aber um das einzuschätzen, fehlen die Details.

> > > > > - Könnte es evtl. aufgrund der Requestmassen Probleme mit ISPs geben?
> > > > Ist nicht Dein Problem.
> > 
> > > Es wird in dem Moment mein Problem, in dem ein Provider dem Benutzer den 
> > > Hahn zudreht. Die Frage war ja nciht, ob der ISP Probleme bekommt (das 
> > > ist tatsächlich nicht mein Problem), sondern, ob der ISP dem Benutzer 
> > > Probleme macht.
> > 
> > Was hast Du denn für Leitungen gekauft?
> > Falscher Provider?
> 
> Nicht *mein* Provider könnte Probleme machen, sondern die der Benutzer. 
> Warum soll ich mich nicht im Vorfeld schlau machen und Lösungen suchen, 
> statt im Livebetrieb plötzlich das Problem festzustellen?

Wenn der Provider Engpässe sieht, sollte er 'ne dickere Leitung
kaufen.  Ist sein Problem.

> > > Hilft es, die regelmäßigen Abfragen (initiiert durch z.B. JavaScript) 
> > > statt mit TCP mit UDP zu machen? Oder bringt mir (aka. dem Benutzer) das 
> > > überhaupt nichts? Abgeleitet habe ich das von DNS-Abfragen, die ja auch 
> > > zunächst via UDP laufen, um (vermutlich) Last zu sparen.
> > 
> > Wie willst Du JavaScript in UDP einpacken?
> 
> So langsam habe ich den Eindruck, daß du meine Erläuterung gar nicht 
> verstanden hast... Es geht nicht darum, JavaScript in UDP einzupacken, 
> sondern darum, ob die Anfragen, die JavaScript oder Ajax oder was weiß 
> ich im Sekundentakt sendet, durch UDP weniger Prozessor, weniger Traffic 
> oder sonst etwas braucht.

Die werden das alles via HTTPeng abholen.

> > > Wie weiter oben beschrieben, geht es zunächst mal nur darum, möglichst 
> > > schnell (also ressourcenschonend) an die Information zu kommen, ob sich 
> > > etwas geändert hat. 
> > 
> > Ajax auf ne bestimme Datei auf dem Server? PHP? $CGI?
> 
> OK, damit ist wohl klar, daß du tatsächlich nicht verstanden hast, worum 
> es geht. Ich werde es zur Entlastung des Mailservers jetzt nicht nochmal 
> wiederholen.

Es wär' sinnvoll, wenn Du das Projekt erstmal so vorstellst, daß ein
technisch versierter Mensch einen ordentlichen Vorschlag machen kann,
anstatt zu raten, was wann wie unter welchen Voraussetzungen
verschifft werden muß.

> > Es wäre vielleicht ganz gut, vorher die Grundlagen zu haben.
> 
> Das hier *sind* die Grundlagen. Was du gerne hättest, sind wohl eher die 
> Details. Ich kann mich natürlich zuerst um Details kümmern und dann 
> feststellen, daß ich alles über den Haufen werfen kann, weil es nicht 
> funktioniert. Ich finde es einen durchaus sinnvollen Ansatz, nicht 
> einfach loszuprogrammieren, sondern sich vorher Gedanken über 
> Möglichkeiten und deren Sinnhaftigkeit zu machen.

Genau. ...und dazu braucht man die Details.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:           Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second  :               Langsam möchte ich mal wieder weiterträumen können.
                             -- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20070909/b4cc65c4/attachment.sig>