Daten in (fast) Echtzeit auslesen und per HTML darstellen..

Django, Flask, Bottle, WSGI, CGI…
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

Zuerst mal hallo hier im Forum. Ich habe zwar schon ein paar kleine Sachen in Python gemacht, aber das waren eher Skripte und weil mich Webentwicklung sehr interessiert, auch diverse Webframeworks. Ein paar kleine Projekte, wie ein Ticketingsystem etc. habe ich schon programmiert, aber das war wie immer schnell geschriebener Code der genau für diesen einen Zweck gut war und dafür auch soweit funktioniert, bis halt mal ein Fehler kommt, der wird dann halt behoben wenn er auftaucht. Das nächste Projekt würde ich nun aber gerne richtig aufziehen, deswegen mal ein paar Fragen an euch :)

Ich habe vor, für unsere Hotline eine kleine Webapplikation zu schreiben, die vorrangig aus einer MySQL-Datenbank Daten ausliest und diese möglichst schnell, am besten in Echtzeit, ausliefert an eine Website, die auf den TFTs / Fernsehern die wir an die Wand hängen, dargestellt wird.

Da ich mir wirklich gerne durchlese, was es so an neuen Technologien, Python-Paketen etc. gibt, bin ich was das angeht, glaube ich auf einem ziemlich guten Wissenstand, aber ich glaube mir fehlt gerade der rechte Durchblick, was ich denn nun wofür nehmen soll. Ich teile das ganze mal in verschiedene Bereiche auf.

Auslieferung in Echtzeit bzw. fast Echtzeit

Da es ja vor allem um Anrufe und dergleichen geht, muss das ganze wirklich fix ausgeliefert werden.
Der erste Ansatz der einem einfällt, ist die Seite bzw. natürlich Web 2.0 mäßig eher einen Teil der Seite in Intervall neu abzurufen, und das Skript ruft den Wert dann jeweils frisch aus der Datenbank ab.

Aber muss das denn sein? Ich würde es gerne lieber so haben, das sobald sich der Wert in der Datenbank ändert, das Skript aktiv wird und das ganze an die Website pusht, statt das die Seite in extrem schnellen Intervallen ständig pollt.

Am liebsten wäre es mir ja, wenn schon die Datenbank sich selbst meldet, wenn sie sich ändert - sowas wie ein inotify für Datenbanken :) - aber das ist mit einfachen Mitteln nicht zu bewerkstelligen, wie ich festgestellt habe und außerdem habe ich sowieso keinen Schreibzugriff auf die Datenbank und irgendwelche seltsamen Basteleien mit Triggern und Functions falls die überhaupt dann funktionieren, wären eh nicht möglich.

Trotzdem stört es mich, die Datenbank bei jedem Zugriff abfragen zu müssen. Aber bleibt mir wohl nichts übrig.
Was ich aber vielleicht abschaffen könnte ist das ständige Polling der Seite.

Ich hab mir ja schon überlegt ob ich sowas wie Websockets verwenden könnte, aber dazu gibt es bislang extrem wenig Infos im Web.
Verwenden könnte ich es schon, denn einen brandaktuellen Browser aus Vorraussetzung ist auf Clientseite natürlich nichts was einen vor Schwierigkeiten stellt.

Naja, ich würde mal gerne von euch wissen wie ihr das lösen würdet.
Nicht in Form von Code, sondern mit welcher Art von Ablauf und welchen Python Libraries etc. :)

Darstellung

Soll natürlich möglichst groß dargestellt werden, entweder in kleinen Fensterchen oder in einem Fenster, das je nach Anzahl der Werte die dargestellt werden (vermutlich 4-8) skaliert werden muss.
Dabei ist mir aufgefallen, das das Anpassen von Schrift bzw. der Größe der Schrift anhand der Fensterbreite gar nicht so einfach ist. Die Schrift wird ja über ihre Höhe definiert und die Breite ist je nach Schriftart unterschiedlich - hier gibt es also keinen Wert den ich direkt verwenden könnte bzw. sagen kann: Der Text soll immer proportional vergrößert werden und immer 100% der Fensterbreite verwenden.

Hierbei dachte ich mir, das es vermutlich sogar einfacher wäre, statt HTML lieber SVG auszuliefern, hier kann ich sagen, skalier mir das entsprechend.
Aber das wirkt für mich auch nicht wie der schönste Weg.
(Und Flash werde ich definitiv NICHT verwenden, nein.)

Sonstiges

Außerdem werde ich wohl Bottle als kleines Web Framework verwenden, für die Adminoberfläche.
Hier wird konfiguriert ob der Wert für das jeweilige Feld aus der Datenbank kommt, aus welchem Feld, welcher Wertebereich okay ist (grün) heikel (gelb) und kritisch (rot)
Alternativ sollen auch Zahlenwerte verwendet werden, die von einer anderen Datenquelle stammen, wie etwa einer Textdatei irgendwo im Netzwerk etc.


Aber das alles nur zur Vollständigkeit halber.
Mir ging es vor allem um die Thematik Echtzeit, ist ständiges Pollen evtl. im Sekundentakt oder evtl. gar öfter wirklich der einzige Weg?
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Du hast 3 Möglichkeiten: Web Sockets, Event Streams und Polling.

Web Sockets und Event Streams sind die elegantesten Möglichkeiten aber sind nicht drin wenn du nicht bereit bist auf WSGI, Unterstützung für nicht-aktuelle Browser oder IE zu verzichten. Damit bleibt dir dann Polling.

Zur Darstellung macht man es üblicherweise so dass der Server entweder die Daten sendet oder schon fertiges HTML. Davon hier SVG zu nutzen würde ich abraten, zum einen ist es semantisch unschön, zum anderen kannst und solltest du nicht einfach Text wie Bilder behandeln, wenn Lesbarkeit eine Rolle spielt.
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

DasIch hat geschrieben:Du hast 3 Möglichkeiten: Web Sockets, Event Streams und Polling.

Web Sockets und Event Streams sind die elegantesten Möglichkeiten aber sind nicht drin wenn du nicht bereit bist auf WSGI, Unterstützung für nicht-aktuelle Browser oder IE zu verzichten. Damit bleibt dir dann Polling.

Zur Darstellung macht man es üblicherweise so dass der Server entweder die Daten sendet oder schon fertiges HTML. Davon hier SVG zu nutzen würde ich abraten, zum einen ist es semantisch unschön, zum anderen kannst und solltest du nicht einfach Text wie Bilder behandeln, wenn Lesbarkeit eine Rolle spielt.
IE und nicht-aktuelle Browser spielen bei mir keine Rolle, somit ist alles für mich relevant.

Kennst du irgendwelche guten aber nicht zu komplexen Beispiele für Web Sockets und Events Streams in Python, welche ich mir mal anschauen kann und davon lernen kann?

Soviel zum Bereich Anzeigefensterchen <-> Pythonskript, nun zum Bereich Pythonskript <-> Datenbank:

Wie sieht das mit dem Zugriff auf die MySQL-Datenbank aus? Irgendne Idee, wie ich das schöner realisieren kann als nur dummes ständiges Abfragen im Sekundentakt (bzw. in noch schnelleren Intervallen)? Irgendwie kommt mir das etwas plump vor, aber vielleicht das da halt einfach der Stand der Technik :)
deets

Du kannst mal einen Blick hierauf werfen:

https://bitbucket.org/deets/wirbelsturm/overview

Das habe ich mal zum experimentieren mit Comet/Long-Poll gebaut. Es ist etwas komplizierter als unbedingt notwendig, weil es sowohl bottle (synchron) als auch tornado (asynchron) benutzt. Und um dann die JS-same-origin-policy durchzusetzen, packe ich noch einen nginx davor. Im Grunde reicht dir tornado.

[edit]Noch ne kurze Anmerkung *warum* ich das gemacht habe: ich wollte einen Pfad probieren, bei dem ich eine bestehende WSGI-App mit einem event-basierten Server kombiniere, weil ich schon eine WSGI-Anwendung laufen habe.[/edit]

Was die DB angeht - da geht's nicht anders, sofern du nicht an den Code rankommst, der die Daten veraendert, wirst du auch keine Events generieren koennen. Und ob ich in die DB via Trigger etwas packen wollen wuerde, was dann wiederum nach draussen Events erzeugt - da waere ich eher skeptisch, denn wenn es da zu Problemen kommt, ist die DB-Integritaet oder Stabilitaet vielleicht in Gefahr.
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

Danke für die Infos und den Link zu deinem Code.

Ich habe gerade, nachdem ich bei der ersten Suche nach Websocket + Python nicht recht fündig wurde, folgende Bibliothek gefunden:
http://www.tavendo.de/autobahn/

Vielleicht kann ich das ganze dann doch gleich statt mit Comet mit Websockets machen ohne ganz von Grund auf anzufangen.

Andernseits, was die Info wegen der Datenbank angeht, wenn hier einfach das ganz normale wiederholte Pollen notwendig ist, dann frag ich mich, wieso ich mir die Mühe überhaupt machen soll. Dann kann ich ja auch einfach vom Javascript aus ganz normal das Skript das mir den Wert für mein Displayfensterchen ausgibt, jedes Mal frisch starten und jedesmal frisch nen Query machen lassen, wenn Datenbanken immer noch so altbacken funktionieren ;)
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Du kannst einen Cache verwenden so dass insgesamt nur ein Query pro Sekunde statt findet, dann macht es schon Sinn.
deets

Marcos hat geschrieben: Andernseits, was die Info wegen der Datenbank angeht, wenn hier einfach das ganz normale wiederholte Pollen notwendig ist, dann frag ich mich, wieso ich mir die Mühe überhaupt machen soll. Dann kann ich ja auch einfach vom Javascript aus ganz normal das Skript das mir den Wert für mein Displayfensterchen ausgibt, jedes Mal frisch starten und jedesmal frisch nen Query machen lassen, wenn Datenbanken immer noch so altbacken funktionieren ;)
Tjoa, sofern du nur eine 1-1 Client-Server-Beziehung hast, ist da wirklich kein grosser Unterschied. Aber schon in dem Moment, wo's 2 werden, verdoppelt sich auf der Datenbank die Last unnoettig....
Benutzeravatar
noisefloor
User
Beiträge: 3882
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,

was sind das überhaupt für Daten, die du darstellen willst? Und wie oft kommen neue Daten dazu?

Je nach dem macht es ggf. auch Sinn, über eine andere Art Datenbank nachzudenken...

Gruß, noisefloor
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Sogar MySQL hat nen Query-Cache. Ich wage es zu bezweifeln, dass zwischen der Anzahl der Clients und der Last der Datenbank eine 1:1 Beziehung vorliegt. Oder ich interpretiere in deets' Posts mal wieder zuviel herein :), wäre ja nicht das erste mal. Andererseits stellt sich die Frage, was die anderen Anwendungen, die sicherlich auf die Datenbank zugreifen, so für Last produzieren und wieweit die Datenbank schon am Limit ist. Dann stellt sich ja die Frage, wie wichtig Echtzeit ist, oder ob wir hier von 5sec oder 10sec Intervallen oder so + Laufzeiten reden. Wie nosefloor schon anmerkte, etwas mehr Infos über das Umfeld wären noch interessant zu erfahren.
deets

@frabron

Du hast natuerlich schon recht, dass die DB versuchen wird, gleiche queries irgendwie zu cachen. Insofern ist eine stumpfe verdopplung natuerlich nicht korrekt. Aber trotzdem ist ein Event-basiertes System resourcen-schonender, denn Verbindungsaufbau, Verarbeitung und auch das auslesen des Caches kosten Zeit - pro Client, pro Poll. Wenn ich das auf das notwendige reduziert bekomme, gewinne ich. Ob nun im Fall des OP in relevanten Bereich, wo es wahrscheinlich um lokale, aeusserst breitbandige Verbindungen geht, sei dahingestellt. Ist dann eher ein aestethisches Argument.
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Ja, du hast schon recht. Ich hatte mich nur gefragt, ob der Aufwand für eine Polling-Lösung (den ich nicht wirklich einschätzen kann), notwendig ist, wenn man per Request fragen kann und das Caching der DB überlässt. Zumal man ja eh irgendein Skript/Routine die DB fragen muss, ob sich was geändert hat. Ansonsten einfach 'nen schnelleren DB-Server kaufen :twisted: *

* So sieht's aus
deets

@frabron

Du meinst den Aufwand fuer eine asynchrone Loesung, oder? Polling ist ja sehr simpel...

Ich bevorzuge ganz klar asynch, natuerlich aber auch, weil ich den stack schon habe. Ein Vorteil davon ist uA dass nerviges favicon-geflacker wegfaellt (geht mir wirklich tierisch auf den zeiger, weil es immer beweging aus dem augenwinkel ist), und auch keine unnoetigen redraws anfallen (was man natuerlich auch anders implementieren kann, aber oft werden eben einfach die gepollten Seitenteile immer ersetzt).

Aber polling ist ganz klar deutlich einfacher.
frabron
User
Beiträge: 306
Registriert: Dienstag 31. März 2009, 14:36

Ich musste das grad noch mal nachschlagen: Ja, ich meinte wohl in der Tat die asynchrone Lösung. Mein Web-Fu ist da nicht so ausgeprägt, bzw. beschränkt sich doch sehr stark auf den Bereich "Anzeigen von Geodaten". Da geben die vorhandenen (OpenSource)-Clientlösungen oft den Weg schon vor, oder man hat ob der grossen Datenmengen gleich ganz andere Probleme :)
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

deets hat geschrieben:
Marcos hat geschrieben: Andernseits, was die Info wegen der Datenbank angeht, wenn hier einfach das ganz normale wiederholte Pollen notwendig ist, dann frag ich mich, wieso ich mir die Mühe überhaupt machen soll. Dann kann ich ja auch einfach vom Javascript aus ganz normal das Skript das mir den Wert für mein Displayfensterchen ausgibt, jedes Mal frisch starten und jedesmal frisch nen Query machen lassen, wenn Datenbanken immer noch so altbacken funktionieren ;)
Tjoa, sofern du nur eine 1-1 Client-Server-Beziehung hast, ist da wirklich kein grosser Unterschied. Aber schon in dem Moment, wo's 2 werden, verdoppelt sich auf der Datenbank die Last unnoettig....
Tja, so simple Sachen merkt man dann erst wenn man schon die ersten Testläufe in Produktivumgebung durchführt ;) deswegen danke fürs Erinnern, da hast du recht.
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

noisefloor hat geschrieben:Hallo,

was sind das überhaupt für Daten, die du darstellen willst? Und wie oft kommen neue Daten dazu?

Je nach dem macht es ggf. auch Sinn, über eine andere Art Datenbank nachzudenken...

Gruß, noisefloor
Eine proprietäre Telefonanlage (also nix mit Asterisk oder so, wo man woanders ansetzen könnte) welche ihre Daten, wieviele Leitungen frei sind, wieviele Personen angemeldet sind, und dergleichen in einer MySQL-Datenbank abspeichert. Auf die habe ich lesend Zugriff, aus ihr kann ich die Daten ziehen.

Leider kann ich deshalb nirgendwo anders ansetzen aktuell.
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

frabron hat geschrieben:Sogar MySQL hat nen Query-Cache. Ich wage es zu bezweifeln, dass zwischen der Anzahl der Clients und der Last der Datenbank eine 1:1 Beziehung vorliegt. Oder ich interpretiere in deets' Posts mal wieder zuviel herein :), wäre ja nicht das erste mal. Andererseits stellt sich die Frage, was die anderen Anwendungen, die sicherlich auf die Datenbank zugreifen, so für Last produzieren und wieweit die Datenbank schon am Limit ist. Dann stellt sich ja die Frage, wie wichtig Echtzeit ist, oder ob wir hier von 5sec oder 10sec Intervallen oder so + Laufzeiten reden. Wie nosefloor schon anmerkte, etwas mehr Infos über das Umfeld wären noch interessant zu erfahren.
Wie mir scheint arbeite ich jetzt alle Antworten Thread für Thread ab.
Du meinst also das MySQL eventuell eh schon für mich cached und wird gar nicht groß gestresst wenn eine Anfrage kommt ohne das eine Änderung da ist?

Nein, 5-10 sec wären schon zu viel. 1sec-Intervalle wären okay, aber eher gesamt gesehen, also von Abfrage bis der neue Wert wieder im Browser ist.

Ach ja, und bevor ich nochmal ne Antwort schreibe: Ja es geht primäe um die "lokale, aeusserst breitbandige Verbindung" - theoretisch könnte sich jemand die Fensterchen natürlich auch per VPN anzeigen lassen von unterwegs, aber bei diesem Einsatzgebiet kommt es dann nicht mehr um die Echtzeit bzw. 1sec Intervalle an. Vorrang hat das LAN, und da hat man Gigabit und somit was das angeht keine Probleme.
Benutzeravatar
noisefloor
User
Beiträge: 3882
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
Marcos hat geschrieben: Du meinst also das MySQL eventuell eh schon für mich cached und wird gar nicht groß gestresst wenn eine Anfrage kommt ohne das eine Änderung da ist?
Genau. Wobei es in deinem Fall wahrscheinlich nicht viel bringt, da sich die Daten häufig ändern. Eine IMHO ganz gute Erklärung findet man in der MySQL Doku.

Nochmal zu Echtzeit: Im IT-Bereicht heißt "Echtzeit" sowas wie innerhalb von 10 Millisekunden. Da brauchst du aber nicht wirklich, oder? Wenn's um die Darstellung der Leitungsbelegung geht, dann reicht doch auch 1x pro Sekunde... Und das schaffte jede DB locker, selbst von schon eine Last von anderen Anwendungen drauf ist.

Gruß, noisefloor
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

noisefloor hat geschrieben:Hallo,
Marcos hat geschrieben: Du meinst also das MySQL eventuell eh schon für mich cached und wird gar nicht groß gestresst wenn eine Anfrage kommt ohne das eine Änderung da ist?
Genau. Wobei es in deinem Fall wahrscheinlich nicht viel bringt, da sich die Daten häufig ändern. Eine IMHO ganz gute Erklärung findet man in der MySQL Doku.

Nochmal zu Echtzeit: Im IT-Bereicht heißt "Echtzeit" sowas wie innerhalb von 10 Millisekunden. Da brauchst du aber nicht wirklich, oder? Wenn's um die Darstellung der Leitungsbelegung geht, dann reicht doch auch 1x pro Sekunde... Und das schaffte jede DB locker, selbst von schon eine Last von anderen Anwendungen drauf ist.

Gruß, noisefloor
Ja 1 Sekunde würde gerade reichen, von der man aber sicherlich die Abarbeitung des Skripts und das Darstellen im Browser abziehen sollte.
Und das dann durchaus von diversen Clients aus ungefähr gleichzeitig.
Wenn ihr denkt das es hier nicht zu allzu großen Problemen kommt, polle ich ganz schlicht und einfach per Javascript und lasse jedesmal vom Pythonskript abrufen.

Dann kann ich mehr Zeit mit der Darstellung verbringen.. :)

Apropos: Falls jemand ne super simple Idee hat, wie man Text sinnvoll skalieren kann bei Fenstergrößenänderung, und zwar nicht nur was die font-size angeht, sondern halt das das ganze halt einfach immer sinnvoll ins Fenster auch von der Breite her passt, dann würde es mich natürlich freuen, da das hier aber ein Python-Forum ist und eher nen Javascript-Thema ist, nur optional ;)

Ich dachte auch mal daran statt HTML einfach SVG auszuliefern, weil das halt immer sauber proportional aber ins Fenster passend skaliert werden kann, aber das macht mir später bloß Kopfschmerzen. Canvas hab ich auch angedacht, aber da läuft es über scale, das wäre das gleich wie wenn ich die Textgröße skaliere.

Ich bräuchte was, wo ich Sachen kann "dehne den Text in diesem DIV, proportional so groß wie möglich aus".

Aber wie schon gesagt, nur falls jemand ne schnelle Idee hat, sonst betrachtet das Thema als erledigt und dann bedanke ich mich auch schonmal.. :)
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@Marcos:
Wieviele Clients werden denn voraussichtlich im Spiel sein, die die DB stressen könnten? Rufen die alle dieselben Inhalte ab? Wie sind die zum Server angebunden (Intranet/Internet)?
Sind die Clients schnell angebunden, kannst Du das Anfrageintervall deutlich kleiner machen. Sollten alle Clients dasselbe von der DB anfragen, kannst Du die Information über eine DB-Verbindung anfragen und den Clients weitergeben. Der Aufwand einer solchen Server-Mittelschicht lohnt allerdings nur, wenn die Pollingrate*Clients zu einer echten Belastung der DB führen würde.
Clientseitig würde ich ein Webseitengerüst ausliefern, in welches dann per Polling die z.B. JSON-formatierten Daten platziert werden. websockets habe ich selbst noch nicht benutzt, wäre aber eine interessante Alternative.
Was spricht eigentlich gegen die Präsentation mit HTML/CSS? Falls Du SVG nutzen willst, gibts mit Raphael eine JS-Bibliothek, welche SVG-Handling halbwegs kopfschmerzfrei werden lässt.

NB: Echtzeit meint in der Informatik die vorhersehbare Abarbeitung innerhalb eines Zeitfensters, nicht das etwas besonders schnell ist bzw. innerhalb von 10ms reagiert.
Marcos
User
Beiträge: 16
Registriert: Sonntag 4. Dezember 2011, 12:28

jerch hat geschrieben:@Marcos:
Wieviele Clients werden denn voraussichtlich im Spiel sein, die die DB stressen könnten? Rufen die alle dieselben Inhalte ab? Wie sind die zum Server angebunden (Intranet/Internet)?
Sind die Clients schnell angebunden, kannst Du das Anfrageintervall deutlich kleiner machen. Sollten alle Clients dasselbe von der DB anfragen, kannst Du die Information über eine DB-Verbindung anfragen und den Clients weitergeben. Der Aufwand einer solchen Server-Mittelschicht lohnt allerdings nur, wenn die Pollingrate*Clients zu einer echten Belastung der DB führen würde.
Clientseitig würde ich ein Webseitengerüst ausliefern, in welches dann per Polling die z.B. JSON-formatierten Daten platziert werden. websockets habe ich selbst noch nicht benutzt, wäre aber eine interessante Alternative.
Was spricht eigentlich gegen die Präsentation mit HTML/CSS? Falls Du SVG nutzen willst, gibts mit Raphael eine JS-Bibliothek, welche SVG-Handling halbwegs kopfschmerzfrei werden lässt.

NB: Echtzeit meint in der Informatik die vorhersehbare Abarbeitung innerhalb eines Zeitfensters, nicht das etwas besonders schnell ist bzw. innerhalb von 10ms reagiert.
Naja, eventuell rufen die auch mal ein, zwei der Felder unterschiedlich ab, also das mal ein Wert der nur für diesen Raum relevant ist, aber für einen anderen nicht, angezeigt wird.
Also nicht immer gleich, deswegen fällt die Middleware eher flach.

Bei der Anbindung: Fokus liegt ganz klar auf dem Intranet und damit Gigabit-Netzwerk ggf. an diversen Stellen noch 100Mbit aber das ist ja egal.
Wenn es übers Internet auch leidlich gut funktioniert ist das zwar nett aber nicht so wirklich wichtig.

Raphaël hab ich mir natürlich angeschaut, aber da gibts auch nur scale, mit dem man mit Werten wie 0.5 oder so skalieren kann, vom Urzustand des Objekts her.
Aber das ganze "mach das immer so groß wie das Fenster proportional" geht nicht, weil das ja in irgendnem Element drin liegt im HTML.
Skalieren geht nur wenn das direkt als SVG ausgeliefert wird.

Aber ich hab jetzt was gefunden, das mir viel Programmierarbeit erspart:
http://www.shapevent.com/scaleraphael/
"The main purpose of ScaleRaphaël is to scale the paper up to the size of the browser window."
Demo: http://www.shapevent.com/scaleraphael/demo1.html

Deiner Definition von Echtzeit hätte ich jetzt auch entsprochen: Nämlich innerhalb den Zeitfenstern, in denen sich der Wert verändern kann, auch ausliefern zu können.
Antworten