Das haben die schon x-mal versucht, ohne daß das aber eine wirklichen Erfolg gebracht hätte. Du mußt dir mal ansehen was das System treiben muß um eine solche Anfrage zu erledigen. Das wurzelt sich da durch mehrere Datenbanken und muß dann noch zwischendurch Zustandsprüfungen machen. Bis das fertig ist vergeht schon seine Zeit, die ist aber eben auch nicht vorhersagbar. Bei älteren Anwendungen kam dann noch hinzu, das während der Anfrage meistens auch noch die Anwendung gefreezt war, was das ganze nicht gerade angenehmer gemacht hat. Viele von den Dingern laufen heute noch.
Ich bin da eher für die elgante Lösung die auch garantiert zum Erfolg führt. Aber da hat halt jeder seine eigene Philosophie.
Schade das du das Stück Quellcode aus dem Zusammenhang gerissen hast, aber trotzdem meinen tief empfundenen Dank für den Hinweis. Vielleicht freunde ich mich ja mit den Synapse doch noch an.
Wie war das eigentlich mit deinen RIMM's, müssen die zwingend Samsung sein wegen der Synchronisierung?
Chat mit Synapse
-
- Beiträge: 1187
- Registriert: Mi 13. Dez 2006, 10:58
- OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
- CPU-Target: AMD A4-6400 APU
- Wohnort: Hamburg
Ja, nur würde ich da einfach mal drauf tippen, dass das Problem nicht in TCP/IP zu suchen (und zu lösen) ist, sondern im Datenbankteil oder was-auch-immer.schnullerbacke hat geschrieben:Das haben die schon x-mal versucht, ohne daß das aber eine wirklichen Erfolg gebracht hätte. Du mußt dir mal ansehen was das System treiben muß um eine solche Anfrage zu erledigen.
Und bevor man den Client zum Server macht, gäbe es andere Ansätze wie z.B.
(spontan-Einfall): Der Client gibt dem Server eine Abfrage in Auftrag, Erhält vom Server ein "Ticket" (ID) und die momentane durchschnittliche Wartezeit und verabschiedet sich wieder. Nach der Wartezeit holt der Client mit der ID das Resultat ab.
Aber dadurch verbessert sich die Gesamtperformance auch nicht wirklich, genau wie bei deinem Vorschlag.
Der Zusammenhang bei Synapse ist im Zweifel immer blcksock.pas.schnullerbacke hat geschrieben: Schade das du das Stück Quellcode aus dem Zusammenhang gerissen hast, aber trotzdem meinen tief empfundenen Dank für den Hinweis. Vielleicht freunde ich mich ja mit den Synapse doch noch an.
Hier genauer:
procedure TBlockSocket.SetDelayedOption(const Value: TSynaOption);
Nach "aussen hin" ist es aber ein Property:
Code: Alles auswählen
{:If @True, turn class to non-blocking mode. Not all functions are working
properly in this mode, you must know exactly what you are doing! However
when you have big experience with non-blocking programming, then you can
optimise your program by non-block mode!}
property NonBlockMode: Boolean read FNonBlockMode Write SetNonBlockMode;
Das Problem ist: ich weiss es nicht. Ich hab nur mal gelesen, dass z.B. NEC oder Kingston nicht so gut funzen. Wäre halt Risiko und hängt deshalb vom Preis ab.schnullerbacke hat geschrieben: Wie war das eigentlich mit deinen RIMM's, müssen die zwingend Samsung sein wegen der Synchronisierung?
Aber vielen Dank für deine Bemühungen!
-
- Beiträge: 1187
- Registriert: Mi 13. Dez 2006, 10:58
- OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
- CPU-Target: AMD A4-6400 APU
- Wohnort: Hamburg