Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Sonntag, 14 März 2021 | Blog: 1 | No: 46658
Ich schreibe ja die meiste meiner Software, um zu lernen, wie Dinge funktionieren, und was man da beachten muss und falschmachen kann. Bei gatling war das genau so. Ich setze den zwar produktiv ein, aber dafür war der eigentlich nie gedacht. Das sieht man auch am Code, der vergleichsmäßig furchtbar ist.
Das liegt nicht daran, dass die Thematik so furchtbar komplex ist, sondern das liegt daran, dass ich die Komplexität der Thematik vorher nicht kannte, und daher architekturelle Entscheidungen getroffen habe, die rückblickend nicht schlau waren.
Das kann man jetzt als Scheitern sehen, aber ich sehe es als Gewinn. Genau deshalb habe ich das ja gemacht, damit ich lerne, was die Probleme sind, und worauf man achten muss.
Das "Protocol Error"-Problem, das ihr heute sehen konntet, lag an einer dieser architekturellen Entscheidungen. gatling war ja auf hohe Skalierbarkeit ausgelegt, kann theoretisch zehntausende von Verbindungen offen haben. Wenn ich da einen neuen Prozess für ein CGI erzeuge, dann muss irgendjemand (entweder ich von Hand oder der Kernel über close-on-exec-Flags) die ganzen Sockets zumachen, sonst erbt das CGI die. Daher hatte ich damals entschieden, dass gatling ganz am Anfang einen Prozess aufmacht, der noch keinen Ballast geerbt hat, und wenn ein neuer Prozess gebraucht wird, dann erzeugt dieser jung gebliebene Prozess den. Dem schickt der Haupt-Gatling dann einen Request, und der macht dann den neuen CGI-Prozess auf und schiebt einen Deskriptor zu diesem neuen CGI-Prozess zurück zum Hauptprogramm.
Die Tage hat mir jemand einen Bug gemeldet. Wenn man HEAD auf ein CGI macht, kommt die falsche Content-Length zurück. Die Content-Length spielt bei HEAD an sich keine Rolle, denn der Content kommt ja nicht. Insofern sagt die Spec auch, Content-Length ist bei HEAD optional. gatling ging jetzt nicht davon aus, dass jemand HEAD auf ein CGI macht, weil das ja eine sinnlose Operation ist (wie HEAD überhaupt ziemlich sinnlos ist, seit es If-Modified-Since gibt). Es war ein bisschen Code dafür da, aber das war in keiner Testsuite und es hat bis jetzt auch nie jemand gemacht glaube ich.
Der Fix dafür hat jetzt subtil die Logik gebrochen, die in dem 2. Prozess den CGI-Dateinamen zu einem Request raussucht. Daher kam da "Protocol error".
Langfristig ist der Plan, gatling nochmal neu zu machen, nachdem ich jetzt gelernt habe, was die Probleme sind.
Neue Features, die ich initial für nicht so wichtig hielt, wären multithreading und Offenhalten und Cachen von Dateien.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Sonntag, 14 März 2021 | Blog: 1 | No: 46658
Posting #46658
Das liegt nicht daran, dass die Thematik so furchtbar komplex ist, sondern das liegt daran, dass ich die Komplexität der Thematik vorher nicht kannte, und daher architekturelle Entscheidungen getroffen habe, die rückblickend nicht schlau waren.
Das kann man jetzt als Scheitern sehen, aber ich sehe es als Gewinn. Genau deshalb habe ich das ja gemacht, damit ich lerne, was die Probleme sind, und worauf man achten muss.
Das "Protocol Error"-Problem, das ihr heute sehen konntet, lag an einer dieser architekturellen Entscheidungen. gatling war ja auf hohe Skalierbarkeit ausgelegt, kann theoretisch zehntausende von Verbindungen offen haben. Wenn ich da einen neuen Prozess für ein CGI erzeuge, dann muss irgendjemand (entweder ich von Hand oder der Kernel über close-on-exec-Flags) die ganzen Sockets zumachen, sonst erbt das CGI die. Daher hatte ich damals entschieden, dass gatling ganz am Anfang einen Prozess aufmacht, der noch keinen Ballast geerbt hat, und wenn ein neuer Prozess gebraucht wird, dann erzeugt dieser jung gebliebene Prozess den. Dem schickt der Haupt-Gatling dann einen Request, und der macht dann den neuen CGI-Prozess auf und schiebt einen Deskriptor zu diesem neuen CGI-Prozess zurück zum Hauptprogramm.
Die Tage hat mir jemand einen Bug gemeldet. Wenn man HEAD auf ein CGI macht, kommt die falsche Content-Length zurück. Die Content-Length spielt bei HEAD an sich keine Rolle, denn der Content kommt ja nicht. Insofern sagt die Spec auch, Content-Length ist bei HEAD optional. gatling ging jetzt nicht davon aus, dass jemand HEAD auf ein CGI macht, weil das ja eine sinnlose Operation ist (wie HEAD überhaupt ziemlich sinnlos ist, seit es If-Modified-Since gibt). Es war ein bisschen Code dafür da, aber das war in keiner Testsuite und es hat bis jetzt auch nie jemand gemacht glaube ich.
Der Fix dafür hat jetzt subtil die Logik gebrochen, die in dem 2. Prozess den CGI-Dateinamen zu einem Request raussucht. Daher kam da "Protocol error".
Langfristig ist der Plan, gatling nochmal neu zu machen, nachdem ich jetzt gelernt habe, was die Probleme sind.
Neue Features, die ich initial für nicht so wichtig hielt, wären multithreading und Offenhalten und Cachen von Dateien.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
