RE: [xsl] xslt on server-side vs. client-side

Subject: RE: [xsl] xslt on server-side vs. client-side
From: "Chris Bayes" <chris@xxxxxxxxxxx>
Date: Fri, 16 Nov 2001 17:21:01 -0000
This is a Friday afternoon thing so
 
> If there is use of the XSLT on the client side then you may 
> save some costs, in some cases.  However, I think I was clear 
> that, in restricting this to 1000 different clients for 1000 
> total passes, that no reuse was happening...? 
> 
> In that particular case, suppose that we have two units of 
> work:  some HTML we want to produce on the browser and some 
> XML and XSLT we want to transform to produce this HTML.  The 
> odds that the XML/XSLT combined in size are smaller than the 
> HTML are extremely low (at least for the XSLT I've written, 
> it is a rather verbose language!).

I disagree totally with that. Your code must be grim ;-)
Seriously though I think you are wrong. Davids company database/42 is a
good example. But even for tables you are going to reduce trafic. If you
are using a very pulling pull stylesheet where the xslt almost looks
like the final html but with a few <xsl:value-of scattered around you
might be right.

>  So, there are no traffic 
> savings in the simple scenario that I've described (if the 
> XSLT is reused on the client it's a different matter).

It seems it usually is.
> 
> Now let's also suppose that the work to process the XML/XSL 
> is equal to the work to render the HTML (a likely generous 
> assumption): 2 units of work total.  Then sending the work to 
> 1000 clients results in 2000 units of total work being done.  
> If you do the same processing on the server, the XML/XSLT 
> will already be at least partially cached (on a properly 
> designed server the efficiency of re-running the transform 
> will be high). I've seen work loads drop by orders of 
> magnitude for subsequent passes, but let's say the result is 
> a 50% reduction in work load (again being generous).  In that 
> case, the total work done with the processing on the server 
> is 1000+1+499.5 = 1500.5 units of total work (1000 units of 
> client rendering, 1 full pass on the server and 999 passes at 
> 50% of the original cost).  A more realistic scenario would 
> see something like 4000 units of work on the client side and
> 1000+4+399.9 = 1807.8 doing it all on the server).
> 
Well that looks ok but it misses a simple thing. If you are sending
static pages each time then you are better off creating static html as
part of the publishing process. However if you are doing serverside
transforms it is usually because you are transforming as the result of
some user input. As this can change because users just tend to do that
(sheesh damn humans) a lot of the results of the transforms can't be
cached.

> Don't misunderstand me, I'm a big believer in distributed 
> computing -- I founded the distributed computing Project for 
> SHARE (now SHARE/GUIDE) some 12 or so years ago.  However, 
> the original assertation that sending an XML/XSLT transform 
> to the client somehow automatically saves electricity just 
> doesn't pan out.  
> 
I still think it does.

> Yes, there are cases where sending a transform to a client 
> make sense. However, many people seem to use the  MS IE 
> combination to process XML/XSLT simply because they don't 
> have the ability (knowledge/whatever) to process it on the 
> server side.  In such a case, it's likely not sound 
> ecological reasoning that's driving the decision!
> 
It is funny that because on this list most people who ask questions seem
to be stuck in a serverside rut and don't seem to have the ability
(knowledge/insight/attitude) to think clientside ;-) as a rule of thumb
I think it is more ecological to go clientside.

Ciao Chris

XML/XSL Portal
http://www.bayes.co.uk/xml




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread