In the ZOPE Documentation there are several tuning features for ZOPE ODB and ZSERVER. I was wondering about current Zope Performance and where it is heading. In certain areas we are looking at JAVA Servlets for performance reasons, where ZOPE falls short of expectations. Here are some questions that we have come up with in regards to Zope Performance in an Enterprise Production Environment. CURRENT ZOPE PERFORMANCE: Q: Is there a performance improvement in raising the number of threads on the ZOPE ODB? Q: Does increasing the # of threads cause any problems? With Threaded DA's? With the ODB? Q: Is ZOPE performance with threads hardware restrictive? (ie. More threads on a strong box=good, Default on a Strong box = bottleneck, More on a weak box=worse performance) Q: How does ZEO improve ZOPE performance? Q: Is there hidden ZEN out there on Performance Tuning Zope for a production environment? FUTURE ZOPE PERFORMANCE/DEVELOPMENT Q: Is ZOPE limited/Dependent on the associated Python Performance? Can ZOPE run on separate instances of Python(Multiple JVM's in the JAVA World)? Q: Is there hidden ZEN out there on Performance Tuning Zope for a Heavy Production Environment(besides ZEO)? (HPE = up to 150 Requests/sec) How does one scale Zope to Java Sevlet performance levels (compiled in-memory performance)? Sevlets = 200+ Requests per second (once invoked and in-memory) Can you run Zope as a precompiled application(not-interpreted python)? Q: Is there a roadmap in the Zope Development to get to these performance levels? What are the options? Thanks, Theodore E. Patrick Ishophere.com
On 11/10/99 10:03 AM, Theodore Patrick at tpatrick@IndigoNetworks.com wrote:
In the ZOPE Documentation there are several tuning features for ZOPE ODB and ZSERVER. I was wondering about current Zope Performance and where it is heading. In certain areas we are looking at JAVA Servlets for performance reasons, where ZOPE falls short of expectations. Here are some questions that we have come up with in regards to Zope Performance in an Enterprise Production Environment.
CURRENT ZOPE PERFORMANCE:
Q: Is there a performance improvement in raising the number of threads on the ZOPE ODB?
Sometimes. :-) How's that for definate? Basically, as you identify below, it's mostly beneficial when you're blocked because of the global-interpreter lock. DAs are a great place for this.
Q: Does increasing the # of threads cause any problems? With Threaded DA's? With the ODB?
Nope, but after a certain point, your performance will go down. This is always true.
Q: Is ZOPE performance with threads hardware restrictive? (ie. More threads on a strong box=good, Default on a Strong box = bottleneck, More on a weak box=worse performance)
Well, we've seen some odd issues with multi-threading on Linux kernels that don't show up on FreeBSD, but we've not really dug into this a lot yet.
Q: How does ZEO improve ZOPE performance?
By replicating the object database, so it increases read performance, decreasing write performance slightly in exchange.
Q: Is there hidden ZEN out there on Performance Tuning Zope for a production environment?
Nope, though there should be perhaps. There's just 10,000 variables, so to be useful, you'd have to dig into the core concepts more.
Q: Is ZOPE limited/Dependent on the associated Python Performance? Can ZOPE run on separate instances of Python(Multiple JVM's in the JAVA World)?
Of course, though it can be somewhat increased by moving to C, or more importantly, changing algorithms. A rule of thumb is that "tweeks" never get more than 2-3x increase, whereas algorithm changes can cause orders of magnitude performance benefits. As for multiple instances, that would be ZEO (there's LOTS of object replication issues).
Q: Is there hidden ZEN out there on Performance Tuning Zope for a Heavy Production Environment(besides ZEO)? (HPE = up to 150 Requests/sec)
Well, without knowing ANYTHING about your "heavy production environment", not a little bit. It's dependent on applications.
Can you run Zope as a precompiled application(not-interpreted python)?
Nope, Python is interpreted by its nature, you can't get a lot of things working otherwise. I'd hazard Acquisition would be 100x harder.
Q: Is there a roadmap in the Zope Development to get to these performance levels? What are the options?
Yes, it's driven by customer requirements. People pay us to deliver results, and we focus on that. We don't have the resources to focus right now on "general" things unless they're driven by customer issues. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Theodore Patrick wrote:
In the ZOPE Documentation there are several tuning features for ZOPE ODB and ZSERVER. I was wondering about current Zope Performance and where it is heading. In certain areas we are looking at JAVA Servlets for performance
I'll be interested to hear the results of this. The knock on servlets is that performance isn't that great, but I haven't seen any specific numbers.
reasons, where ZOPE falls short of expectations. Here are some questions
I'd also like to hear some existing numbers (hit rates, response times, kind of operations that are slow) that frame the discussion -- that is, what are you seeing that makes you conclude Zope isn't performing up to expectations?
that we have come up with in regards to Zope Performance in an Enterprise Production Environment.
CURRENT ZOPE PERFORMANCE:
Q: Is there a performance improvement in raising the number of threads on the ZOPE ODB?
Chris answered this pretty well. If you have operations that last longer than a tenth of a second (they compute a lot of stuff, its a management operation, its a request to a relational database), then yes.
Q: Does increasing the # of threads cause any problems? With Threaded DA's? With the ODB?
Definately a Python threading voodoo area. Increasing the number of application threads can certainly increase memory required, as each thread has its own "cache" of objects.
Q: Is ZOPE performance with threads hardware restrictive? (ie. More threads on a strong box=good, Default on a Strong box = bottleneck, More on a weak box=worse performance)
Dunno.
Q: How does ZEO improve ZOPE performance?
You get to add processors, boxes, and networks to your object system. On multiprocessor machines, you get around Python's non-wonderful threading by spreading processes across processors rather than threads across processors. Finally, processes that are performing poorly (long compute, hung, etc.) don't get requests sent to them.
FUTURE ZOPE PERFORMANCE/DEVELOPMENT
Q: Is ZOPE limited/Dependent on the associated Python Performance? Can ZOPE run on separate instances of Python(Multiple JVM's in the JAVA World)?
Zope is written largely in Python, so obviously it is tied to the performance of Python. If there is evidence that Python itself, or Zope itself, is the bottleneck, convert something to C.
Q: Is there hidden ZEN out there on Performance Tuning Zope for a Heavy Production Environment(besides ZEO)? (HPE = up to 150 Requests/sec)
How does one scale Zope to Java Sevlet performance levels (compiled in-memory performance)? Sevlets = 200+ Requests per second (once invoked and in-memory)
I have a hard time believing that servlets can retrieve data from storage and render a complicated page 200 times per second. You've obviously run the test, though. Can you describe the test scenario, then give the numbers for Zope performing the equivalent test? Alternatively, about the fastest Zope test I can think of is to go to a non-existant page in the top folder. Try that and let us know what is Zope's hit rate on the machine you are using.
Can you run Zope as a precompiled application(not-interpreted python)?
Q: Is there a roadmap in the Zope Development to get to these performance levels? What are the options?
If I had to make a guess, right now the priorities are: get the portal toolkit story straight, usability, then scalability. It has been a long time since (over a year) since we've studied how to tune Zope's performance. Especially since Z2 has landed, there should be a number of places to look for incremental improvements. You, however, are looking for something like a three-fold performance improvement. Tinkering won't get us there. Instead, something like the caching proposals discussed on the list several months back are probably the most the radical proposal on the table. You can certainly do your argument, and the whole issue of performance, a great service by proposing a test suite, a hardware platform, and what the numbers should look like. Until then, it is hard to know what we are discussing. --Paul
Paul Everitt wrote:
You, however, are looking for something like a three-fold performance improvement. Tinkering won't get us there. Instead, something like the caching proposals discussed on the list several months back are probably the most the radical proposal on the table.
Well, I would like some benchmarks on my ZCache product in some real sites, like Technocrat or www.zope.org, but it should speed up access a lot. And it's really easy to add. Anyone willing to give it a try? -- Itamar - itamars@ibm.net ---------------------------o----------------------------------------------o Perl/Gimp Greeting Cards | Trust? Ha! The US dollar is backed by ICBMs! | http://www.sealingwax.com | --Anonymous Coward, Slashdot |
Paul Everitt wrote:
Q: Is there hidden ZEN out there on Performance Tuning Zope for a Heavy Production Environment(besides ZEO)? (HPE = up to 150 Requests/sec)
How does one scale Zope to Java Sevlet performance levels (compiled in-memory performance)? Sevlets = 200+ Requests per second (once invoked and in-memory)
I have a hard time believing that servlets can retrieve data from storage and render a complicated page 200 times per second.
I have just tested an out-of box apache 1.3.9 with a page of ~18kb and an out-of-box zope 2.0.1 server with 1.2 kb zope opening page on an IBM NetFinity 5500 M20, dual Pentium III/500MHz with the following results: Changing the number of threads did not change a thing and top showed only 3-4 threads actually getting work. The cpu usage was ~= 1.0. Are the numbers terribly wrong ? [hannu@www hannu]$ zeus_bench localhost /estno/ -t 30 -p 80 -c 10 --- Server: Apache/1.3.9 Doucment Length: 18327 Concurency Level: 10 Time taken for tests: 30.011 seconds Complete requests: 12390 Failed requests: 0 Bytes transfered: 230559372 HTML transfered: 227126511 Requests per seconds: 412.85 Transfer rate: 7682.50 kb/s Connnection Times (ms) min avg max Connect: 0 3 3034 Total: 4 22 3055 --- [hannu@www hannu]$ zeus_bench localhost / -t 30 -p 8080 -c 10 --- Server: Zope/(unreleased Doucment Length: 1210 Concurency Level: 10 Time taken for tests: 30.025 seconds Complete requests: 1047 Failed requests: 0 Bytes transfered: 1447288 HTML transfered: 1268080 Requests per seconds: 34.87 Transfer rate: 48.20 kb/s Connnection Times (ms) min avg max Connect: 0 0 1 Total: 120 227 369 ---
On 11/11/99 2:36 PM, Hannu Krosing at hannu@tm.ee wrote:
I have just tested an out-of box apache 1.3.9 with a page of ~18kb and an out-of-box zope 2.0.1 server with 1.2 kb zope opening page on an IBM NetFinity 5500 M20, dual Pentium III/500MHz with the following results:
This looks like regular Apache, not serverlets, not Java. Was this backed by a Java interpreter? Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Regardless, 30 TPS is a terrible score. However, I suspect there is something going on here that is skewing the numbers on the Zope test. I have been in webserver development for many years, most of them on the cutting edge, and I have spent a LOT of time benchmarking various servers and proxies. I haven't benchmarked Zope at all, but Zope feels much faster than a 30 TPS webserver. Generally, on a server that slow, requesting a single object from a browser will not exactly feel quick, and Zope tends to feel almost instantaneous. This is a very subjective analysis, but I have learned to trust my feelings on this one. I have never looked at the Medusa code at all, but I suspect that there is something about the zeustest that causes the Zope server to be unhappy. It could be that Medusa does not handle concurrency well at all, which would be a very bad thing. I assume the test you are using is similar to the apache bench. If so, you should definitely see more than 4 threads in use at once on the server, since there should be 10 connections open at all times (assuming the -c option is comcurrency, although -t could be threadcount) . It could imply something fairly ugly going on in the webserver's scheduler. I would suggest that the surest way to see where you are seeing the delay is to hack some stats into the test you are using. Some very interesting numbers to collect are time from last byte out to first byte in, time from first byte in to last byte of headers in, time for body to transfer, and of course, overall transaction length. Take averages over 5 or 10 second intervals and see what they look like. I have seen latencies occur at all three locations, almost always do to funky interactions between TCP and code in the server. --sam Christopher Petrilli wrote:
On 11/11/99 2:36 PM, Hannu Krosing at hannu@tm.ee wrote:
I have just tested an out-of box apache 1.3.9 with a page of ~18kb and an out-of-box zope 2.0.1 server with 1.2 kb zope opening page on an IBM NetFinity 5500 M20, dual Pentium III/500MHz with the following results:
This looks like regular Apache, not serverlets, not Java. Was this backed by a Java interpreter?
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope No cross posts or HTML encoding! (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Sam Gendler wrote:
Regardless, 30 TPS is a terrible score. However, I suspect there is something going on here that is skewing the numbers on the Zope test. I have been in webserver development for many years, most of them on the cutting edge, and I have spent a LOT of time benchmarking various servers and proxies. I haven't benchmarked Zope at all, but Zope feels much faster than a 30 TPS webserver. Generally, on a server that slow, requesting a single object from a browser will not exactly feel quick, and Zope tends to feel almost instantaneous.
Zope usually has very good latency but much worse throughput (due to very high level of dynamism)
This is a very subjective analysis, but I have learned to trust my feelings on this one. I have never looked at the Medusa code at all, but I suspect that there is something about the zeustest that causes the Zope server to be unhappy. It could be that Medusa does not handle concurrency well at all, which would be a very bad thing. I assume the test you are using is similar to the apache bench. If so, you should definitely see more than 4 threads in use at once on the server, since there should be 10 connections open at all times (assuming the -c option is comcurrency, although -t could be threadcount) .
This time I changed the concurrency (-c , -t is timelimit) on zeus_benc side -c 1 - 41 TPS -c 2 and up ~ 35 TPS and max 4 threads showing as being used in top. the top lines of top looked like this on -t 30 -c 100 10:36pm up 11 days, 22:56, 3 users, load average: 0.60, 0.41, 0.24 93 processes: 91 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 32.5% user, 32.7% system, 0.0% nice, 34.6% idle Mem: 1036316K av, 262628K used, 773688K free, 75440K shrd, 108888K buff Swap: 0K av, 0K used, 0K free 92476K cached 14639 zope2 12 0 8044 8044 1748 R 0 25.3 0.7 0:36 python 14643 zope2 13 0 8044 8044 1748 R 0 18.7 0.7 0:20 python 14644 zope2 12 0 8044 8044 1748 S 0 16.1 0.7 0:16 python 24229 hannu 2 0 476 476 328 S 0 3.0 0.0 0:00 zeus_bench 16688 root 4 0 1056 1056 844 R 0 1.3 0.1 0:21 top 14647 zope2 1 0 8044 8044 1748 S 0 0.7 0.7 0:09 python 1 root 0 0 472 472 408 S 0 0.0 0.0 0:04 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:01 kflushd BTW, I don't know if the load average of 1.0 means that one or two processors are running at full throttle. Does anyone know if adding two more processors would change these numbers ? ----------------- Hannu
This time I changed the concurrency (-c , -t is timelimit) on zeus_benc side -c 1 - 41 TPS -c 2 and up ~ 35 TPS and max 4 threads showing as being used in top.
the top lines of top looked like this on -t 30 -c 100
If even going to 2 threads on the client side causes a 20% degradation in performance, there has got to be something wrong with the threading model in the server. I will look at it as I get a chance, but I am in the midst of building a huge application with a deadline of Dec 20, so I will not have much time until then. However, if someone could do the timings that I requested, I can certainly help diagnose the problem. the fact that it gets such poor performance with even a single thread is quite bothersome. A perl script should be able to do better than that, quite frankly. It tends to suggest something systemic, like a lookup that is taking to long, or one of the ugly TCP side effects that I mentioned. A couple of things to look for (things that have bitten apache and others over the years)... Make sure you send the largest possible packets. If the client receives a 'small packet' (I can't remember the criteria, although 1/2 maximum segment size rings a bell), it will delay the ACK of that packet for 200ms while it waits for data to go back the other way. Since this is a web client, there is no data to go back the other way, so there is a 200ms delay after every small packet from the server. On most systems, you can set TCP_NODELAY to off, but linux doesn't support this, last time I checked. Many servers started out sending each HTTP header as a different packet, or else they send the headers as one packet and the body as another. In either case, you will usually trigger this behaviour. Simply buffering the output is enough to prevent the problem. If you are seeing latency between starting to receive the headers and finishing the headers, or between receiving the headers and starting to receive the body, this is probably the culprit. Latency before receiving anything could be just about anywhere, however. The fact that going to 2 client threads impacts performance really points to the threads scheduler itself. It would almost appear that the server is trying to handle all requests with the same thread. Someone may want to look and make sure that the server is doing what it is supposed to be doing. Just my $.02 --sam
Sam Gendler wrote:
This time I changed the concurrency (-c , -t is timelimit) on zeus_benc side -c 1 - 41 TPS -c 2 and up ~ 35 TPS and max 4 threads showing as being used in top.
the top lines of top looked like this on -t 30 -c 100
If even going to 2 threads on the client side causes a 20% degradation in performance, there has got to be something wrong with the threading model in the server. I will look at it as I get a chance, but I am in the midst of building a huge application with a deadline of Dec 20, so I will not have much time until then. However, if someone could do the timings that I requested, I can certainly help diagnose the problem. the fact that it gets such poor performance with even a single thread is quite bothersome. A perl script should be able to do better than that, quite frankly.
I just tested a small python cgi scriptat concurrency level 10: a cgi script that printed the Content-type and "Hi There!" got ~30 TPS at a more complicated one that connected to Database and retrieved the 20 rows of 700 ran at about ~10 TPS Just importing DocumentTemplate got it down to 7-8 TPS Compiling a simple DTML made it go 6.5 TPS using the DTML it to display the results --> 6.1 TPS ------------------- Hannu
I just tested a small python cgi scriptat concurrency level 10:
a cgi script that printed the Content-type and "Hi There!" got ~30 TPS at
a more complicated one that connected to Database and retrieved the 20 rows of 700 ran at about ~10 TPS
Just importing DocumentTemplate got it down to 7-8 TPS
Compiling a simple DTML made it go 6.5 TPS
using the DTML it to display the results --> 6.1 TPS
Running the apache bench on my development machine is getting much better results. I am just requesting the default index page from zope 2.01, so it is pretty small, but I get 65 TPS whether I use a concurrency of 30 or of 50. I do, however, still only see 3 python threads executing. This is a single CPU Mobile Pentium II with 256 MB of memory with apache and mysql and zope all running, running Mandrake 6.1 with a 2.2.13 kernel. Another test just ran and I continue to get 65 TPS on my laptop. Perhaps you are running an older kernel that doesn't like multiple CPUs, or maybe python doesn't like SMP regardless of the kernel version? I will test on my desktop now. By the way, the clieet was running on the same machine as the server, presumably eating up much of the cpu during the test. When I run it on my 500Mhz P-III desktop with 384MB of RAM, I get 75 TPS running the client on the same machine. When I run the client on my laptop, connecting over TCP, I get 77.5 TPS. This is an admittedly small document, too. I consistently have 3 python threads in operation, no matter what the concurrency (I was running 50 concurrent requests, grabbing the doc a total of 10,000 times). I saw somewhere that Medusa is touted as being an asynchronous webserver, which should allow it to run with a minimum of threads, but my experience with such architectures is that you can usually eke some performance gains out of allowing a small pool of threads to service incoming transactions (be they http connections or asynchronous callbacks), especially on a multiple CPU machine. If it isn't doing this, it is wasting a CPU and adding overhead every time the process gets switched from one CPU to the other (if linux does this, I don't know). Also, it would appear that Zope isn't really behaving in a multi-threaded manner, either, perhaps some of the guys with digicool addresses in the CC list would care to comment some on the Zope architecture, as I have not and do not have time to delve into source code right now. We should probably move such a discussion to zope-dev of course. I am subscribing now. One last thing. The zope processes were not utilizing all the memory available to them. That is probably because of the small size and limit to the number of objects being requested. Each of the 3 zope processes was running at 8MB for the entire length of the test. --sam
Another test just ran and I continue to get 65 TPS on my laptop. Perhaps you are running an older kernel that doesn't like multiple CPUs, or maybe python doesn't like SMP regardless of the kernel version? I will test on my desktop now. By the way, the clieet was running on the same machine as the server, presumably eating up much of the cpu during the test. When I run it on my 500Mhz P-III desktop with 384MB of RAM, I get 75 TPS running the client on the same machine. When I run the client on my laptop,
What program should be used for testing, and where can I get it? /Magnus Heino
Hannu Krosing wrote:
Sam Gendler wrote:
I just tested a small python cgi scriptat concurrency level 10:
a cgi script that printed the Content-type and "Hi There!" got ~30 TPS at
I suspected the CGI numbers would come down to earth. Here's the thing about Apache serving from the filesystem, that's it's native environment. Apache has been tweaked, to the max, to server files off the filesystem as fast as it can. I can remember way back in the early Apache days talking about how many sys calls per request were being made, and how this release they knocked it down by 3 sys calls! This is supreme optimization embodied in high speed C code. I would really like to see some benchmarks against a Java servelet (the idea of which started this thread), but only if that java servelet: 1) served an object out of an database (an *OBJECT* not a result row, I define an object as an instanciation of a class, regardless of the backing store that contained the object) 2) verified the request through a security system 3) dynamically generated a template that retrieved values from the object Of course, Zope does alot more than this. I certainly don't expect any Java based system to have as many cool features as Zope does, but benchmarks are unfair when you're talking about apples and Mack trucks. -Michel
On Thu, 11 Nov 1999, Sam Gendler wrote:
If even going to 2 threads on the client side causes a 20% degradation in performance, there has got to be something wrong with the threading model in the server. I will look at it as I get a chance, but I am in the midst of building a
I think the issue is with ZServer's architecture. Threads were introduced to guard against requests that blocked or took too long to complete, which placed medusa on hold. I do not expect to see any increase in performance by increasing threads unless you have requests that take a long time to execute. But before we worry about fine tuning Zope, we can easily put some upper limits to it by running a simple object through ZPublisher. Here is a test: from Globals import HTML class Test: 'test class' index_html=HTML(''' <html><head></head><body> This is test <dtml-var a> <dtml-var b> <dtml-in c> <dtml-var sequence-item> </dtml-in> </body> </html>''') test=Test() test.a='a' test.b='b' test.c=range(20) bobo_application=test and the rendered text has saved as straight HTML to be served from apache as well. On a heavily loaded server (in terms of network access) I got using apache benchmark: Document Path: /test.html Document Length: 154 bytes Concurrency Level: 20 Time taken for tests: 2.420 seconds Complete requests: 300 Failed requests: 0 Total transferred: 137846 bytes HTML transferred: 48356 bytes Requests per second: 123.97 Transfer rate: 56.96 kb/s received Connnection Times (ms) min avg max Connect: 9 13 21 Processing: 14 141 215 Total: 23 154 236 and ZServer did: Document Path: /index_html Document Length: 109 bytes Concurrency Level: 20 Time taken for tests: 6.786 seconds Complete requests: 300 Failed requests: 0 Total transferred: 83700 bytes HTML transferred: 32700 bytes Requests per second: 44.21 Transfer rate: 12.33 kb/s received Connnection Times (ms) min avg max Connect: 9 13 60 Processing: 88 422 544 Total: 97 435 604 Looks like running a simple DTML method through ZPublisher with some dynamic content, reduces performance to about a third/fourth of apache serving straight html. Not bad, even blazingly fast in my opinion (no wonder I still use bobo). At least now I know where the lid is. I hope with good caching Zope should approach such performance.
packet, or else they send the headers as one packet and the body as another. In either case, you will usually trigger this behaviour. Simply buffering the output is enough to prevent the problem.
If I remember correctly, each channel in medusa buffers all output including headers etc. Pavlos
Sam Gendler wrote:
This time I changed the concurrency (-c , -t is timelimit) on zeus_benc side -c 1 - 41 TPS -c 2 and up ~ 35 TPS and max 4 threads showing as being used in top.
the top lines of top looked like this on -t 30 -c 100
If even going to 2 threads on the client side causes a 20% degradation in performance, there has got to be something wrong with the threading model in the server.
I suspect this is due to the global python interpreter lock. Two threads content for the same locks throughout two simultaneous requests, thus resulting in the 20% loss. However, the goal of threading Zope was NOT to increase requests per/sec, the goal was to allow simultaneous requests to happen, in Zope 1.x, requests were serialized and one requests wait for (possibly long running) previous requests. Threading allows many requests to happen simultaneously, and means that individual threads can call 'blocking' methods without worrying about locking up the whole site. We knew it wouldn't increase performance, because of the global interpreter lock. Further, the python lock prevents the threaded method from scaling to anything more than a handful of threads. This whole issue is sidesteped by ZEO. ZEO is a client/server protocol between Zope clients and a storage server. The Zope clients are the 'frontend' web servers that connect to a common backend. Thus, you can have a whole farm of cheap, single processor Zope machines running the ZEO client (which is a Zope process, ie a server to the browser client) that connect to a common backend database which you can dump as much money into as you want to make it an incredibly reliable storage system (and, using something like Coda could allow you to have multiple backend storage servers, but this have never been tested and might cause alot of write-write contention). Further, because ZEO clients are seperate *processes* and not threads, multiple ZEO clients can run concurrently on multi-processor machines. ZEO is an incredibly flexible archetecture, and I think it will prove to scale well beyond anything else out there right now.
Make sure you send the largest possible packets. If the client receives a 'small packet' (I can't remember the criteria, although 1/2 maximum segment size rings a bell), it will delay the ACK of that packet for 200ms while it waits for data to go back the other way. Since this is a web client, there is no data to go back the other way, so there is a 200ms delay after every small packet from the server. On most systems, you can set TCP_NODELAY to off, but linux doesn't support this, last time I checked. Many servers started out sending each HTTP header as a different packet, or else they send the headers as one packet and the body as another. In either case, you will usually trigger this behaviour. Simply buffering the output is enough to prevent the problem.
It would be good to analyze ZServer (medusa) to see if this is done. -Michel
Christopher Petrilli wrote:
On 11/11/99 2:36 PM, Hannu Krosing at hannu@tm.ee wrote:
I have just tested an out-of box apache 1.3.9 with a page of ~18kb and an out-of-box zope 2.0.1 server with 1.2 kb zope opening page on an IBM NetFinity 5500 M20, dual Pentium III/500MHz with the following results:
This looks like regular Apache, not serverlets, not Java. Was this backed by a Java interpreter?
No, its just regular Apache, given for reference of what can be achieved. I should have been more clear about this. I also tested zope on returning DTML formatted simple sql query results from a postgreSQL DB - when using a dummy query like [select 'a' as a] i got about 25 rps when selecting ~20 rows from a 700 row table it went down to 12 rps when iterating ofer a plain list instead of the query it was about 29 rps ----------- Hannu
participants (9)
-
Christopher Petrilli -
Hannu Krosing -
Itamar Shtull-Trauring -
Magnus Heino -
Michel Pelletier -
Paul Everitt -
Pavlos Christoforou -
Sam Gendler -
Theodore Patrick