- From: Francois Deza <francois.deza@sema.fr>
- Date: Wed, 26 Feb 1997 21:16:45 +0100
- To: Anselm Baird-Smith <abaird@w3.org>
- CC: www-jigsaw@w3.org
Anselm, Thanks for your reply. We have done some experiments and want to ask new questions. The logger is indeed a major bottleneck, do you think increasing the w3c.jigsaw.logger.bufferSize property (default 8192 bytes) would alleviate this issue. The logger of Jeeves seems far less of an issue. When put upon heavy stress (with the right stresser), Jigsaw refuses many connections (the ServerSocket.accept call generates a "Too many file handles open") runtime Exception under Solaris. There are limits on the number of file handles in the kernel and per process. Is there any way to parametrize it in Jigsaw so that we can tune it for heavy load? I have seen that the ServerSocket instantiated in SocketClientFactory has a hardcoded backlog equal to 128. Could you comment on that? Why is it so high? Could you supply me on guidelines on how to set the w3c.jigsaw.http.socket.SocketClientFactory properties minfree, maxfree, maxidle, masclients, idleTimeout and maxThreads. I mean they are complex interdependencies between those with respects to the tuning of the performance of Jigsaw. Currently, we are running benchmarks with different values for all those parameters so that we could possible derive tuning rules. An explaination of the rationale behind the algorithms coded in Jigsaw would help a lot. I am referring to the changing priority of the thread accepting sockets, the killing of clients and the server state changes. To finish, could you clarify the following phenomenon. Upon certain circumstances the stresser in httpd does not return when Jigsaw gets overloaded. I mean certain threads never join. We observed the same for Stresser (in java). This is strange considering than Jigsaw seems to recover in the meantime from the overload. Francois Anselm Baird_Smith wrote: > > Francois Deza writes: > > Anselm, > > > > We tested the performance of Jigsaw upon simultaneous > > transactions againt Netscape, Apache and Jeeves. > > > > Our conclusion is that Jigsaw is right now not very scalable. > > For instance, with the Stresser utilitity provided in the > > distribution of Jigsaw we see the following results. > > Lots of comments :-) > > - To start with, the Stresser is not the tool to use for benchmarking > (in fact it would be the bottleneck) > - Not included in 1.0alpha5 (because I wanted it to be compatible with > 1.0.2) is a call to setNoDelay (grep JAVA11 in > w3c.jigsaw.http.httpd, and uncomment if you're using java11). This > causes severe performance penalty, particularly on a LAN. > - The logger is still a bit of a bottle neck in Jigsaw, I will > (hopefully) have time to enhance it. > - If you want to see really a serious benchmark check > > http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html > > Even though this page is about HTTP performances, you can use it to > get some rough idea as to how Jigsaw compares to Apache. > > - Also, directory listings are much slower in Jigsaw than in Apache, > make sure you run your benchmark on files > - Lastly, I would be very interested in getting performance numbers > that take into account SSI, authentification, or that kind of > features. (SSI would be particularly interesting, I expect Jigsaw to > beat any other server, by far, on that topic) > - par=100 is not recommended with the default config of Jigsaw, you > should fiddle with the socket client properties before playing that > kind of games (quite a difficult task, let us know if you try it) > - The last bug (failed to accept), is either a Java or a solaris bug ( > I can't remember which one of them), > - jdk1.1final (which will run Jigsaw at least on unix) is the one to > pick for benchmarking on unix, on windows use symantec cafe jit > compiler > > With all this in mind, I am eager to hear your opinion ;-) > > Anselm. > > > For Jigsaw with par = 10: > > > > Total request: 411 > > Total time : 61328 > > Req/sec : 6.7016697104096 > > detailed results: > > http://saggitaire:8001/: s=1046 t=1.4779268292682928 f=0 t=605950 c=410 > > > > For Apache with par = 10: > > > > Total request: 2694 > > Total time : 60157 > > Req/sec : 44.78281829213558 > > detailed results: > > http://saggitaire:80/: s=523 t=0.22259041960638695 f=0 t=599436 c=2693 > > > > For Jigsaw with par = 100: > > > > Jigsaw crashed with the following exceptions, > > client-5: caught ClientException: [w3c.jigsaw.http.ClientException] > > Resource temporarily unavailable > > [http-server] failed to accept incoming connection on > > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8001] > > [http-server] linux/193.106.58.164 refused (overloaded). > > > > > > For Apache with par = 100: > > > > Total request: 2957 > > Total time : 65434 > > Req/sec : 45.1905737078583 > > detailed results: > > http://saggitaire:80/: s=523 t=1.6727302182810366 f=24 t=4904445 c=2932 > > > > > > Could you please comment on that. > > I mean do you have suggestions on solutions to this scalability issue. > > I really find Jigsaw a fantastic product. > > My only concern right now is its scalability. > > > > Francois > > > > > > > > -- > > > > Sincerely yours, > > > > ------------------------------------------------------- > > Francois Deza mailto:francois.deza@sema.fr > > Corporate R&D http://www.semagroup.com > > > > Sema Group tel: 33 - 1 - 40 92 43 16 > > 16, rue Barbes fax: 33 - 1 - 40 92 42 41 > > 92126 Montrouge Cedex > > France > > > > secretary: Beth Gould > > tel: 33 - 1 - 40 92 42 18 > > email: beth.gould@sema.fr > > ------------------------------------------------------- > > > > -- Sincerely yours, ------------------------------------------------------- Francois Deza mailto:francois.deza@sema.fr Corporate R&D http://www.semagroup.com Sema Group tel: 33 - 1 - 40 92 43 16 16, rue Barbes fax: 33 - 1 - 40 92 42 41 92126 Montrouge Cedex France secretary: Beth Gould tel: 33 - 1 - 40 92 42 18 email: beth.gould@sema.fr -------------------------------------------------------
Received on Wednesday, 26 February 1997 15:28:40 UTC