RE: WebDAV effeciancy

> I haven't expressed my question correctly - sorry. By WebDAV 
> and HTTP, in fact I meant comparing the process of 
> communication between the WebDAV servers and clients compare 
> to the HTTP ones.
> 
> I agree with you that WebDAV is an extension on HTTP and 
> provide all functionality of the HTTP, added some new 
> functionality regarding the metadata, access control, locking 
> and so on. However, since there is more processing for those 
> new functionality in environment based on the WebDAV 
> protocol, I am wondering how much this would effect on the 
> speed. Also many functionality of the WebDAV can be 
> implemented by HTTP POST method, Soap and so on ( as you 
> mentioned like Microsoft FrontPage). So if the security is 
> the same and if the speed may be low (not sure), why would 
> the user choose WebDAV rather HTTP?
> 

A WebDAV server can be implemented that has the same performance as an HTTP
server, for the HTTP functions.  THat is to say, as long as the server is
being used only for HTTP functions, it would have the same performance and
scalability.  A thousand GET requests can theoretically be handled in the
same time whether or not you've got WebDAV.

When the server's usage includes WebDAV requests as well, obviously this can
change things -- and now it really depends on the scenario.
 - When users start using WebDAV functionality, are they doing *more*
requests?  On top of the thousand GET requests per minute, are users now
also doing a thousand PROPFIND requests?  Obviously this is twice as many
requests and takes more processing time on the server.
 - On the other hand, when users start using WebDAV does this *replace* HTTP
requests?  Imagine 500 of our 1000 GET requests are directory listings, so
when WebDAV replaces the server generated directory listings, there are then
500 GET requests and 500 PROPFIND requests in an average period.  Now the
server can be *faster* because it should be faster to generate and send 500
PROPFIND responses than to compile 500 dynamically-generated GET responses
with the same directory listings.  That's because in the HTTP scenario the
server is responsible for generating the presentation (in HTML) of the info,
whereas in WebDAV the client is responsible for presentation.

This kind of analysis can be extended.  In general, and on average, I think
we find that when the server has to do presentation it has more work to do,
and thus has worse performance and worse scalability.  WebDAV generally
allows the server to do less presentation work, which should improve its
performance and scalability (as long as the overall usage patterns do not
change, which they might).

An example of this was documented at Microsoft in the development of Outlook
Web Access for Exchange 2000.  When the server had to do all the
presentation work itself, the OWA server could not handle so many users.
When the server offloaded the presentation work using scripting, stylesheets
and WebDAV, the number of users that could be handled increased by a very
significant amount. If the client supported WebDAV without needing scripting
and stylesheets (if it had all its own presentation logic) then even more
clients could have been handled.

So in a general authoring scenario, I would expect WebDAV to be much more
scalable and high-performing than a HTTP interface that uses forms (like
Yahoo PageWizards).

Now let's consider FrontPage.  FrontPage is very much like WebDAV in the
semantic operations it defines.  Thus, we would expect its performance to be
very much like WebDAV.  They both extend HTTP, it's just that FrontPage does
it in different ways.  But both FrontPage and WebDAV leave the presetnation
layer to the client so they have similar characteristics.

SOAP is an entirely theoretical case.  There doesn't exist a set of
authoring operations defined for SOAP.  So how could we compare them?  SOAP
is a protocol for delivering XML payload but it doesn't define any schemas
for payloads that would allow authoring operations, like LOCK and UNLOCK and
metadata operations.  If you were to write a new schema for SOAP to define
authoring operations, since SOAP is based on HTTP as well it might be as
scalable as WebDAV, but it would likely be less scalable (because there is
overhead in SOAP that WebDAV doesn't seem to need).

There are a number of factors you didn't mention, beyond
performance/scalability, why a user would choose WebDAV authoring rather
than a non-standard HTTP-based client authoring solution.
 - WebDAV allows clients to syncrhonize data in order to maintain sites
(sitecopy), for offline usage or to run automated backups (Xythos WFC).
 - WebDAV allows clients to control the UI.  Your UI can be 
	Command-line (like cadaver)
	Mac-like (WebDAV-FS, Goliath)
	Windows Explorer (Xythos WFC, Web Folders)
	A search-oriented file "locator" rather than explorer (KCura)
 - WebDAV allows users to save straight from Office and Adobe authoring
applications (and any other app that chooses to support WebDAV).  This saves
the upload step.
 - WebDAV allows the user/client to choose a language and supports
sight/hearing disabled usage better than HTML.
 - WebDAV allows locks to be obtained automatically by the authoring
application.  HTTP-based authoring sites either don't support locking or
make the user get locks manually (like www.sharemation.com)

Beyond this I suggest you preorder my book, though it's not out quite yet.
(http://www.amazon.com/exec/obidos/tg/detail/-/0130652083/qid=1055892821/sr=
1-1/ref=sr_1_1/103-3410589-6207009?v=glance&s=books)

Lisa

Received on Tuesday, 17 June 2003 19:34:34 UTC