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."

Received on Thursday, 22 April 2004 11:13:16 UTC