[phpBB Debug] PHP Warning: in file [ROOT]/ext/tas2580/privacyprotection/cron/task/anonymize_ip.php on line 83: A non-numeric value encountered
Inoffizielles deutsches Xbase-Forum • xb2.net Stresstest
Seite 1 von 2

xb2.net Stresstest

Verfasst: Do, 16. Feb 2012 23:22
von ramses
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 4:26
von Martin Altmann
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 :roll:
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 7:53
von ramses
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 8:21
von Martin Altmann
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:

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()
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 10:57
von ramses
Hallo Martin

nach der Beschreibung darf es auch ein String sein:

:onMaxConnect exported/character | codeblock | NIL The :onMaxConnect 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 :onMaxConnect to client and immediately close connection.
CODEBLOCK - accept new connection, create new xbSocketThread object and execute codeblock contained in :onMaxConnect 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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 11:06
von Martin Altmann
Moin,
hast Du es mal mit der Funktion, die ich oben gepostet habem, versucht?

Viele Grüße,
Martin

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 11:47
von ramses
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 11:49
von Martin Altmann
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 12:12
von ramses
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 12:30
von Martin Altmann
XPPERROR.LOG? XPPFATAL.LOG?

Viele Grüße,
Martin

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 12:33
von ramses
Hallo Martin

beide Dateien sind nicht vorhanden.

Viele Grüsse

Carlo

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 12:38
von Martin Altmann
OK - also ist Deine Anwendung noch nicht abgestürzt.
Wieviel RAM? Was für ein OS?

Viele Grüße,
Martin

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 13:05
von brandelh
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.

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 15:08
von ramses
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:

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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 16:43
von brandelh
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:
ich nehme an du meintest mich ( Hubert ;-) ), da Herbert nicht geantwortet hatte ...

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).

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 21:40
von ramses
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 21:56
von Martin Altmann
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 21:58
von Martin Altmann
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

Re: xb2.net Stresstest

Verfasst: Fr, 17. Feb 2012 22:51
von ramses
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.

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
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

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 10:32
von brandelh
Hi,

zunächst in eigener Sache 8) ...
entschuldige die verwechslung der Namen
macht nix, ich wollte nur sicher gehen dass ich auch angesprochen war :D

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 :badgrin: )
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.

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 13:38
von ramses
Hallo Hubert

danke für deine Antwort.
Obwohl drausen perfektes Wetter und stahlblauer Himmel MUSS ich mich weiter mit den Sorgen umplagen. :cry:
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

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 14:02
von Martin Altmann
Moin,
welche Funktion in den Tools nutzt Du denn an der Stelle?

Viele Grüße,
Martin

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 14:29
von brandelh
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.

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 14:45
von ramses
@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

Re: xb2.net Stresstest

Verfasst: Sa, 18. Feb 2012 15:05
von Martin Altmann
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