Zitat:
Ein Tunnel z.B via zeebeedee (mit höchster
zlib Kompression)
Kann es sein, dass bei vielen kleinen Abfragen ein Grossteil der Latenz durch die hohe Komprimierung und Verschlüssleung der Pakete entsteht?
Kann Zeebeedee Abfragen-Abhängig verschlüsseln / komprimieren?
Ich habe mir für solche Zwecke über die Jahre ein inzwischen recht gut funktionierende Middleware mit Paket-Protokoll geschrieben, bei dem ich solche Sachen selbst in der Hand habe, sprich, auf meinem Server lauscht meine eigene Server-Applikation, die dort lokal an einer Firebird hängt.
Clients konnektieren sich nicht direkt auf die Firebird, sondern auf meine Server-Applikation / Middleware.
Mit dieser kann ich dann über OPCodes und
Package-Types steuern, welche der Pakete verschlüsselt werden (bei sehr sensiblen Daten aymmetrisch mit RSA, mittelprächtige symmetrisch Blowfish und unsensible Daten gar nicht) und ebenso, ob das Paket komprimiert wird.
Damit habe ich folgende Vorteile:
1) Ich bin nicht auf das Firebird-Netzwerk-Protokoll angewiesen, das ziemlich aufgeblasen ist
2) Ich kann den Overhead an Paketen minimal halten, je nach Situation, da ich statt Firebird meinen Server befrage, der die Daten dann lokal abfrägt und mir ggf. schon aufbereitet / gestrippt schickt.
3) Ich kann die Geschwindigkeit / Latenz viel besser tweaken, da ich selbst in der Hand habe, was genau übers Netz verschickt wird.
4) Ich kann die Datenbank später ggf. gegen eine andere (
mySQL, PostGre etc.) austauschen, ohne dass dies die Clients irgendwie beeinflusst, da die Queries nur über die Middleware lokal auf dem Server ausgeführt werden und die Clients somit nie direkt
SQL-Queries schicken, sondern meine Middleware-
API verwenden.
Firebird selbst empfiehlt ja auch eine Art von Middleware:
Zitat:
Firebird has a rather heavy network protocol (a lot of chit-chat), so it isn't really comfortable to work accross the Internet. You can use some tunneling software like ZeBeDee,
SSH or SSL to encrypt and compress the data, but latency is the main problem as a lot of messages go back and forth (and transfering a lot of small messages over Internet is much slower than one big message).
For this reason it's better to use some middleware or serve the content as web pages (if applicable to your requirements) or use some kind of
SOAP.
Was mir noch enfällt ist, manche Abfragen vielleicht auf Stored Procedures auszulagern, falls es geht, das bringt auch manchmal etwas Geschwindigkeit.