xb2.net Stresstest
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
xb2.net Stresstest
Hi
ich habe bei einem Kunden eine Web-App mit xb2.net aufgebaut. Dieses läuft auf einem separten Gerät unter XP. Die Datenzugriffe erfolgen via ADSDBE auf den Datei-Server. Das ganze läuft einwandfrei und erfüllt die Anforderungen und Wünsche des Kunden.
Im Rahmen einer Risko Beurteilung/Bewertung wurde nun ein Stresstest der Web-App verlangt. (Vermutlich infolge der sich gehäuften Artikeln in der Presse)
Schon der einfachste Stresstest, ein mehrfachses get an 192.168.0.100/login? mit einem Stresstestprogramm killt nach wenigenn Sekunden die Web-App samt dem PC komplett. Es hilft nur noch Stecker raus.
Hat jemand auch schon solche Erfahrungen gesammlt?
Cu carlo
ich habe bei einem Kunden eine Web-App mit xb2.net aufgebaut. Dieses läuft auf einem separten Gerät unter XP. Die Datenzugriffe erfolgen via ADSDBE auf den Datei-Server. Das ganze läuft einwandfrei und erfüllt die Anforderungen und Wünsche des Kunden.
Im Rahmen einer Risko Beurteilung/Bewertung wurde nun ein Stresstest der Web-App verlangt. (Vermutlich infolge der sich gehäuften Artikeln in der Presse)
Schon der einfachste Stresstest, ein mehrfachses get an 192.168.0.100/login? mit einem Stresstestprogramm killt nach wenigenn Sekunden die Web-App samt dem PC komplett. Es hilft nur noch Stecker raus.
Hat jemand auch schon solche Erfahrungen gesammlt?
Cu carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Nein,
tut mir leid - eher im Gegenteil. Kannst ja mal hier http://www.xbaseforum.de/viewtopic.php?f=7&t=5781 lesen, was mein Server schon alles mitmachen durfte
Wie sehen denn Deine Slots aus:
::LingerTimeout()
::RecvTimeout()
::SendTimeout()
::MaxConnections
::onMaxConnect
::onGET
::onPOST
::onHTTPError
::onError
::onInvalidCommand
::onNotFound
::FilterRequest
bzw. wie die Funktionen, die dort jeweils aufgerufen werden?
Viele Grüße,
Martin
tut mir leid - eher im Gegenteil. Kannst ja mal hier http://www.xbaseforum.de/viewtopic.php?f=7&t=5781 lesen, was mein Server schon alles mitmachen durfte
Wie sehen denn Deine Slots aus:
::LingerTimeout()
::RecvTimeout()
::SendTimeout()
::MaxConnections
::onMaxConnect
::onGET
::onPOST
::onHTTPError
::onError
::onInvalidCommand
::onNotFound
::FilterRequest
bzw. wie die Funktionen, die dort jeweils aufgerufen werden?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Guten Morgen Martin
solche Logs wie du Sie beschrieben hast habe ich auch massenhaft, die waren noch nie ein Problem. Nach den IP Adressen kommen meine meist aus China.....
Meine Slots sehen so aus:
soServer:MaxConnections := 50
soServer:LingerTimeout(60)
// ::RecvTimeout() Nicht gesetzt -> Vorgabe 30000
// ::SendTimeout() Nicht gesetzt -> Vorgabe 30000
soServer:onMaxConnect := "Too many connections, please try later..."
soServer:onGET := {|o| HTTPHandler(o)}
soServer:onPOST := {|o| HTTPHandler(o)}
// ::onHTTPError Nicht gesetzt Standardverhalten xb2.net
// ::onError Nicht gesetzt --> kein Log Socketerror
// ::FilterRequest Nicht gesetzt
// ::onInvalidCommand Nicht gesetzt --> Standardverhalten xb2.net --> 501
soServer:onNotFound := {|o| OnNotFound(o)} // log access errors
Die in den Codeblöcken verwendeten Funktionen sind die Originalen Funktionen von XB2 mit kleinen Anpassungen.
Ich habe jetzt schon an einigen Werten geschraubt, ohne Erfolg, nach max. 15 Sekunden ist der Webserver samt PC absolut tot....
Was verwendest du für eine Hardware und Plattform für dein Webserver?
Cu Carlo
solche Logs wie du Sie beschrieben hast habe ich auch massenhaft, die waren noch nie ein Problem. Nach den IP Adressen kommen meine meist aus China.....
Meine Slots sehen so aus:
soServer:MaxConnections := 50
soServer:LingerTimeout(60)
// ::RecvTimeout() Nicht gesetzt -> Vorgabe 30000
// ::SendTimeout() Nicht gesetzt -> Vorgabe 30000
soServer:onMaxConnect := "Too many connections, please try later..."
soServer:onGET := {|o| HTTPHandler(o)}
soServer:onPOST := {|o| HTTPHandler(o)}
// ::onHTTPError Nicht gesetzt Standardverhalten xb2.net
// ::onError Nicht gesetzt --> kein Log Socketerror
// ::FilterRequest Nicht gesetzt
// ::onInvalidCommand Nicht gesetzt --> Standardverhalten xb2.net --> 501
soServer:onNotFound := {|o| OnNotFound(o)} // log access errors
Die in den Codeblöcken verwendeten Funktionen sind die Originalen Funktionen von XB2 mit kleinen Anpassungen.
Ich habe jetzt schon an einigen Werten geschraubt, ohne Erfolg, nach max. 15 Sekunden ist der Webserver samt PC absolut tot....
Was verwendest du für eine Hardware und Plattform für dein Webserver?
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Moin,
OK - die Timeouts sind bei mir jeweils doppelt so hoch.
onMaxConnect kann nicht einfach einen String erhalten - das wird sicherlich die Ursache für Deinen Absturz sein.
Ich nehme bei mir eine Funktion:
Dadurch wird die Verbindung auch gleich wieder getrennt!
"Meine" Hardware ist ein VServer bei hosteurope (den ich natürlich nicht für mich alleine habe) - das Paket Virtual Server Windows XL 3.0.
Viele Grüße,
Martin
OK - die Timeouts sind bei mir jeweils doppelt so hoch.
onMaxConnect kann nicht einfach einen String erhalten - das wird sicherlich die Ursache für Deinen Absturz sein.
Ich nehme bei mir eine Funktion:
Code: Alles auswählen
FUNCTION OnMaxConnect()
Local oResp := xbHTTPResponse():new()
oResp:StatusCode := 503
oResp:Content := '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"' + CRLF + '"http://www.w3.org/TR/html4/loose.dtd"><html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"></head><body><b>Server is temporarily busy!</b><br>Please try your request a little later...</body></html>'
oResp:Connection := "close"
Return oResp:AsString()
"Meine" Hardware ist ein VServer bei hosteurope (den ich natürlich nicht für mich alleine habe) - das Paket Virtual Server Windows XL 3.0.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Hallo Martin
nach der Beschreibung darf es auch ein String sein:
nMaxConnect exported/character | codeblock | NIL The nMaxConnect ivar determines what happens when :ActiveConnections reaches :MaxConnections. The following options are possible:
NIL - do not accept any more connections until an existing client connection is closed.
STRING - accept new connection, receive request, send string contained in nMaxConnect to client and immediately close connection.
CODEBLOCK - accept new connection, create new xbSocketThread object and execute codeblock contained in nMaxConnect within this new thread.
ich habe nun alle 3 Möglichkeiten getestet. Leider in allen 3 Fällen das gleiche, innert Sekunden ist der Web-Server tot.
Cu Carlo
nach der Beschreibung darf es auch ein String sein:
nMaxConnect exported/character | codeblock | NIL The nMaxConnect ivar determines what happens when :ActiveConnections reaches :MaxConnections. The following options are possible:
NIL - do not accept any more connections until an existing client connection is closed.
STRING - accept new connection, receive request, send string contained in nMaxConnect to client and immediately close connection.
CODEBLOCK - accept new connection, create new xbSocketThread object and execute codeblock contained in nMaxConnect within this new thread.
ich habe nun alle 3 Möglichkeiten getestet. Leider in allen 3 Fällen das gleiche, innert Sekunden ist der Web-Server tot.
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Moin,
hast Du es mal mit der Funktion, die ich oben gepostet habem, versucht?
Viele Grüße,
Martin
hast Du es mal mit der Funktion, die ich oben gepostet habem, versucht?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Hallo Martin
ja, natürlich habe ich deine Funktion getestet. Habe auch das Time-Out auf 60000 gesetzt. Es ist immer das gleiche.....
Viele Grüsse
Carlo
ja, natürlich habe ich deine Funktion getestet. Habe auch das Time-Out auf 60000 gesetzt. Es ist immer das gleiche.....
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Ok - was heißt tot? XPPERROR.LOG? XPPFATAL.LOG?
Läuft er als Dienst? Und wenn ja, wie ist die Konfiguration? Wenn weg, dann Neustart?
Viele Grüße,
Martin
Läuft er als Dienst? Und wenn ja, wie ist die Konfiguration? Wenn weg, dann Neustart?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Ich starte auf dem Testgerät einfach die exe im Verzeichnis. Also kein Dienst.
Es werden keine Error Eintrage in die Logs geschrieben.
Im Consolen Log erscheinen einfach die Aufrufe:
Thread: 17 GET /login? HTTP/1.0 0.00 Sek.
Thread: 25 GET /login? HTTP/1.0 0.00 Sek.
Thread: 19 GET /login? HTTP/1.0 0.00 Sek.
dann Ende. Keine weitere Reaktion mehr.
Tot heisst: oft kann nicht mal der Taskmanager geöffnet werden, wenn doch lässt sich der WServer.exe nicht beenden, Explorer öffnet noch, aber nur leere Seite, offene Programme reagieren nicht mehr. Es ist unterschiedlich, aber eine erneute Korrekte Funktion von WServer.exe ist nur nach neustart möglich.
Viele Grüsse
Carlo
Es werden keine Error Eintrage in die Logs geschrieben.
Im Consolen Log erscheinen einfach die Aufrufe:
Thread: 17 GET /login? HTTP/1.0 0.00 Sek.
Thread: 25 GET /login? HTTP/1.0 0.00 Sek.
Thread: 19 GET /login? HTTP/1.0 0.00 Sek.
dann Ende. Keine weitere Reaktion mehr.
Tot heisst: oft kann nicht mal der Taskmanager geöffnet werden, wenn doch lässt sich der WServer.exe nicht beenden, Explorer öffnet noch, aber nur leere Seite, offene Programme reagieren nicht mehr. Es ist unterschiedlich, aber eine erneute Korrekte Funktion von WServer.exe ist nur nach neustart möglich.
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
XPPERROR.LOG? XPPFATAL.LOG?
Viele Grüße,
Martin
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
OK - also ist Deine Anwendung noch nicht abgestürzt.
Wieviel RAM? Was für ein OS?
Viele Grüße,
Martin
Wieviel RAM? Was für ein OS?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Wenn der Taskmanager und die anderen Programme langsam reagieren, kann es an einer Endlosschleife liegen,
wenn gar nix reagiert, könnte er auf ein Netzlaufwerk warten oder das OS selbst ist z.B. im fehlerhaften TCPIP Treiber in einer Endlosschleife ...
KEIN Xbase++ Programm dürfte OHNE API Aufrufe den Rechner zum Absturz bringen.
Baue doch mal ein zeitgesteuertes ENDE ein. Ich kenne XB2.NET nicht, aber z.B. mit settimerevent() nach 60 Sekunden QUIT aufrufen, sollte doch das Programm beenden.
ODER Einen Befehl der einen Fehler verursacht. z.B. sollte &("{|| 'abd' + 3 / 'ABC' }") einen Laufzeitfehler erzwingen. Wenn du Glück hast, kannst du im dann entstehenden XppError oder Fatal was finden das hilft.
wenn gar nix reagiert, könnte er auf ein Netzlaufwerk warten oder das OS selbst ist z.B. im fehlerhaften TCPIP Treiber in einer Endlosschleife ...
KEIN Xbase++ Programm dürfte OHNE API Aufrufe den Rechner zum Absturz bringen.
Baue doch mal ein zeitgesteuertes ENDE ein. Ich kenne XB2.NET nicht, aber z.B. mit settimerevent() nach 60 Sekunden QUIT aufrufen, sollte doch das Programm beenden.
ODER Einen Befehl der einen Fehler verursacht. z.B. sollte &("{|| 'abd' + 3 / 'ABC' }") einen Laufzeitfehler erzwingen. Wenn du Glück hast, kannst du im dann entstehenden XppError oder Fatal was finden das hilft.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Danke für den Tip Herbert.
Nachdem ich die EXE und alle DLL's vom Netzlaufwerk auf c: kopiert und da starte stellt sich das Problem ganz anders dar:
Bei einem Angriff reagiert der WServer auf keine Browser-Anfrage mehr. Tastatureingaben und auch Bildschirmanzeige funktioniert noch. Mit einer Zeitgesteuerten Funktion oder dem Ende Befehl der App hängt sich das Programm ( 0 % CPU) bei QUIT auf und muss im Taskmanager beendet werden.
@Martin, es kommt drauf an wie man abgestürtzt definiert. Das (Test) System ist ein HP Z200 mit Quad Core und XP SP3 mit 3GByte RAM
Eine Fehlermeldung hab ich bekommen:
Viele Grüsse
Carlo
Nachdem ich die EXE und alle DLL's vom Netzlaufwerk auf c: kopiert und da starte stellt sich das Problem ganz anders dar:
Bei einem Angriff reagiert der WServer auf keine Browser-Anfrage mehr. Tastatureingaben und auch Bildschirmanzeige funktioniert noch. Mit einer Zeitgesteuerten Funktion oder dem Ende Befehl der App hängt sich das Programm ( 0 % CPU) bei QUIT auf und muss im Taskmanager beendet werden.
@Martin, es kommt drauf an wie man abgestürtzt definiert. Das (Test) System ist ein HP Z200 mit Quad Core und XP SP3 mit 3GByte RAM
Eine Fehlermeldung hab ich bekommen:
Code: Alles auswählen
= WEB-Server LOG ==========
Date: 20120217 15:33:01
C:\wserver\wserver.exe, Thread: 6
Windows XP 05.01 Build 02600 Service Pack 3, Web-Server: 3.2.18, Runtime: 1.90.355
ERROR BASE/5
Interne Datenstrukturen besch„digt: dllExecuteCall
Called from (B)XBHTTPTHREAD:EXECUTE(4328)
Called from XBHTTPTHREAD:RECV(3688)
Called from XBHTTPMESSAGE:RECV(5096)
Called from XBHTTPTHREAD:EXECUTE(4369)
= WEB-Server LOG ==========
Date: 20120217 15:33:02
C:\wserver\wserver.exe, Thread: 7
Windows XP 05.01 Build 02600 Service Pack 3, Web-Server: 3.2.18, Runtime: 1.90.355
ERROR BASE/5
Interne Datenstrukturen besch„digt: dllExecuteCall
Called from (B)XBHTTPTHREAD:EXECUTE(4328)
Called from XBHTTPTHREAD:RECV(3688)
Called from XBHTTPMESSAGE:RECV(5096)
Called from XBHTTPTHREAD:EXECUTE(4369)
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
ich nehme an du meintest mich ( Hubert ), da Herbert nicht geantwortet hatte ...Danke für den Tip Herbert.
Nachdem ich die EXE und alle DLL's vom Netzlaufwerk auf c: kopiert und da starte stellt sich das Problem ganz anders dar:
Grundsätzlich sollten EXE, DLL und DATEN auf dem gleichen Rechner liegen, denn der Server muss viele Clientanfragen (Netzwerkkarte) verarbeiten,
wenn er dann auch noch die EXE, DLL und DATEN (Indexe...) von einem anderen Rechner holen muss wird das nicht besser.
Läuft dein "Test" eigentlich im LAN und mit welcher Geschwindigkeit startest du die Anfragen und wie ?
Ich habe mal gelesen, dass bei einem Wettbewerb ein WebServer mit PHP auf 50.000 Anfragen pro Sekunde korrekt geantwortet hat
(Oracle Team mit eigener Datenbank und und und ...), die meisten waren bei 5000 platt.
Einen eigenen Test habe ich mit 2 Clients je 5 Threads im 1/10 Sekundentakt gegen meinen WebServer (Apache mit CGI-EXE) laufen lassen.
Abgestürzt ist er nicht, aber die Antwortzeiten wurden dann länger. Ich kam so auf 5 bis 10 Antworten in der Sekunde.
Wenn du einen aktuellen Rechner in einer Endlosschleife Anfragen starten läßt OHNE den zu bremsen, haut der zig tausende Anfragen pro Sekunde raus,
wenn ich mich recht erinnere gehen da einem normalen Desktop mit lahmer onboard Karte schnell die Ports zu.
Je Anfrage startet dann XB2.NET ja einen Thread ... das ist eher nicht typisch für eine "normale" Belastung kleiner Web-Siten.
Wenn du aber meintest, dass 2 Browser per Hand gestartet den Rechner so überlasten, dann würde ich mal direkt bei Boris fragen
was da schief läuft. Interne Datenstrukturen ... deutet auf einen API Aufruf mit falschen Parametern bzw. falschen Datentypen in den Parametern hin.
Der Parameter, der auch ein String sein darf, der sollte aber auf jeden Fall einen gültigen HTML String enthalten (die Rückgabe ist ja eine HTML Seite für den Browser).
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Hallo Hubert
entschuldige die verwechslung der Namen, ich bin nach den letzten Stunden und Tagen ein wenig durch den Wind.....
im Produktivsystem sind die Dll's und die EXE natürlich auf der lokalen Festplatte und im selben Verzeichnis. Ich habe für mich zum Arbeiten alles auf einem Server unter VMWare da ich regelmässig Snapshot's möchte ........
Der Test läuft im LAN zum Test habe ich das Freeware-Tool "Fastream Web Stress Tester 4.0" verwendet. Das sendet einfach sehr schnell eine URL und wertet das Ergebniss aus. Dropped, Hits/Sek, 2XX, 3XX usw. ....
Weisst du mit längeren Antwortzeiten lässt sich ja leben, eine Geschäftskritische Anwendung darf einfach nicht nach 2-10 Sek. oder 40-100 Anfragen/Sek. platt sein.
Als Verzweiflungstat hab ich dann den Test mit der Demo-Version von Boris wiederholt. Auf dem selben Rechner, die läuft einwandfei, das Problem lässt sich nicht generieren.
Deshalb vermute ich dass das Problem weniger bei Boris's Code liegt, sondern vielmehr an der Speicherverwaltung von xbase resp. meinen verwendeten Lib's.
Ich lade beim start des Wservers folgende:
xbasetools
see32.dll
ip-zip.dll
ot4xb.dll (1.5.17.16)
quickpdfdll0726.dll
des333.dll (Modifiziertes 3DES Crypt Programm für 8 Byte Strings, in C )
Alle diese Libs laufen auch auf dem Produktivsystem mit dem "normalen" Aufkommen von Anfragen einwandfrei.
Bei der Funktion die ich beim TZest aufrufe (192.168.100/login?) ist KEIN Aufruf einer Funktion der oben erwähnten Libs enthalten. Da sich das problem mit der Demo von Boris nicht erzeugen lässt bin ich der Meinung dass es eigentlich nur an einer der verwendeten Libs liegen muss/kann.
Was denkst du? Was könnte es sein?
Viele Grüsse
Carlo
entschuldige die verwechslung der Namen, ich bin nach den letzten Stunden und Tagen ein wenig durch den Wind.....
im Produktivsystem sind die Dll's und die EXE natürlich auf der lokalen Festplatte und im selben Verzeichnis. Ich habe für mich zum Arbeiten alles auf einem Server unter VMWare da ich regelmässig Snapshot's möchte ........
Der Test läuft im LAN zum Test habe ich das Freeware-Tool "Fastream Web Stress Tester 4.0" verwendet. Das sendet einfach sehr schnell eine URL und wertet das Ergebniss aus. Dropped, Hits/Sek, 2XX, 3XX usw. ....
Weisst du mit längeren Antwortzeiten lässt sich ja leben, eine Geschäftskritische Anwendung darf einfach nicht nach 2-10 Sek. oder 40-100 Anfragen/Sek. platt sein.
Als Verzweiflungstat hab ich dann den Test mit der Demo-Version von Boris wiederholt. Auf dem selben Rechner, die läuft einwandfei, das Problem lässt sich nicht generieren.
Deshalb vermute ich dass das Problem weniger bei Boris's Code liegt, sondern vielmehr an der Speicherverwaltung von xbase resp. meinen verwendeten Lib's.
Ich lade beim start des Wservers folgende:
xbasetools
see32.dll
ip-zip.dll
ot4xb.dll (1.5.17.16)
quickpdfdll0726.dll
des333.dll (Modifiziertes 3DES Crypt Programm für 8 Byte Strings, in C )
Alle diese Libs laufen auch auf dem Produktivsystem mit dem "normalen" Aufkommen von Anfragen einwandfrei.
Bei der Funktion die ich beim TZest aufrufe (192.168.100/login?) ist KEIN Aufruf einer Funktion der oben erwähnten Libs enthalten. Da sich das problem mit der Demo von Boris nicht erzeugen lässt bin ich der Meinung dass es eigentlich nur an einer der verwendeten Libs liegen muss/kann.
Was denkst du? Was könnte es sein?
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Moin,
und noch eine Frage von mir (abgesehen davon, dass wirklich die DLL-Dateien und das Programm und die Daten sinnvollerweise auf der selben Büchse liegen sollten):
Welche Version von XB2.Net setzt Du denn ein? Ich nehme mal an, eine ältere. In der aktuellen Version (von Dezember 2010) hat sich ein wenig was getan, was Performance anbelangt (schau mal in dem Changelog auf Boris' Webseite).
Als bei mir die knapp 6.300 Zugriffe innerhalb von 219 Sekunden erfolgten, lief er weiter. Es war zwar keine Loginseite, aber verschiedene Formularseiten, in denen willkürlich Daten eingetragen und abgesandt/gemailt wurden.
Viele Grüße,
Martin
und noch eine Frage von mir (abgesehen davon, dass wirklich die DLL-Dateien und das Programm und die Daten sinnvollerweise auf der selben Büchse liegen sollten):
Welche Version von XB2.Net setzt Du denn ein? Ich nehme mal an, eine ältere. In der aktuellen Version (von Dezember 2010) hat sich ein wenig was getan, was Performance anbelangt (schau mal in dem Changelog auf Boris' Webseite).
Als bei mir die knapp 6.300 Zugriffe innerhalb von 219 Sekunden erfolgten, lief er weiter. Es war zwar keine Loginseite, aber verschiedene Formularseiten, in denen willkürlich Daten eingetragen und abgesandt/gemailt wurden.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Gerade Deine Antwort gelesen:
Wie/wann lädst Du denn die betreffenden DLLs in den Speicher? Etwa bei jedem Aufruf Deiner Loginseite bzw. bei jedem Sessionaufbau durch einen Client?
Viele Grüße,
Martin
Wie/wann lädst Du denn die betreffenden DLLs in den Speicher? Etwa bei jedem Aufruf Deiner Loginseite bzw. bei jedem Sessionaufbau durch einen Client?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Hallo Martin
alle die Dll's lade ich in der procedure Main() in den Speicher, Ausnahme: des333 und xbaseTools die sind lediglich gelinkt.
Die Loginseite verwendet keine Funktionen einer DLL.
Als Xb2net verwende ich 3.2.17, ich habe die Sourcecode Version und kompilliere und linke alles zu einer EXE Datei.
(Damit kein Zweifel mit der oben geposteten Fehlermeldung aufkommt: ich habe die HTTP Fehlermeldungen gekürzt und deshalb die Versionsnummer auf 3.2.18 erhöht)
Viele Grüsse
Carlo
alle die Dll's lade ich in der procedure Main() in den Speicher, Ausnahme: des333 und xbaseTools die sind lediglich gelinkt.
Die Loginseite verwendet keine Funktionen einer DLL.
Code: Alles auswählen
// Load DLL-s mit Test auf korrekte Funktion
// SEE32 eMail
? "Load See32.DLL ...."
if dllload("see32.dll") = 0
? "ERROR: See32.dll not found -> Abbort "
Terminate(5)
endif
if !checkConnToSee()
? "ERROR: See32.dll WRONG Version -> Abbort "
Terminate(5)
endif
? "Load IB-Zip.DLL ...."
if dllload("ib-zip.dll") = 0
? "ERROR: IB-Zip.dll not found -> Abbort "
Terminate(5)
endif
// PDF
? "Load ot4xb.dll " + ot4xb() + " ...."
if ot4xb() < "001.005.017.016"
? "ERROR: Version from ot4xb.dll is not 1.5.17.16 -> Abbort "
Terminate(5)
endif
? "Load QuickPDFDLL0726.DLL ...."
if dllload("QuickPDFDLL0726.dll") = 0
? "ERROR: QuickPDFDLL0726.dll not found -> Abbort "
Terminate(5)
endif
i := kbPrintPDF():new():create() // DLL is OK
if !i:IsOK
? "ERROR: QuickPDFDLL0726.dll is not working -> Abbort "
Terminate(5)
endif
i:destroy()
//
? "Load des333.dll ...." // Gelink mit Lib Datei -> Test: Aufruf Set Key
i := C_DesString( 0, "AA4532ADCA11891F" ) // 0 =SetKey, 1=Encrypt, 2=Decrypt, 3=Hash
if !empty(i)
? "ERROR: " + i
Terminate(5)
endif
(Damit kein Zweifel mit der oben geposteten Fehlermeldung aufkommt: ich habe die HTTP Fehlermeldungen gekürzt und deshalb die Versionsnummer auf 3.2.18 erhöht)
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Hi,
zunächst in eigener Sache ...
nun zum Problem, es gibt STATISCH gelinkte und DYNAMISCH gelinkte DLLs.
DLLLOAD() ist dynamisch, die #PRAGMA Anweisung linkt STATISCH.
Die XbTools müssen mit so einer Anweisung Eingebunden werden:
// File: TEST.PRG
#pragma library( "XBTBASE1.LIB" )
#pragma library( "XBTBASE2.LIB" )
Hast du das gemeint ?
Nun zur QuickPDF...DLL, du schreibst DLLLOAD, wie rufst du die denn auf ?
Mit meiner HBPrintPDF-Klasse offensichtlich nicht, nimmst du die von Pablo ?
Wenn nicht, sind dort einige Funktionen enthalten die mit BAP nicht funktionieren können weil die Parameter falsch sind.
Nutzt du etwa die ActiveX Variante ? (lahm und fehlerträchtig )
Im Forum von Pablo hat vor kurzem jemand von internal Errors in Verbindung mit dieser DLL geschrieben,
ich habe mit meiner HBPrintPDF Klasse noch nie Probleme damit gehabt, wobei mit einer älteren
ot4xb ein Speicherleck aufgetreten ist (zum Testen gegen dieses erzeuge ich in sehr kurzer Zeit tausende von PDF).
Damals viel uns auch auf, dass die QuickPDF...DLL den DLLUNLOAD() gar nicht mag, also nur einmal laden und gut ist.
Du schreibst aber auch, dass bei der Routine die die Fehler verursacht (Neue Workerthread für neuen Client wenn ich es recht verstehe.)
keine der DLL Funktionen benötigt wird.
Ich denke du musst hingehen und für den Test dein Programm nacheinander um jede DLL abspecken und sehen ob das Problem verschwindet.
Oder gleich alles weg auser dem Teil der für den LOGIN zuständig ist und solange Testen bis du das Problem eingrenzen kannst.
Es ist gut möglich, dass die Startparameter bei dir (soweit anders als in der Demo) dafür verantwortlich sind, weil Boris andere erwartet ...
Wenn XB2.NET ein grundsätzliches Problem hätte, wäre das sicherlich schon aufgefallen, er hat sicherlich einige Kunden mit größeren Installationen.
zunächst in eigener Sache ...
macht nix, ich wollte nur sicher gehen dass ich auch angesprochen warentschuldige die verwechslung der Namen
nun zum Problem, es gibt STATISCH gelinkte und DYNAMISCH gelinkte DLLs.
DLLLOAD() ist dynamisch, die #PRAGMA Anweisung linkt STATISCH.
Die XbTools müssen mit so einer Anweisung Eingebunden werden:
// File: TEST.PRG
#pragma library( "XBTBASE1.LIB" )
#pragma library( "XBTBASE2.LIB" )
Hast du das gemeint ?
Nun zur QuickPDF...DLL, du schreibst DLLLOAD, wie rufst du die denn auf ?
Mit meiner HBPrintPDF-Klasse offensichtlich nicht, nimmst du die von Pablo ?
Wenn nicht, sind dort einige Funktionen enthalten die mit BAP nicht funktionieren können weil die Parameter falsch sind.
Nutzt du etwa die ActiveX Variante ? (lahm und fehlerträchtig )
Im Forum von Pablo hat vor kurzem jemand von internal Errors in Verbindung mit dieser DLL geschrieben,
ich habe mit meiner HBPrintPDF Klasse noch nie Probleme damit gehabt, wobei mit einer älteren
ot4xb ein Speicherleck aufgetreten ist (zum Testen gegen dieses erzeuge ich in sehr kurzer Zeit tausende von PDF).
Damals viel uns auch auf, dass die QuickPDF...DLL den DLLUNLOAD() gar nicht mag, also nur einmal laden und gut ist.
Du schreibst aber auch, dass bei der Routine die die Fehler verursacht (Neue Workerthread für neuen Client wenn ich es recht verstehe.)
keine der DLL Funktionen benötigt wird.
Ich denke du musst hingehen und für den Test dein Programm nacheinander um jede DLL abspecken und sehen ob das Problem verschwindet.
Oder gleich alles weg auser dem Teil der für den LOGIN zuständig ist und solange Testen bis du das Problem eingrenzen kannst.
Es ist gut möglich, dass die Startparameter bei dir (soweit anders als in der Demo) dafür verantwortlich sind, weil Boris andere erwartet ...
Wenn XB2.NET ein grundsätzliches Problem hätte, wäre das sicherlich schon aufgefallen, er hat sicherlich einige Kunden mit größeren Installationen.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
Hallo Hubert
danke für deine Antwort.
Obwohl drausen perfektes Wetter und stahlblauer Himmel MUSS ich mich weiter mit den Sorgen umplagen.
Die XbaseTools habe ich Statisch gelinkt wie du schreibst.
Für die Quickpdf verwende ich deine Klasse Version 1.20 ich habe dieser nur sämltiche nicht benötigten Methoden und das UnLoad der Quickpdf beim ::destroy() entfernt. Damit die Ausstattung und Version der Klasse klar ist und es nicht zu verwechslungen kommt habe die Namen von HB..... auf KB.... geändert.
Wegen den von dir erwähnten Speicherfehlern und vorallem um sicherzustellen dass alle benötigen Dynamischen verwendeten DLL vorhanden und die benötigte Version haben lade ich alle beim Programmstart. Gerade beim Web-Server macht sich z.B. eine fehlende QuickPDF sonst erst beim erstellen eines PDF's bemerkbar evtl. Stunden später ......
Es ist richtig: Der Workerthread für den neuen Client den ich mit dem Aufruf 192.168.0.100/Login? starte verwendet KEINE Funktionen einer Dynamisch geladenen DLL. Diese setzt mit einigen Xbasetool Funktionen und im Programm Hardcodierten Strings eine HTML-Loginseite zusammen und sendet diese zum Client.
Ich bin heute wie du schreibst hingegangen und habe die DLL's abgespeckt, leider ohne Erfolg. Nach dem entfernen der ot4xb Funktionen und Bindungen war das Verhalten besser, es brauchte ein wenig länger bis zum Crash.
Als nächstes habe ich dann meine Loginfunktion und die Tools in die XB2 Demo von Boris eingebaut.
Die Demo OHNE die Tools lief einwandfrei, mit meiner Loginfunktion crasht nun auch die DEMO. Es dürfte wohl an den Xbase-Tools liegen.
Siehst du/ihr das auch so?
Gibts da Tricks um die Tools zu verwenden oder muss ich die rausschreiben? Hat das schon jemand gemacht? Wo liegte eigentlich das Problem der Tools?
Ich weiss, es wurde hier schon öfter von der Verwendung der Tools abgeraten......
Viele Grüsse
Carlo
danke für deine Antwort.
Obwohl drausen perfektes Wetter und stahlblauer Himmel MUSS ich mich weiter mit den Sorgen umplagen.
Die XbaseTools habe ich Statisch gelinkt wie du schreibst.
Für die Quickpdf verwende ich deine Klasse Version 1.20 ich habe dieser nur sämltiche nicht benötigten Methoden und das UnLoad der Quickpdf beim ::destroy() entfernt. Damit die Ausstattung und Version der Klasse klar ist und es nicht zu verwechslungen kommt habe die Namen von HB..... auf KB.... geändert.
Wegen den von dir erwähnten Speicherfehlern und vorallem um sicherzustellen dass alle benötigen Dynamischen verwendeten DLL vorhanden und die benötigte Version haben lade ich alle beim Programmstart. Gerade beim Web-Server macht sich z.B. eine fehlende QuickPDF sonst erst beim erstellen eines PDF's bemerkbar evtl. Stunden später ......
Es ist richtig: Der Workerthread für den neuen Client den ich mit dem Aufruf 192.168.0.100/Login? starte verwendet KEINE Funktionen einer Dynamisch geladenen DLL. Diese setzt mit einigen Xbasetool Funktionen und im Programm Hardcodierten Strings eine HTML-Loginseite zusammen und sendet diese zum Client.
Ich bin heute wie du schreibst hingegangen und habe die DLL's abgespeckt, leider ohne Erfolg. Nach dem entfernen der ot4xb Funktionen und Bindungen war das Verhalten besser, es brauchte ein wenig länger bis zum Crash.
Als nächstes habe ich dann meine Loginfunktion und die Tools in die XB2 Demo von Boris eingebaut.
Die Demo OHNE die Tools lief einwandfrei, mit meiner Loginfunktion crasht nun auch die DEMO. Es dürfte wohl an den Xbase-Tools liegen.
Siehst du/ihr das auch so?
Gibts da Tricks um die Tools zu verwenden oder muss ich die rausschreiben? Hat das schon jemand gemacht? Wo liegte eigentlich das Problem der Tools?
Ich weiss, es wurde hier schon öfter von der Verwendung der Tools abgeraten......
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Moin,
welche Funktion in den Tools nutzt Du denn an der Stelle?
Viele Grüße,
Martin
welche Funktion in den Tools nutzt Du denn an der Stelle?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Die Tools wurden vor Jahren für Einzelanwendungen geschrieben und lange nicht mehr geändert (zumindest was die Version angeht).
Schon möglich, dass da ein Problem mit mehreren Threads besteht, das normalerweise nicht zu Tage tritt.
Eigentlich sollte man (fast) alles aus den Tools durch eigenen oder ot4xb Code ersetzten können.
Schon möglich, dass da ein Problem mit mehreren Threads besteht, das normalerweise nicht zu Tage tritt.
Eigentlich sollte man (fast) alles aus den Tools durch eigenen oder ot4xb Code ersetzten können.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: xb2.net Stresstest
@Martin, da nutze ich: FileStr(), NumToken(), Token() und natürlich an anderen orten viele mehr
@Hubert, hat sich schon jemand die Mühe gemacht und es public gemacht?
Viele Grüsse
Carlo
@Hubert, hat sich schon jemand die Mühe gemacht und es public gemacht?
Viele Grüsse
Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16549
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: xb2.net Stresstest
Nun, dann solltest Du was dran ändern und diese Funktionen selber schreiben.
Von den drei genannten habe ich speziell das erste in Verdacht. Überlebt Deine Anwendung den Stresstest denn noch, wenn Du diese Funktion weglässt?
Viele Grüße,
Martin
Von den drei genannten habe ich speziell das erste in Verdacht. Überlebt Deine Anwendung den Stresstest denn noch, wenn Du diese Funktion weglässt?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.