Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Replace TView with Wrap?

Project highlights: Architectural Overview

joist
Discussion topic

Hide all messages in topic

All messages in topic

Re: [helm-dev] Replace TView with Wrap?

Author edk
Full name Ed Korthof
Date 2000-07-01 17:59:50 PDT
Message On Fri, 30 Jun 2000, Manoj Kasichainula wrote:

> On Fri, Jun 30, 2000 at 04:28:01PM -0700, Ed Korthof wrote:
> > Are you saying that with a reguest for a piece of dynamic content (ie. the
> > output from a servlet), an additional http request will be required?
>
> I didn't think TView was needed for our dynamic content.
[snip]

Ah -- sorry, I was confused by the discussion of doing branding though
only one mechanism. This makes much more sense to me ...

OK, after some tests, I'm +1 on the change. More discussion follows; feel
free to ignore it, though.

> > I don't think you can discount the disadvantage so lightly: if we reach a
> > point where we're serving a significant amount of traffic, this nearly
> > doubles the cost of delivering static content (in terms of the processing
> > required).
>
> Do we have any stats on servlet processing delay vs. HTTP processing
> delay? My assumption was that servlet delay >> loopback HTTP delay, so
> that (servlet + HTTP) is approximately = (servlet + HTTP + loopback
> HTTP).

Well, I've seen stats on how much additional time it takes to use a URL
connection to get static content. Someone on the JServ list did a bit of
testing based the discussion there, using URL.openStream() ... I think
his result was at most an addition of 50ms to request time, and that may
have required several such requests. (Also, it was older hardware.)

... So I went ahead and did some tests. As a base point of reference, a
simple document takes about 250ms to deliver through TView on my test
system.

I tried a couple of different approaches to the tests. First, when using
a small file (144bytes), I found that using a FileReader is slightly
slower than using an URL. I switched to using a FileInputStream, and that
was faster than URL -- so I'm assuming the issue there is either extra OO
layers or character conversions (probably the later).

When using a 144 byte file, the difference between a FileInputStream and
URL.openStream() was about 60% -- but on a per-request basis, that was
about 6ms. When using a 1512 byte file, the difference increased slightly
-- but the abs size is still small.

That effect is drowned by the cost of using TView. So long as we only
have to do one of these per request (ie. the sidebars & so on are done
locally), you're right -- the effect is insignificant.

> > I can see the advantages, and I know I sometimes go overboard on
> > efficiency issues
>
> I don't think that's possible.

Yeah, it is -- we could say we're going to write this all in C. ;-)
Similarly, there are contortions in code which may be slightly more
efficient, but not worth the time to build & maintain ...

take care --

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [helm-dev] Replace TView with Wrap?

Author Manoj Kasichainula <manoj at collab dot net>
Full name Manoj Kasichainula <manoj at collab dot net>
Date 2000-06-30 17:29:44 PDT
Message On Fri, Jun 30, 2000 at 04:28:01PM -0700, Ed Korthof wrote:
> Are you saying that with a reguest for a piece of dynamic content (ie. the
> output from a servlet), an additional http request will be required?

I didn't think TView was needed for our dynamic content.

> Or just that an additional http request will be required for static
> content & other content which isn't delivered through joist?

That was my intent.

> I don't think you can discount the disadvantage so lightly: if we reach a
> point where we're serving a significant amount of traffic, this nearly
> doubles the cost of delivering static content (in terms of the processing
> required).

Do we have any stats on servlet processing delay vs. HTTP processing
delay? My assumption was that servlet delay >> loopback HTTP delay, so
that (servlet + HTTP) is approximately = (servlet + HTTP + loopback
HTTP).

> I can see the advantages, and I know I sometimes go overboard on
> efficiency issues

I don't think that's possible.

> -- but this strikes me as a bad idea. It seems like the
> design principle behind this is: save engineering time regardless of
> performance.

That is never something I would say intentionally. You should have
seen the hassles I went through to eliminate a single mutex call in
the Apache request path :). However, I don't think code duplication is
good either, and since Apache has a pile of code to set Expires:
headers and such, let's take advantage of it.

See the other reasons I mentioned. I think caching is an extremely
important one for efficiency. And my belief was that the proposal
would not affect performance much at all.

> Before we head down this route, I'd like to do benchmarks quantifying the
> effects -- both for static and for dynamic content.

+1.

Re: [joist-dev] Replace TView with Wrap?

Author "Daniel L dot Rall" <dlr at collab dot net>
Full name "Daniel L dot Rall" <dlr at collab dot net>
Date 2000-06-30 16:46:01 PDT
Message Manoj Kasichainula wrote:
>
> I'd like to propose that the TView servlet from Helm get replaced
> eventually with the Wrap servlet from Joist.

+1
--

Daniel Rall <dlr at finemaltcoding dot com>

Re: [helm-dev] Replace TView with Wrap?

Author edk
Full name Ed Korthof
Date 2000-06-30 16:28:01 PDT
Message On Fri, 30 Jun 2000, Manoj Kasichainula wrote:

> I'd like to propose that the TView servlet from Helm get replaced
> eventually with the Wrap servlet from Joist.
>
> Advantages:
> - Wrap will eventually pass-through all headers. So caching of content
> and other features will be given to us for free, because we let
> Apache handle those details
> - Content can be done using any system (SSI, PHP, whatever), and still
> wrapped.
> - Standardize on one way to do wrapping of content instead of two
>
> Disadvantages:
> - Somewhat slower for wrapped static content, because of hitting
> Apache twice. I don't think this will be a significant difference,
> since we're doing so much dynamic content generation anyway.
>
> Thoughts?

Are you saying that with a reguest for a piece of dynamic content (ie. the
output from a servlet), an additional http request will be required? Or
just that an additional http request will be required for static content &
other content which isn't delivered through joist?

I don't think you can discount the disadvantage so lightly: if we reach a
point where we're serving a significant amount of traffic, this nearly
doubles the cost of delivering static content (in terms of the processing
required).

I can see the advantages, and I know I sometimes go overboard on
efficiency issues -- but this strikes me as a bad idea. It seems like the
design principle behind this is: save engineering time regardless of
performance. That doesn't necessarily make for good engineering -- and
more importantly, it ignores the fact that if there is a sufficient
performance effect, additional machines will be required -- that means
additional people are needed to manage the servers, which is an ongoing
cost.

Before we head down this route, I'd like to do benchmarks quantifying the
effects -- both for static and for dynamic content. I suspect we could
look at the logs on tigris.org to get an idea what sort of effect this
would have on our hardware requirements. Actual tests are (IMO) the only
way to determine whether or not a bad algorithm actually has a significant
effect. Often it doesn't ...

Ed
--
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=
   | Ed Korthof | edk at collab dot net | 415-247-1690 |
   +=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=+=-=​+=-=+=-=+=-=+=-=

Re: [joist-dev] Replace TView with Wrap?

Author Jon Stevens <jon at latchkey dot com>
Full name Jon Stevens <jon at latchkey dot com>
Date 2000-06-30 15:38:51 PDT
Message on 6/30/2000 3:19 PM, "Manoj Kasichainula" <manoj at collab dot net> wrote:

> I'd like to propose that the TView servlet from Helm get replaced
> eventually with the Wrap servlet from Joist.
>
> Advantages:
> - Wrap will eventually pass-through all headers. So caching of content
> and other features will be given to us for free, because we let
> Apache handle those details
> - Content can be done using any system (SSI, PHP, whatever), and still
> wrapped.
> - Standardize on one way to do wrapping of content instead of two
>
> Disadvantages:
> - Somewhat slower for wrapped static content, because of hitting
> Apache twice. I don't think this will be a significant difference,
> since we're doing so much dynamic content generation anyway.
>
> Thoughts?


+1

-jon

Replace TView with Wrap?

Author Manoj Kasichainula <manoj at collab dot net>
Full name Manoj Kasichainula <manoj at collab dot net>
Date 2000-06-30 15:19:29 PDT
Message I'd like to propose that the TView servlet from Helm get replaced
eventually with the Wrap servlet from Joist.

Advantages:
- Wrap will eventually pass-through all headers. So caching of content
  and other features will be given to us for free, because we let
  Apache handle those details
- Content can be done using any system (SSI, PHP, whatever), and still
  wrapped.
- Standardize on one way to do wrapping of content instead of two

Disadvantages:
- Somewhat slower for wrapped static content, because of hitting
  Apache twice. I don't think this will be a significant difference,
  since we're doing so much dynamic content generation anyway.

Thoughts?
Messages per page: