Vorbemerkung: Mit "Zope" ist im folgenden der gesamte "Application Server (i.w. AS)" , d.h. Zope an sich inklusive aller installierten Produkte gemeint. - auszert magere Dokumentation! Nicht einmal Konfigurations-Parameter sind hinreichend/aussagekraeftig beschrieben. Essentielles Know-How musz sich muehselig via Internet zusammengesucht und mit gebotener Vorsicht analysiert werden. Oftmals sind die entsprechenden Hinweise und Artikel inkl. referenzierte Software genauso veraltet, wie die offizielle Dokumentation des AS selbst. D.h. Tuning ist deshalb und aufgrund fehlender Werkzeuge und Statistiken/Reports auszerordentlich zeitaufwendig, adminstrativ ein Alptraum. Es darf bezweifelt werden, dasz einen "Standard-Admin" auch mit entsprechenden Hinweisen aus dem Internet nennenswerte Erfolge bzgl. Performance erreichen kann: - Zope skaliert in keinster Weise. Multithreading scheint wenn, dann in einem Kontext verwendet zu werden, der dem allgemeinen Verstaendnis fuer diesen Begriff widerspricht. Man kann einen Konfigurations-Parameter zserver-threads setzen und es werden auch tatsaechlich entsprechend viele leichtgewichtige Prozesse gestartet, die HTTP-Anfragen scheinen aber trotzdem nur sequentiell abgearbeitet zu werden (es wird auch bei Multiprozessor Maschinen immer nur EINE CPU genutzt, auch wenn mehrere Anfragen gleichzeitig zu bearbeiten sind). Das laeszt vermuten, das Zope zwar entsprechend viele Threads zur Annahme von Web-request startet, angenommene Anfragen dann aber doch wieder in eine Queue einreiht, die nur von einem Thread abgearbeitet wird (was natuerlich nicht sonderlich viel Sinn macht). Die Dokmentation diesbzgl. erschoepft sich in "The number of threads to use. The default is 4." Ein Experimentieren hat gezeigt, dasz mit 4 zserver-threads Zope oefters laengere Denkpausen einlegt, 25 scheinen ausreichend zu sein. - Die ZopeDB wurde in ZEO ausgelagert. Die Analyse zeigt, das der workload fuer den entsprechenden Prozess zu vernachlaessigen ist (nie ueber 0.1%), d.h. hier scheint kein Flaschenhals zu existieren. Allerdings wurde hier entsprechend Hinweisen in Web-Artikeln sofort der Parameter 'invalidation-queue-size' auf 10000 erhoeht. - Serverseitiger Cache: Der Begriff Cache taucht sicherheitshalber gar nicht erst in der Dokumentation auf (dagegen der Begriff object Live time), allerdings enthaelt die Konfiguration-Datei, die beim Anlegen einer Zope-Instanz generiert wird, ein undokumentiertes Beispiel - Parameter: "cache-size". Ein Experimentieren zeigt, dasz dieser Parameter auf den gesamten Prozess bezogen ist und nicht wie anzumehmen den RAM bezeichnet, sondern eine temporaere Datei (kein sparse file!), die zumindest unter Unix-OS unter /tmp/ angelegt wird. Da unter modernen Unix-Systemen /tmp i.d.R. ein in den Hauptspeicher gemapptes Filesystem ist, hat die festgelegte Groesze u.U. entscheidenden Einflusz auf das gesamte System: z.B. auf 1024 MB gesetzt, werden diese von Zope sofort allokiert und stehen dem System nicht mehr zur Verfuegung! Hat die entsprechende Maschione nur 1 GB Hauptspeicher, fuehrt das im Falle von Solaris dazu, dasz keine neuen Prozesse mehr gestartet werden koennen ("No more processes"), Linux faengt je nach Scheduler an, solange Prozesse zu terminieren, bis wieder genug Speicher zur Verfuegung steht, wenn ein Prozess Speicher benoetigt. Zu beachten: Zope selbst benoetigt natuerlich selber auch noch Hauptspeicher, im wdok Falle i.d.R. ca. 200 MB - die anscheinend weder mit Cache noch Object-Livetimes zu tun haben. In wieweit der Cache tatsaechlich wirksam ist, ist fraglich. Festzustellen ist, dasz die erstmalige Anfrage von DHTML-Seiten relativ lange dauert (im Falle von http://wdok2.cs.uni-magdeburg.de/wdok ca. 2.7s), anschlieszend zwar geringer (ca. 0.8s), aber immer noch weit unter den Erwartungen liegt - gegenueber statischem Content ca. Faktor 100 (siehe unten). - mehre Instanzen = bessere Performance ? Beispiel Server-Benchmark mit warmup 120s, test 120s, shutdown 30s, no thinktime; Server und Client haben jeweils 2 CPUs: a) 1 Zope-Instanz, 2 Clients simuliert elkner.q ~ > faban.local -c 2 http://wdok2.cs.uni-magdeburg.de:9080/wdok ... ops/sec: 1.208 % errors: 0.0 avg. time: 1.642 max time: 2.550 90th %: 2.20 ERROR: Missed target 90% of 1.0 b) 1 Zope-Instanz, 1 Client simuliert elkner.q ~ > faban.local -c 1 http://wdok2.cs.uni-magdeburg.de:9080/wdok ops/sec: 1.225 % errors: 0.0 avg. time: 0.815 max time: 1.617 90th %: 0.85 c) 2 Zope-Instanzen (loadbalanced by Apache), 2 Clients simuliert elkner.q ~ > faban.local -c 2 http://wdok2.cs.uni-magdeburg.de/wdok ops/sec: 2.400 % errors: 0.0 avg. time: 0.828 max time: 1.699 90th %: 0.85 d) 4 Zope-Instanzen (loadbalanced by Apache), 4 Clients simuliert (bei der schwachen Server-Performance ist unwahrscheinlich, dasz wir die Client- Performance messen - was das apache log dann ach beweist): elkner.q ~ > faban.local -c 4 http://wdok2.cs.uni-magdeburg.de/wdok ops/sec: 2.358 % errors: 0.0 avg. time: 1.671 max time: 4.916 90th %: 2.80 ERROR: Missed target 90% of 1.0 Apache Log Auszug fuer c): q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:17 +0200 + 201 28507 28158 831032 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:18 +0200 + 201 28507 28158 818599 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:18 +0200 + 201 28507 28158 816055 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:19 +0200 + 201 28507 28158 818075 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:19 +0200 + 201 28507 28158 815576 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:19 +0200 + 201 28507 28158 828590 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:20 +0200 + 201 28507 28158 823767 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:20 +0200 + 201 28507 28158 822388 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 05:56:21 +0200 + 201 28507 28158 818988 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" Apache Log Auszug fuer d): q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:44 +0200 + 201 28507 28158 1675804 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:45 +0200 + 201 28507 28158 1601636 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:45 +0200 + 201 28507 28158 1703454 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:46 +0200 + 201 28507 28158 985671 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:46 +0200 + 201 28507 28158 1497580 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:45 +0200 + 201 28507 28158 2410346 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:47 +0200 + 201 28507 28158 1506615 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:47 +0200 + 201 28507 28158 1710564 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:48 +0200 + 201 28507 28158 1466703 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" q.iws.cs.uni-magdeburg.de 2007-05-29 06:28:48 +0200 + 201 28507 28158 1317032 - 200 "GET /wdok HTTP/1.1" "-" "Java/1.6.0_01" 1. hostname 2. date of request 3. time of request 4. timezone offset 5. connection (+ .. keep a live) 6. request size 7. total bytes transferred 8. respone size in bytes (excl. headers) 9. time taken to serve the request, in µs 10. Status 11. 1st request line 12. referrer 13. User agent Wie zu sehen ist, fuehren auch mehr Zope-Instanzen als der Server CPUs hat zu keiner Verbesserung, stattdessen zu eine geringfuegigen Verschlechterung (vermutlich durch Prozess-Swapping). Ergebnis ist also, das je http://wdok2.cs.uni-magdeburg.de/wdok Anfrage ca. 0.8-0.85 Sekunden CPU-Zeit verbraucht wird. Stellt sich die Frage, ob das immer so ist. e) 2 Instanzen, 2 simulierte Clients elkner.q ~ > faban.local -c 2 http://wdok2.cs.uni-magdeburg.de/wdok/favicon.ico ops/sec: 133.300 % errors: 0.0 avg. time: 0.015 max time: 0.047 90th %: 0.05 Anscheinend nicht (bei 100 Mbps ist der Unterschied bzgl. Groesze ~27K selbst mit einem TCP-Overhead von 20% eingerechnet, relativ gering ~ 2.7 ms), was nahelegt, dasz Zope anscheinend die Antworten auf DHTML-Anfragen jedes mal komplett neu generiert oder zur Ueberpruefung der Freshness relativ viel Zeit verschwendet. - Verbesserung durch Caching moeglich? f) 2 Instanzen, 2 simulierte Clients, Apache Mem Cache (also wie e mit Caching): elkner.q ~ > faban.local -c 2 http://wdok2.cs.uni-magdeburg.de/wdok/favicon.ico ops/sec: 4810.517 % errors: 0.0 avg. time: 0.000 max time: 0.016 90th %: 0.05 Eine beachtliche Steigerung auf ~ 3600% bzw. Faktor 36. g) 2 Instanzen, 2 simulierte Clients, Apache Mem Cache (also wie c mit Cache) elkner.q ~ > faban.local -c 2 http://wdok2.cs.uni-magdeburg.de/wdok ops/sec: 2.400 % errors: 0.0 avg. time: 0.829 max time: 2.395 90th %: 0.85 Keine Verbesserung. Stellt sich die Frage, wieso nicht? Eine Pruefung der Header zeigt, dasz fuer einige Bilder wie http://wdok2.cs.uni-magdeburg.de/wdok/favicon.ico ein Header generiert wird, der Caching erlaubt. elkner.q ~ > telnet wdok2.cs.uni-magdeburg.de 9080 Trying 141.44.24.19... Connected to wdok2.iws.cs.uni-magdeburg.de. Escape character is '^]'. GET /wdok/favicon.ico HTTP/1.1 Host: wdok2.cs.uni-magdeburg.de HTTP/1.1 200 OK Server: Zope/(Zope 2.9.7-final, python 2.4.4, sunos5) ZServer/1.1 Plone/2.1.4 Date: Tue, 29 May 2007 06:03:20 GMT Last-Modified: Tue, 24 Jan 2006 12:33:59 GMT Content-Length: 1406 Content-Type: image/x-icon Accept-Ranges: bytes bzw. elkner.q ~ > telnet wdok2.cs.uni-magdeburg.de 9080 Trying 141.44.24.19... Connected to wdok2.iws.cs.uni-magdeburg.de. Escape character is '^]'. HEAD /wdok/favicon.ico HTTP/1.1 Host: wdok2.cs.uni-magdeburg.de HTTP/1.1 200 OK Server: Zope/(Zope 2.9.7-final, python 2.4.4, sunos5) ZServer/1.1 Plone/2.1.4 Date: Tue, 29 May 2007 06:04:42 GMT Content-Length: 1406 Accept-Ranges: bytes Last-Modified: Tue, 24 Jan 2006 12:33:59 GMT Etag: ts24809983.63 Content-Type: image/x-icon Also ein verwertbarer Last-Modified Header. Enttaeuschend dagegegen folgender Test: elkner.q ~ > telnet wdok2.cs.uni-magdeburg.de 9080 Trying 141.44.24.19... Connected to wdok2.iws.cs.uni-magdeburg.de. Escape character is '^]'. GET /wdok HTTP/1.1 Host: wdok2.cs.uni-magdeburg.de HTTP/1.1 200 OK Server: Zope/(Zope 2.9.7-final, python 2.4.4, sunos5) ZServer/1.1 Plone/2.1.4 Date: Tue, 29 May 2007 06:06:24 GMT Content-Length: 28040 Expires: Sat, 1 Jan 2000 00:00:00 GMT Content-Type: text/html;charset=utf-8 Content-Language: de Expired. Hmmm, ein cleverer Cache kann jetzt sagen, wird erstmal zwischengespeichert und beim naechsten Mal nachgefragt, ob sich der Inhalt geaendert hat (was laut Spezifikation erlaubt ist): elkner.q ~ > telnet wdok2.cs.uni-magdeburg.de 9080 Trying 141.44.24.19... Connected to wdok2.iws.cs.uni-magdeburg.de. Escape character is '^]'. HEAD /wdok HTTP/1.1 Host: wdok2.cs.uni-magdeburg.de HTTP/1.1 200 OK Server: Zope/(Zope 2.9.7-final, python 2.4.4, sunos5) ZServer/1.1 Plone/2.1.4 Date: Tue, 29 May 2007 06:09:47 GMT Content-Length: 1963 Content-Location: http://wdok2.cs.uni-magdeburg.de/wdok/ Accept-Ranges: none Last-Modified: Sun, 13 May 2007 10:21:45 GMT Connection: close Etag: ts79051704.09 Date: Tue, 29 May 2007 06:09:47 GMT Content-Type: text/structured Die Content-Length stimmt anscheinend nicht ueberein. Man koennte ja nochmal bei der Content-Location (dem redirect) nachfragen: elkner.q ~ > telnet wdok2.cs.uni-magdeburg.de 9080 Trying 141.44.24.19... Connected to wdok2.iws.cs.uni-magdeburg.de. Escape character is '^]'. HEAD /wdok/ HTTP/1.1 Host: wdok2.cs.uni-magdeburg.de HTTP/1.1 200 OK Server: Zope/(Zope 2.9.7-final, python 2.4.4, sunos5) ZServer/1.1 Plone/2.1.4 Date: Tue, 29 May 2007 06:13:00 GMT Content-Length: 1963 Accept-Ranges: none Last-Modified: Sun, 13 May 2007 10:21:45 GMT Connection: close Etag: ts79051704.09 Date: Tue, 29 May 2007 06:13:00 GMT Content-Type: text/structured Wieder eine Fehlanzeige. Sprich, die Caches, die die Antwort nicht schon aufgrund des Expires-Header wegwerfen, tun dies spaetestens bei der Nachpruefung. Ergo, Performance-Verbesserung durch Caching ist nur marginal moeglich (clients tun dies sowieso, wenn ein korrekter Last-Modified bzw. Expires-Header generiert wird). Anyway, Caching fuer personalisierte Seiten (d.h. authorisierte Anfragen) werden i.d.R. eh nicht zwischengespeichert. Bleibt zu ueberpruefen, ob sich der AS bzgl. dieser Anfragen aehnlich verhaelt. - Performance fuer personalisierte Seiten (aka authorisierte Sessions): Inzwischen haben wir gelernt, dasz das Logfile von Apache aussagekraeftig genug ist - deshalb waehlen wir hier eine etwas schonendere Variante 3x nacheinander: elkner.q ~ > wget --no-cookies --header "Cookie: __ac=************************" http://wdok2.cs.uni-magdeburg.de/wdok --08:26:13-- http://wdok2.cs.uni-magdeburg.de/wdok => `wdok.3' Resolving wdok2.cs.uni-magdeburg.de... 141.44.24.19 Connecting to wdok2.cs.uni-magdeburg.de|141.44.24.19|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 51,389 (50K) [text/html] 100%[====================================>] 51,389 --.--K/s 08:26:15 (175.87 MB/s) - `wdok.3' saved [51389/51389] Apache Log: qws.cs.uni-magdeburg.de 2007-05-29 08:26:37 +0200 + 156 51812 51389 2064945 - 200 "GET /wdok HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:26:41 +0200 + 156 51812 51389 2042880 - 200 "GET /wdok HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:26:44 +0200 + 156 51812 51389 2066738 - 200 "GET /wdok HTTP/1.0" "-" "Wget/1.10.1" Gegenueber test c braucht hier der Server ca. 2.5x mehr Zeit - hat aber auch ca. 1.8 x mehr Inhalt. Ist das bei anderen Seiten ebenfalls so? Wir probieren http://wdok2.cs.uni-magdeburg.de/wdok/forschung (3x ohne und 3x mit Session): q.iws.cs.uni-magdeburg.de 2007-05-29 08:31:33 +0200 + 127 38738 38388 1013815 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:31:37 +0200 + 127 38738 38388 1007164 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:31:45 +0200 + 127 38738 38388 908120 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:31:56 +0200 + 166 82181 81758 2590753 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:32:00 +0200 + 166 82181 81758 2590584 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:32:06 +0200 + 166 82181 81758 2471624 - 200 "GET /wdok/forschung HTTP/1.0" "-" "Wget/1.10.1" Ja. Und mit http://wdok2.cs.uni-magdeburg.de/wdok/publikationen: q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:24 +0200 + 131 75034 74684 1982644 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:27 +0200 + 131 75034 74684 1966053 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:30 +0200 + 131 75034 74684 1955427 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:45 +0200 + 170 98087 97664 5179543 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:52 +0200 + 170 98087 97664 4817272 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" q.iws.cs.uni-magdeburg.de 2007-05-29 08:36:58 +0200 + 170 98087 97664 4656569 - 200 "GET /wdok/publikationen HTTP/1.0" "-" "Wget/1.10.1" Will man fuer personalisierte Seiten also eine akzeptable Antwortzeit erreichen, kommt man angesichts des miserablen Multithreadings im AS nicht um schnelle CPU's (hoher Takt) herum. Was ist nun schnell genug? Erfahrungsgemaesz gehoeren nur sehr wenige Flieszkommaoperationen zum working set von Webapplikationen/-server. I.d.R. sind AS/WS mit reiner byteschubserei/Integeroperationen beschaeftigt. Deshalb kann angenommen werden, soweit die Peripherie keinen Engpass darstellt und ein Prozess nicht uebermaeszig durch Context/ Prozess-Switching unterbrochen wird, dasz PI x Daumen mit einer Halbierung der Servicetime fuer eine Anfrage bei einer Verdoppelung des CPU-Takts gerechnet werden kann. Da eine Verdoppelung des CPU-Taktes i.d.R. auch mit Verbesserungen bzgl. Speicherverwaltung (MMUs, Hyperthreading, Takt), ist bei CPU-Takt-Verdoppelung wahrscheinlich, dasz sich die Servicetime mehr als nur halbiert (sicher nicht drastisch, aber messbar). Leider kann das gesagte aufgrund fehlender Hardware derzeit nicht verifiziert werden, sollte aber als Planungsgroesze hinreichend genau sein. Der Rest ist wieder nur Rechnerei: Geht man von einer stichprobenartig ermittelten durchschnittl. servicetime von ~ 3 Sekunden/Request fuer authentifizierte Nutzer bei einer 1503 MHz CPU aus, braucht man fuer eine durchschnittl. Servicetime mit <= 1 Sekunde eine CPU-Taktung von 3 GHz. Fuer das erstmalige Fetching einer Seite (abgelaufene Livetime eines Object ? ; per default 5min?) wurde festgestellt, dasz die Beantwortung der Anfrage ungefaehr doppelt so lange wie die nachfolgenden benoetigt. Damit kann davon ausgegangen werden, das bzgl. einer Anfrage und garantierter Servicetime von <= 1s eine 6 GHz Taktung noetig ist. Treffen mehrere Anfragen gleichzeitig oder ueberlappend ein, ist je nach Mix eine entsprechende Multiprozessormaschine notwendig. Session: Last but not least, ein Fakt bisher gar nicht beruecksichtigt: Sessions oder im J2EE-Jargon: stateful session beans (heutzutage speichert niemand mehr session-infos/objects in Cookies). Bisher ist der wdok loadbalancer des Apache so eingestellt, dassz er die Last unabhaengig vom Inhalt der Abfrage auf die zur Verfuegung stehenden ZEO-Clients verteilt. Da verschiedene Zope-Instanzen von einander nichts wissen, koennen diese soimit auch keinen Session-behafteten Objekte austauschen/ replizieren, woraus sich ergibt, dasz sowie eine Session etabliert wurde, saemtliche Anfragen des jeweiligen Clients immer wieder zu ein und derselben Zope-Instanze weitergeleitet werden. Technisch ist das weniger ein Problem, allerdings kann das zur Folge haben, dasz in unguenstigen Faellen sehr viele Anfragen auf ein und dieselbe Instanz/CPU weitergeleitet werden muessen, sprich selbige ueberlastet ist, waehrend die andere Instanzen/CPUs "Daeumchen" drehen. Daraus folgt unmittelbar, dasz wenn Sessions ins Spiel kommen, auch 6 GHz CPUs nicht ausreichen, um eine vorgegebene Servicetime von <= 1s/Abfrage garantieren zu koennen. Fazit: Ergo, ohne grundlegende Ueberarbeitung der Zope/AS-Software (hauptsaechlich besseres Multithreading) sind auch mit modernster Technik keine bzw. nur inakzeptable Servicetimes garantierbar bzw. etwas publizistischer ausgedrueckt: ZopeAS ist ein Fasz ohne Boden!