- From: Laird, Brian <BLaird@perseco.com>
- Date: Fri, 23 Apr 2004 09:36:55 -0500
- To: "Yves Lafon" <ylafon@w3.org>
- Cc: <www-jigsaw@w3.org>
Yves, Here is my current server configuration. Let me know if you see anything that should be changed. In the future, we plan on turning off keep alives because it helps our load balancer better. Thanks, Brian #Jigsaw written #Thu Mar 25 17:46:42 CST 2004 org.w3c.jigsaw.http.socket.SocketClientFactory.bindAddress=192.168.17.83 org.w3c.jigsaw.serializer=org.w3c.tools.resources.serialization.xml.XMLSerializer org.w3c.jigsaw.servlet.servlet-log-file=/opt/jigsaw_2_1/Jigsaw/logs/scm_servletlog.txt org.w3c.jigsaw.logger.logname=/opt/jigsaw_2_1/Jigsaw/logs/scm_log.txt org.w3c.jigsaw.checkSensitivity=true org.w3c.jigsaw.server=Jigsaw/2.2.2 org.w3c.jigsaw.root=/opt/jigsaw_2_1/Jigsaw org.w3c.jigsaw.config=/opt/jigsaw_2_1/Jigsaw/config_scm org.w3c.jigsaw.root.name=virtual_hosts org.w3c.jigsaw.logger.tracelogname=/opt/jigsaw_2_1/Jigsaw/logs/scm_tracelog.txt org.w3c.jigsaw.version.counter=4 EnableServerTracing=false org.w3c.jigsaw.trace=false org.w3c.jigsaw.ssl.keystore.password=**** org.w3c.jigsaw.port=8501 org.w3c.jigsaw.http.socket.SocketClientFactory.maxIdle=80 org.w3c.jigsaw.http.socket.SocketClientFactory.maxClients=150 org.w3c.jigsaw.docurl=/Doc/Reference org.w3c.jigsaw.propfile=/opt/jigsaw_2_1/Jigsaw/config/https-scm.props org.w3c.jigsaw.keepAlive=true org.w3c.www.protocol.http.filters= org.w3c.jigsaw.client.priority=5 org.w3c.jigsaw.ssl.enabled=true org.w3c.jigsaw.request.timeout=3000000 org.w3c.jigsaw.client.bufsize=8192 org.w3c.jigsaw.root.class=org.w3c.jigsaw.resources.DirectoryResource org.w3c.jigsaw.http.socket.SocketClientFactory.maxThreads=100 org.w3c.jigsaw.space=/opt/jigsaw_2_1/Jigsaw/WWW org.w3c.jigsaw.logger.errlogname=/opt/jigsaw_2_1/Jigsaw/logs/scm_errlog.txt org.w3c.jigsaw.host=pulaski.perseco.com org.w3c.jigsaw.checkpointer=/Admin/Checkpointer org.w3c.jigsaw.http.socket.SocketClientFactory.maxFree=15 org.w3c.www.protocol.http.connections.timeout=840000 org.w3c.jigsaw.trashdir=/opt/jigsaw_2_1/Jigsaw/trash org.w3c.jigsaw.http.ClientFactory=org.w3c.jigsaw.https.socket.SSLSocketClientFactory org.w3c.jigsaw.edit.root=root org.w3c.jigsaw.logger=org.w3c.jigsaw.http.PersecoCommonLogger org.w3c.jigsaw.ssl.keystore.path=/opt/jigsaw_2_1/Jigsaw/keystore/scmnavigator.keystore -----Original Message----- From: Yves Lafon [mailto:ylafon@w3.org] Sent: Thursday, April 22, 2004 10:12 AM To: Laird, Brian Cc: www-jigsaw@w3.org Subject: Re: A couple of issues... On Tue, 20 Apr 2004, Laird, Brian wrote: > First, I have been running off the build you made a few weeks ago and > everything has been great. From our standpoint, everything seems to be > caught up and fixed. Thomas deserves a huge thank you for putting > together SSL fixes. His solution is much more elegant and useful than > what I had originally came up with. Good to know! I am currently heavily testing it, and so far, I didn't see anything preventing me to schedule a 2.2.5 quite soon. > Now what email from wouldn't be complete with a few issues / questions: :) > > > 1) Re-indexing loses changes made to a file entry: I setup an > existing html file, which was originally indexed with an HTMLFrame, with > the SSIFrame. If I re-index through the admin tool, the SSI Frame and > subsequent filters are lost and reset to the HTML Frame. Is this > correct and is there any way to correct it so that doesn't happen? Yes, this is one of the issues of reindexing that has not been entirely solved, how to distinguish from a manually edited resource from a automatically (and then reindexable) one. Also what people expect from a reindex may vary from "reindex only what has been done automatically" to "reindex everything" (the cleanup mode). I am afraid I have no good reasons for that. > 2) Performance of the mirror frame: We have been doing a lot of > load testing on our jigsaw servers and I have figured out that on a per > request basis the mirror frame takes at least 2 seconds to do it works. > An example would be the following: > > * Workstation talks to server1 to be mirrored - We get 250+ > requests per second for a 1 user load (no think time) > > * Workstation talks to jigsaw server which is mirroring server1 > - We get about 40 requests per second. What is the configuration on the jigsaw server? By default it will open a maximum of 5 concurrent connections, this needs to be tuned, as well as the client buffer probably. > It should be noted that jigsaw does great just serving up files. I am > hoping that you can help shed some light why there is such a gap when > doing the mirror frame or if there is settings we can use to optimize > the performance. I do realize everything that has to be done in mirror > frame and I also realize that in the long run there may not be anything > that can be done about it. This could also be more of an issue with > HTTP client and less with the mirror frame. I will try to do some test to find out where are the possible points of contention (there might be unneeded costly synchronization statement somewhere). The latest jar (probably the one you test) already have lots of improvements in the speed of the client stack. More on this soon (I hope :) ) -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras." ************************************************************************ This e-mail and any accompanying documents or files contain information that is the property of Perseco, that is intended solely for those to whom this e-mail is addressed (i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary, and/or privileged. If you are not an intended recipient of this e-mail, you are hereby notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of this information is strictly prohibited and may be subject to legal sanctions. If you have received this e-mail in error, please notify the sender immediately of any unintended recipients, and delete the e-mail, all attachments, and all copies of both from your system. While we have taken reasonable precautions to ensure that any attachments to this e-mail have been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses. ************************************************************************
Received on Friday, 23 April 2004 11:22:49 UTC