Steffen Pirsigs Twitter

[Martin Altmann]

Tja - ist ganz einfach: Möglichst viel den Server erledigen lassen, damit der Client nicht so viel zu tun hat
Es soll ja "Spezies" geben (auch bei uns in der Bank), die sich mittels select *... erstmal alles geben lassen und dann die Menge am Client nach den gewünschten Treffern durchflöhen...
Viele Grüße,
Martin

[AUGE_OHR]

hi,

http://databear.wordpress.com/2009/09/

hm ... ja ... aber ...

man startet also mehrere Threads, aber die gehen alle auf den "selben" Server.
angenommen eine Application startet 10 Thread und ich habe 10 User ... macht eine "Last" von 100 "Anfragen" ... also wie 100 "Single" User... ?
... ich weiss nicht wie das dann in der Realität aussehen soll wenn die "Last" 10x grösser wird ?


i have a Dream :
beim "Torrent" Systemen funktioniert es doch genau "andersherum" d.h. je mehr "gleichzeitig" online sind desto höher die (Download) Transferraten.
Es gibt nun "Server" (Seeds) und es gibt Clients (Peers) von denen man "gleichzeitig" (Threads) die Teile bekommt.

wenn nun X++ "so was" ähnliches könnte d.h. mehrere Verbindungen zu verschiedenen Server "gleichzeitig" um seine Abfrage zu starten ...

[Martin Altmann]

Hallo Jimmy,
was soll das bringen? Du wirst Deine Daten ja kaum auf mehreren SQL-Servern verteilt abgelegt haben - oder

Viele Grüße,
Martin

[Manfred]

Doch, Jimmy macht dass. Verlass Dich drauf.

[Martin Altmann]

Nun ja - ich sprach ja oben von der clientseitigen Sicht! Natürlich macht es Sinn, die Daten verteilt abzulegen - man braucht kein eigenes DR-System mehr und die Performance kann steigen, wenn man das sinnvoll macht! Aber das ist die serverseitige Sicht! Und die braucht einen Client nicht zu interessieren - der stellt seine Anfrage nach wie vor an genau einen Adressaten - den Manager.
Um den Rest (Server) kümmern sich Leute, die hoffentlich ihr Geld wert sind

Viele Grüße,
Martin

[AUGE_OHR]

hi,

was soll das bringen? Du wirst Deine Daten ja kaum auf mehreren SQL-Servern verteilt abgelegt haben - oder

Doch, Jimmy macht dass. Verlass Dich drauf.

ich würde es ja tun wenn es gehen würde...

die DBF´s habe ich schon in 2 "Bereiche" (Kunden / Lager) unterteilt die auf verschiedenen Servern liegen.
Das hat schon eine Menge gebracht da 1/2 der User "nur" auf das Lager zugreifen während die andere 1/2 meistens mit den Kunden (Fibu) zu tun hat.

Nun ja - ich sprach ja oben von der clientseitigen Sicht! Natürlich macht es Sinn, die Daten verteilt abzulegen - man braucht kein eigenes DR-System mehr und die Performance kann steigen, wenn man das sinnvoll macht! Aber das ist die serverseitige Sicht! Und die braucht einen Client nicht zu interessieren ...

schon klar, aber der Client stellt ja 10x so viele "Anfragen" also erzeugt er auch 10x mehr "Last" !?

Wie also soll ich das für "mein" Netzwerk verwenden ohne das ich "massiv" an Hardware für Arctica aufrüsten müsste !?
... und das ganze ist ja wohl auch nicht schneller (bei kleinen Datenmengen ist SQL sowieso langsamer als DBF SEEK)

Um den Rest (Server) kümmern sich Leute, die hoffentlich ihr Geld wert sind

JA ... aber genau "so" einen Server gibt es ja IMHO nicht, oder ?

... der stellt seine Anfrage nach wie vor an genau einen Adressaten - den Manager.

und hier wird es "interessant". Wie müsste sowas aussehen ... theoretisch ...

angenommen "jeder" hätte den kompletten Datenbestand "local" (verschlüsselt), dann hätte man die schnellste "Ladezeit".
Es müssten dann also "nur" Veränderungen "bekannt" gemacht werden damit der Datenbestand der Client´s "aktuell" sind.

genau "das" ist doch das "Torrent" Prinzip, das die Server KEINE Daten sondern nur die "Verwaltung" (Hashtable, Peerlisten etc) beinhalten.
der "Server" regelt also nur den Verkehr der Client´s und "sagt" ihnen "wo/was" vorhanden ist oder geändert wurde.

Diese "Problem" stellt sich z.b. auch bei "offline" Erfassung oder WLAN mit schlechter Verbindung.

Der Mitarbeiter hat auf seinem Notebook ja einen kompletten (verschlüsselten) Datenbestand.
Nachdem er einen neuen Auftrag erfasst hat, "hätte" sich ja was "geändert".
Das muss ich nun dem "Server" mitteilen der es wiederum "den anderen" Clients "erzählt".

Nun muss aber nicht sofort jeder Client darauf "reagieren", den wenn es den Client "nicht betrifft" kann er sich "später" darum kümmern (Priorität).

Es gehen also nur noch minimale Mengen an Daten über das Netzwerk ... oder der Client kann viel mehr gleichzeitige "Anfragen" stellen.

so einen (DBF) "Server" gibt es aber wohl (noch) nicht, also müsste man so ein Ding mal schreiben ... :-"

[Martin Altmann]

schon klar, aber der Client stellt ja 10x so viele "Anfragen" also erzeugt er auch 10x mehr "Last" !?

Ja - aber dadurch nutzt er die vorhandenen Ressourcen nur besser aus

JA ... aber genau "so" einen Server gibt es ja IMHO nicht, oder ?

Na klar - schon seit etlichen Jahren!
Vor über 10 Jahren (ungefähr) hat bereits MS genau so was groß rausgebracht - und die sind (sicherlich) nicht die einzigen! Die Logik wird von den Daten getrennt. Die Speicher (SAN/NAS/was_auch_immer) werden bereitgestellt und dem Server bekannt gemacht. Der nutzt die "Wolke" für seine Daten. Was dabei wo liegt, ist ihm völlig egal (und braucht ihn auch nicht zu interessieren)!
Wir sind gerade dabei, ein Metrocluster hochzuziehen (Metropolitan cluster, also standortübergreifend, innerhalb einer Metropole). Dabei werden in dem Metrocluster (zwei M9000) nicht nur diverse virtuelle Maschinen bereitgestellt, sondern auch (pro M9000) ein Filer. In diesem (untereinander werden ja beide M9000 gespiegelt - natürlich in Echtzeit) liegen alle von den (physikalischen und logischen) Maschinen genutzten Filesysteme.
Die MS-Variante war damals ähnlich aufgebaut - einfach eine Wolke (Cloud) bereitstellen, in der die Daten liegen. Klar kann man innerhalb des SQL-Servers auch einzelne Datenbanken oder auch Tabellen oder Views oder ... gezielt auf verschiedenste Filesysteme auslagern (linkes tables sind hierbei nur ein Stichwort). Wenn man dabei berücksichtigt, dass verschiedenste Filesysteme auf diversen Datenträgern mit unterschiedlichsten Geschwindigkeiten/Latenzen vorhanden sind, kann man damit schon ein wenig tunen.

Viele Grüße,
Martin

[AUGE_OHR]

Ja - aber dadurch nutzt er die vorhandenen Ressourcen nur besser aus

welche Resourcen (= Bandbreite)... ich nutze doch schon "maximal" alles aus was geht ...

angenommen mehrere User sind gleichzeitig in einem Browse und "blättern" ... das erzeugt massive "Last" bis zu 100% beim Client (nix geht mehr ...)

da noch eine Thread aufzumachen geht vielleicht beim DualCore, aber ohne HT macht der PC in solchen Situationen "nichts" (ausser warten ...)

Na klar - schon seit etlichen Jahren!
Vor über 10 Jahren (ungefähr) hat bereits MS genau so was groß rausgebracht ...
...
Wir sind gerade dabei, ein Metrocluster hochzuziehen...
...
Die MS-Variante war damals ähnlich aufgebaut - einfach eine Wolke (Cloud) bereitstellen...

ok das ist mir eine Nummer "zu hoch" und auch eine andere Grössen Ordnung.

ich denke mal bei dem M$ Produckt reden wir vom vielen $$$ und massive GB von *.DLL ... der µTorrent Client ist aber nur 300 Kb(!!!)

[Martin Altmann]

Hallo Jimmy,

welche Resourcen (= Bandbreite)... ich nutze doch schon "maximal" alles aus was geht ...

natürlich tust Du das nicht Wenn dem so wäre, hättest Du ein Riesenproblem! Ein SQL-Server kann nicht durch eine einzelne Anfrage ausgelastet werden - wie sollte er sonst noch andere Anfragen bedienen können Also stellst Du mehrere parallele Anfragen, um mehrere "Häppchen" der verfügbaren Ressourcen zu bekommen. Lies mal den Beitrag durch und betrachte die Tabelle.
Viele Grüße,
Martin

[brandelh]

Hi,

das Torrent-System hinkt im Vergleich

Denn es stellt nur mehrere identische Quellen zur Verfügung, eine Datenbank mit Schreib- und Lesezugriffen,
müsste man danach noch syncronisieren ...

Ich weiß nicht, ob die Tests über ODBC gingen oder die direkte DLL Eingabe genutzt haben.
Ich hatte vor Jahren bei Test mit SQLExpress() festgestellt, dass die ODBC Schnittstelle lahm ist.
Aber ähnlich wie in ActiveX und Excel liegt die Lösung darin nicht jeden Satz einzeln hochzuladen,
sondern mehrere Sätze zu sammeln und diese dann im 10er oder 100er Pack hochzuladen.
Die genauen Ergebnisse habe ich nicht mehr im Kopf, aber ich meine 10 Block => braucht nur 1/10 der Zeit

[AUGE_OHR]

hi,

das Torrent-System hinkt im Vergleich

YUP ...

Ich will auch nicht die "Transferraten" von "Torrent" System mit einem "local" Netzwerk vergleichen,
sondern eher die "Logic" des Netzwerk (de-Zentral) die dem des Internet entspricht.

Auch ist das Internet ja nicht immer verfügbar und wenn ich dann online gehe möchte ich ihn dann "aktuallisieren".
Diese Situation wäre z.b. bei Aussendienst Mitarbeitern und Notebooks der Fall.

Denn es stellt nur mehrere identische Quellen zur Verfügung,

sorry das ist so nicht ganz richtig. Es kommt ja darauf an welche "Grösse" du mit der "Quelle" meinst.

Eine DBF sehe ich nicht als "ganzes" und die "Quelle" stellt für mich 1 Datensatz dar.
Dieser Datensatz soll/muss bei allen identisch sein und in der Summe ist es dann die ganze DBF.

Ich muss ja auch bei einem APPEND pro Datensatz vorgehen wenn ich eine Prüfung der Daten (Termin, Bestand) vornehmen will.

eine Datenbank mit Schreib- und Lesezugriffen,müsste man danach noch syncronisieren ...

sag ich doch das dass synchronisieren "das" Problem ist was ein "Server" machen müsste. Der "Server" müsste aber den Datensatz gar nicht selbst "haben".
Er müsste es nur "verwalten" und wissen wo der Datensatz ist und die Anfrage dorthin weiterleiten und genau das ist doch das "Torrent" Prinzip.

Der Client hat als "Peer" bei den "Torrent" Prinzip ja mit den anderen "Peer" eine Verbindung und gleicht solange seine Daten ab bis alles "stimmt" .

Das Prinzip könnte man nun ausnutzten um z.b. Termine unter verschiedenen "Peer" auszuhandeln, wenn Überschneidungen existieren.
Erst wenn alle "Peer" ein OK melden werden die Bewegungsdaten Daten per APPEND an die Stammdaten angehängt/editiert.

Frage : wie können mehrere Xbase++ Applicationen "miteinander" kommunizieren ? Xb2Net ?