AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Multithreading und Datenbanken

Multithreading und Datenbanken

Ein Thema von QuickAndDirty · begonnen am 5. Dez 2011 · letzter Beitrag vom 6. Dez 2011
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.371 Beiträge
 
Delphi 12 Athens
 
#11

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 14:33
Mehrere Connections zur Datenbank (je Thread) und dann sollte es keine Probleme geben.

Die meisten Datenbanken verkraften es ja auch, wenn mehrere zigtaustend Programme (mit je einer Connection) drauf zugreifen,
also sollte ein Programm, mit zigtausend Connections auch zu schaffen sein. (von Seiten der DB ist es ja egal von wo die Connections kommen)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
franktron

Registriert seit: 11. Nov 2003
Ort: Oldenburg
1.446 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#12

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 14:44
Was ich etwas seltsam finde ist eine Webanwendung die alle User in eine Instanz laufen lässt.

Webserver stelle doch normalerweise pro User eine Instanz zur Verfügung, und damit wäre das mit der Zeit doch kein Problem mehr.
Frank
Tux sein Lieblingsquellcode
While anzfische<TuxSatt do begin
Fisch:=TFisch.Create; Tux.EssenFisch(Fisch); Fisch.Free;inc(anzfische); end;
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.902 Beiträge
 
Delphi 12 Athens
 
#13

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 14:53
Was ich etwas seltsam finde ist eine Webanwendung die alle User in eine Instanz laufen lässt.

Webserver stelle doch normalerweise pro User eine Instanz zur Verfügung, und damit wäre das mit der Zeit doch kein Problem mehr.
Es ist ein A-To-Zed - Intrawebserver.
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.371 Beiträge
 
Delphi 12 Athens
 
#14

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 15:10
Es gibt quasi 3-4 Varianten, wie der Server das verwalten kann.

* eine Instanz der Serverklasse ... alle Befehlsaufrufe werden nacheinander behandelt

* eine Instanz der Serverklasse ... alle Befehlsaufrufe werden gleichzeitig behandelt

* je eine Instanz der Serverklasse pro eingehender Connection ... alle Befehlsaufrufe werden gleichzeitig behandelt
(in den Befehlsaufrufen könnte man diese aber wieder komplett/teilweise synchronisieren/blockieren/serialisieren)

* je eine Instanz der Serverklasse pro aufgerufenem Befehl jeder eingehenden Connection ... alle Befehlsaufrufe werden gleichzeitig behandelt
(in den Befehlsaufrufen könnte man diese aber wieder komplett/teilweise synchronisieren/blockieren/serialisieren)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.902 Beiträge
 
Delphi 12 Athens
 
#15

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 16:24
Wir haben szenario 3
wo dann dennoch alles wieder in eine Queue zusammengeführt wird.
die Funktionen in der Queue haben 3 Ausführungsmodi:
1 = asyncron (quasi eigener Thread Fire and forget)
2 = syncron (von denen kann nur eine gleichzeitig laufen, neben anderen asnycronen...)
3 = Mainthread(die Function wartet auf das ende aller threads und blockiert dann das ausführen weiterer, sie wird im Hauptthread ausgeführt...wegen blöder VCL abhängigkeit)

leider kommt ohne das ganze nur matsche raus....
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.006 Beiträge
 
Delphi 2009 Professional
 
#16

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 16:42
1 = asyncron (quasi eigener Thread Fire and forget)
2 = syncron (von denen kann nur eine gleichzeitig laufen, neben anderen asnycronen...)
3 = Mainthread(die Function wartet auf das ende aller threads und blockiert dann das ausführen weiterer, sie wird im Hauptthread ausgeführt...wegen blöder VCL abhängigkeit)
1 = unproblematisch, kann parallel mehrere Clientanfragen entgegennehmen und auch multithreaded laufen?
2 = alle Clientanfragen müssen serialisiert werden (Queue) da es sonst "Matsche" gibt?
3 = in einem Atozed Intraweb Server werden VCL Teile verwendet?

Für den letzten Punkt wäre eine Alterative, seine Verarbeitung aus der Intraweb Anwendung auszulagern in externe Prozesse, damit das blockieren der anderen Threads nicht mehr nötig ist. Könnte man einen eigenen Prozess je Clientanfrage starten, der nach dem Beenden seine Ergebnis-Daten irgendwie an Intraweb zurückliefert, oder einen Pool ständig laufender VCL-Anwendungen verwenden, die sich gegenseitig nicht mehr behindern können? Damit wäre der Server bzw seine Kerne besser ausgelastet.

Ist in Punkt zwei gemeint, dass es global genutzte Resourcen gibt die verhindern, mehrere Clientanfragen parallel auszuführen? (zum Beispiel eine Datenbanktabelle die für die gesamte Dauer der Requestverarbetung exklusiv einem Client gehört)?
Michael Justin
habarisoft.com

Geändert von mjustin ( 5. Dez 2011 um 16:51 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#17

AW: Multithreading und Datenbanken

  Alt 5. Dez 2011, 19:17
zum Thema Transaktion in Oracle:
wir nutzen im Wesentlichen seit Jahren ADO / OLEDB ohne klientseitige Transaktionssteuerung. Andere Zugriffe (App.Server, ..) ebenfalls mit impliziten Transaktionen. Das geht wunderbar- für Datenpflege/-verarbeitung.
Für lesenden Zugriff bzw. Reporting sehe ich da allerdings gar keinen Sinn. Wenn ich commited lese, bekomme ich genau das, was zum Zeitpunkt des Aufrufs commited war.
Intensive DV lagern wir in Jobs aus, die nur aus dem Klient angestoßen werden. Den Verlauf kann sich dann im Klient anschauen, wenn man mag. In einem Fall gibt es noch ein kleines DW für extreme Reportingfragen auf einer 2. Hardware. Ansonsten läuft auch viel über Snapshots, das ist für massive Reportanfragen sicher ratsam. Man müsste sich allerdings etwas Gedanken machen, wie man bestimmte Basissnapshots aufbaut, damit möglichst viele Reports das nutzen können. Queueing brachen wir nicht, auch nicht in Intranet Systemen, die auf diese DBs gehen.

In meinen Augen gäbe es nur einen einzigen Nutzen für klientseitiges Transaktionshandling, wenn nämlich der Anwender nach einem Verarbeitungslauf, Import oder so sagen möchte, "alles Quatsch, nicht commiten, rollback". Das hab ich mir zwar schon ab und zu gewünscht, aber der Preis, den man dafür zahlt, ist zu hoch.

Allgemein (gilt nicht nur für Oracle):
Man kriegt natürlich jede DB in die Knie, relativ problemlos. Umgekehrt gibt es aber den gleichen Effekt, Application Tuning und Architektur kann locker mal einen 3 oder 4 stelligen Faktor Performance bringen (natürlich abhängig davon, wie schlecht es vorher umgesetzt war). Eine Größenordnung, die mit neuer Hardware niemals erreicht werden kann.
Wenn man eine DB allerdings stur als Blackbox betrachtet, darf man auch keine großen Erwartungen haben.
Gruß, Jo
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.902 Beiträge
 
Delphi 12 Athens
 
#18

AW: Multithreading und Datenbanken

  Alt 6. Dez 2011, 09:04
1 = asyncron (quasi eigener Thread Fire and forget)
2 = syncron (von denen kann nur eine gleichzeitig laufen, neben anderen asnycronen...)
3 = Mainthread(die Function wartet auf das ende aller threads und blockiert dann das ausführen weiterer, sie wird im Hauptthread ausgeführt...wegen blöder VCL abhängigkeit)
1 = unproblematisch, kann parallel mehrere Clientanfragen entgegennehmen und auch multithreaded laufen?
Es ist so: Diese Aufgabe kann parallel oder zu irgendeiner aufgabe laufen, darf ruhig unterbrochen werden &c.
meist jedoch sind es so kleine aufgaben (abschicken eines Query ...) das da kein synchronisationsbedarf existiert,
2 = alle Clientanfragen müssen serialisiert werden (Queue) da es sonst "Matsche" gibt?
Aufgaben vom Typ 2 kommen in eine queue mit den aufgaben von typ 3 und werden immer nur eine nach der anderen bearbeitet.
3 = in einem Atozed Intraweb Server werden VCL Teile verwendet?
Nein wir haben 2 Programme einen Applikation server mit der Queue und den Funktionen und eben der Geschäftlogik &c. Der Atozed webserver rendert das ganze nur.


Für den letzten Punkt wäre eine Alterative, seine Verarbeitung aus der Intraweb Anwendung auszulagern in externe Prozesse, damit das blockieren der anderen Threads nicht mehr nötig ist. Könnte man einen eigenen Prozess je Clientanfrage starten, der nach dem Beenden seine Ergebnis-Daten irgendwie an Intraweb zurückliefert, oder einen Pool ständig laufender VCL-Anwendungen verwenden, die sich gegenseitig nicht mehr behindern können? Damit wäre der Server bzw seine Kerne besser ausgelastet.
Vermutlich ist die beste lösung daran zu arbeiten das der Applicationserver MultiInstanzfähig wird.

Ist in Punkt zwei gemeint, dass es global genutzte Resourcen gibt die verhindern, mehrere Clientanfragen parallel auszuführen? (zum Beispiel eine Datenbanktabelle die für die gesamte Dauer der Requestverarbetung exklusiv einem Client gehört)?
Nun, zu BDE zeiten gab es eine DB mit Localen Tabellen wenn da mehr als ein vorgang drauf gearbeitet hat gabs keine vernünftigen Ergebnisse...die sind allerdings mittlerweile abgeschafft bzw. als Durchnummerierte Temp_Tabellen in der normalen DB untergebracht.
Der andere Ultimative Grund ist der das wir sowas wie ein "Security Objekt" für den gerade angemeldeten benutzer haben (*facepalm*) alle möglichen alten Funktionen beziehen informationen von "DEM" im Applicationserver angemeldeten Benutzer.

Vermutlich macht es durchaus mittelfristig Sinn den Angemeldeten benutzer genauso wie im Webserver an den Thread zu kleben....leider ist der zur zeit noch Global.(*Aua*)

Das einfachste dürfte es wohl sein dem FB mehrere Prozessoren zu geben und mehrere instanzen des Applicationservers laufen zu lassen. Da müsste man dann noch drann arbeiten

wie geben ich dem FB mehrere Prozessoren?
Andreas
Monads? Wtf are Monads?

Geändert von QuickAndDirty ( 6. Dez 2011 um 09:09 Uhr)
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
530 Beiträge
 
#19

AW: Multithreading und Datenbanken

  Alt 6. Dez 2011, 10:06
Zitat:
wie geben ich dem FB mehrere Prozessoren?
Kommt auf deine verwendete Firebid Architektur drauf an. Classic und SuperClassic (neu in Firebird 2.5) Server verwenden von Haus aus mehrere CPUs/Cores. Für SuperServer muss der Konfigurationsparameter CpuAffinityMask entsprechend einer BitMask für die CPUS/Cores gesetzt werden. Aber, SuperServer in einer Produktionsumgebung mit mehreren CPUs/Cores macht eh nicht wirklich Sinn.
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.902 Beiträge
 
Delphi 12 Athens
 
#20

AW: Multithreading und Datenbanken

  Alt 6. Dez 2011, 10:58
Ok,
also habe ich da schon mal keine Optimierungsmöglichkeit.
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:09 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz