W3C home > Mailing lists > Public > www-jigsaw@w3.org > March to April 2004

RE: A couple of issues...

From: Laird, Brian <BLaird@perseco.com>
Date: Fri, 23 Apr 2004 09:36:55 -0500
Message-ID: <45A6279F82E4CA4BBDC0F4EFC7B6A2FE127FA7@atlas.perseco.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:37 GMT