Apache Modul blockiert bei zip

[AndreasSt]

Hallo,
Ich habe mit Delphi ein Modul für den Apache entwickelt, das auf einem Apache unter Windows läuft.
Das Modul reagiert auf 2 unterschiedliche "Kommandos":
In der Funktion procedure TWebModule1.WebModule1DefaultHandlerAction
wird anhand des Inhaltes im Contentfield entschieden welche der beiden Funktionen angefragt wird.
Funktion1 liefert direkt eine Antwort als Text ohne irgendwelche sonstigen Aktionen. (Response.Content:='HALLO'; )
Funktion2 soll mit der Information aus dem Übergabeparameter folgendes tun:
- Aus einer Datenbank werden Daten geladen und in einzelne Files abgelegt.
- Diese Files werden in ein Zip gepackt.
- Das Zip wird in einem Download Bereich am Server bereitgestellt.
- Die DownloadURL wird am Schluss aus dem Modul heraus an den aufrufenden zurückgesendet damit dieser die Datei laden kann.
Bei vielen Daten nimmt das zippen ziemlich viel Performance am Server, das geht bis zu 100% CPU.

Das Ganze funktioniert, dauert manchmal aber am Server etwas länger, was aber kein Problem ist. Der Aufruf erfolgt vom Client als Post und da das meine eigene App ist die das aufruft kann ich da lange genug warten.

Mein Problem ist, dass wenn ich die Funktion2 aufrufe von einem Client aus und während das läuft mit einem anderen Client die Funktion1 aufrufe ich keine sofortige Antwort bekomme.
Verschiebe ich die Funktion2 in ein anderes Apache Modul, bekomme ich sofort eine Antwort obwohl der Server gerade mit dem zippen beschäftigt ist und die CPU teilweise bei 100% steht.
Ich habe gesehen dass in der dpr Datei des webmoduls standardmäßig folgendes gesetzt ist:
{$IFDEF MSWINDOWS}
CoInitFlags := COINIT_MULTITHREADED;

Ich habe aktuell auch nicht den Parameter application.MaxConnections gesetzt damit gehen wohl nur 32 parallele Aufrufe des moduls. (muss ich produktiv erhöhen)

Hat jemand eine Erklärung für das Verhalten bzw. ein Hinweis dass ich da grundlegend was falsch mache?
Vielen Dank
Gruß Andreas

[Olli73]

Ohne Code wird das schwierig...

[AndreasSt]

Ich habe nun weiter getestet.
Das Ganze hängt wahrscheinlich mit der Datenbankabfrage zusammen.
Aktuell verwende ich eine ADO Verbindung.
Vor dem Abruf wird die Connection erzeugt danach wieder gelöscht. Dabei wird auch coinitialize und couninitialize aufgerufen.

Hier der Handler:

Code:

procedure TWebModule1.WebModule1DefaultHandlerAction(Sender: TObject;Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
var
  contentFields:TStrings;
  i:Integer;
begin
  contentfields:=Request.QueryFields;  
  for i := 0 to contentfields.Count-1 do begin
    if contentfields[i].ToUpper.Contains('MITDB') then begin
      Response.Content:= getDBResponse;
      exit;
    end;
    if contentfields[i].ToUpper.Contains('OHNEDB') then begin
      Response.Content:= getNormResponse;
      exit;
    end;
  end;
end;

//Hier die Funktionen die aufgerufen werden

Code:

function TWebModule1.getDBResponse:string;
var
  MyADOConnection : TADOConnection;
  MyAdoQuery      : TADOQuery;
  NewGUID:TGUID;
  myZipFile: TZipFile;
  bs: TStream;
  contentStream: TMemorystream;
begin
  CoInitializeEx(nil,COINIT_MULTITHREADED);
  MyADOConnection := TADOConnection.Create(nil);
  MyADOConnection.ConnectionString :='bla'; 
  MyAdoQuery      :=  TADOQuery.Create(nil);
  MyAdoQuery.Connection := MyADOConnection;
  MyADOConnection.Connected := true;
  
  myZipFile := TZipFile.Create;
  CreateGUID(NewGUID);
  myZipFile.Open('C:\temp\'+GUIDToString(NewGUID)+'.zip');
  MyADOQuery.SQL.Text := 'SELECT bla bla'; 
  MyADOQuery.Open;
  while not MyADOQuery.Eof do Begin
    bs := MyADOQuery.CreateBlobStream(MyADOQuery.Fields[0], bmRead);
    contentStream.CopyFrom(bs, bs.Size);
    bs.Free;
    contentStream.Position:=0;
    MyZipFile.Add(contentStream, generateFileName), zcDeflate);
  end; 
  ms.Free;
  MyZipFile.Close;
  MyZipFile.Free;
  Result:= '';//URL zum zipfile
end;

function TWebModule1.generateFileName:string;
begin
  Result:='';//erzeugt einen eindeutigen Filename
end;

function TWebModule1.getNormResponse:string;
begin
  Result:='Hallo';
end;

Das Verhalten ist so, dass wenn ein Aufruf der Aktion 'MITDB' erfolgt und diese lange läuft, eine separate Anfrage der Funktion 'OHNEDB' keine Probleme macht.
Wenn aber gleichzeitig die Anfrage mit der Aktion 'MITDB' erfolgt kommt es zu Verzögerungen.
Vielleicht wäre einen Lösung auf eine andere DB Schnittstellentechnik zu gehen.

[Olli73]

Du solltest CoinitializeEx einmal zu Beginn im Hauptthread(!) aufrufen.

[Jumpy]

Hat bestimmt nix mit dem Problem zu tun, aber was macht ms.Free?

[AndreasSt]

Mir ist beim kopieren des Quelltextes ein Fehler unterlaufen.
In der function TWebModule1.getDBResponse:string;
wird am Schluss noch folgendes gemacht:
try
MyAdoQuery.Free;
MyADOConnection.Connected:=False;
MyADOConnection.Free;
finally
CoUninitialize;
end;

Da das webmodul ja xfach aufgerufen wird gibt es ja nicht den einen Hauptthread.
Das heißt ich komme ja immer aus dem Handler raus.
was ist der Unterschied zwischen
CoInitializeEx(nil,COINIT_APARTMENTTHREADED);
und
CoInitializeEx(nil,COINIT_MULTITHREADED);

Gruß

[AndreasSt]

ms.free ist eigentlich contentStream.free;
Auch ein Kopierfehler

[Olli73]

Also ich nutzte CoinitilazeEx sowohl im Haupt- als auch in den anderen Threads, und zwar mit COINIT_APARTMENTTHREADED.

[AndreasSt]

Hallo Olli,
Danke für die Rückmeldungen.
Setzt du in der dpr des Webmoduls das CoInitflags auf COINIT_APARTMENTTHREADED?
Also statt:

begin
{$IFDEF MSWINDOWS}
CoInitFlags := COINIT_MULTITHREADED;
{$ENDIF}
Web.ApacheApp.InitApplication(@GModuleData);
Application.Initialize;
Application.WebModuleClass := WebModuleClass;
Application.Run;
end.

dies hier:

begin
{$IFDEF MSWINDOWS}
CoInitFlags := COINIT_APARTMENTTHREADED;
{$ENDIF}
Web.ApacheApp.InitApplication(@GModuleData);
Application.Initialize;
Application.WebModuleClass := WebModuleClass;
Application.Run;
end.

[Olli73]

Ich rufe in der dpr auch CoInitilizeEx(COINIT_APARTMENTTHREADED) auf.

[Delphi.Narium]

Bei mir sieht das im Prinzip so aus:

Delphi-Quellcode:

unit WebModule1derWieSieAuchImmerHeißenMag;

interface

// Hier jetzt alles, was so implementiert wurde ...


initialization
  // Das wird für ADO dringend benötigt.
  CoInitializeEx(nil,COINIT_MULTITHREADED);

finalization
  CoUninitialize;

end.

Mein Erfahrung: CoInitialize sollte nur einmal aufgerufen werden und nicht bei jeder Anfrage ans Webmodul erneut.

[AndreasSt]

Hallo,
Könntest du mir mal Auszüge aus deiner dpr und aus dem eigentlichen Webmodul schicken? Notfalls auch als nachricht.
Danke

[Delphi.Narium]

Habe halt nur Delphi 7 und dort sieht eine typische dpr bei mir sinngemäß so aus:

Delphi-Quellcode:

library WebProjekt;

uses
  ActiveX,
  ComObj,
  ISAPIThreadPool,
  ISAPIApp,
  WebModuleUnit1 in 'WebModuleUnit1.pas' {wm: TWebModule},
  BrkrConst in '..\..\..\Delphi7\Source\Internet\BrkrConst.pas',
  WebBroker in '..\..\..\Delphi7\Source\Internet\WebBroker.pas',
  ... und weitere Units, sofern erforderlich
  ;

{$R *.res}

exports
  GetExtensionVersion,
  HttpExtensionProc,
  TerminateExtension;

begin
  CoInitFlags := COINIT_MULTITHREADED;
  Application.Initialize;
  Application.CreateForm(Twm, wm);
  Application.Run;
end.

Die Unit WebModuleUnit1 beginnt mit

Delphi-Quellcode:

unit WebModuleUnit1;

interface

uses
  HTTPApp,
  HTTPProd,

und endet mit

Delphi-Quellcode:

initialization
  // Das wird für ADO dringend benötigt.
  CoInitializeEx(nil,COINIT_MULTITHREADED);

finalization
  CoUninitialize;

end.

Der Webserver ist ein Eigenbau mit Hilfe der Indykomponenten und diesen Komponenten, für die Nutzung von ISAPI-Dlls bzw. CGI Programmen ID: 17810, idRunner 3.3 - ISAPI and CGI scripts support for Indy, erstellt.

Alles schon was älter, daher ist nicht auszuschließen, dass das Verhalten, im Zusammenspiel mit Apache, nicht absolut identisch ist.

[AndreasSt]

Danke für die Rückmeldung.
Ich habe weitere Tests durchgeführt.
Sobald 4 Anfragen am Modul laufen wird keine weitere Anfrage gestartet.
Es scheint so dass der Apache weitere Aufrufe blockiert bzw aufschiebt.
Sobald dann wieder eine Anfrage beendet ist kommt tatsächlich die nächste in Bearbeitung.
Ich habe daher den Parameter Application.MaxConnections: in der dpr angepasst, kein Erfolg.
In der httpd-mpm.conf habe ich folgende Einstellung:
<IfModule mpm_winnt_module>
ThreadsPerChild 150
MaxRequestsPerChild 0
</IfModule>

Auch mit dem MaxRequestPerChild Parameter habe ich getestet, ohne Erfolg.

Hat jemand eine Idee welcher Parameter verhindert dass da weitere gleichzeitige Anfragen bearbeitet werden?

Vielen Dank

[Delphi.Narium]

Erfolgen die Zugriffe von mehreren Clients oder nur von einem Client?

Sind nur ein Client und ein Server involfiert, könnte es mit der Spezifikation des HTTP-Protokolls zusammenhängen. Hier ist die Anzahl der gleichzeitigen Verbindungen zwischen Client und Server begrenzt.

part of Hypertext Transfer Protocol -- HTTP/1.1 - RFC 2616 Fielding, et al., letzter Absatz des Kapitels 8.1.4 Practical Considerations

Zitat:

Zitat von 8.1.4 Practical Considerations

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

Könnte es hier eventuell einen Zusammenhang geben?