RE: Antwort: RE: server side sorting & paging? [Virus checked]

["Howard Chu" <hyc@highlandsun.com>]

-----Original Message-----
From: denis.havlik@t-mobile.at [mailto:denis.havlik@t-mobile.at]

>Server-side work like this doesn't scale well as the number of clients
>increases. When you have 1 server and N clients making N queries with
>sorting, it stands to reason that the N clients are more likely to have
>sufficient memory and CPU to handle their own individual search than that
the
>1 server can do all of them simultaneously.

>>>
Hi, Howard

There is a flow in this reasoning. Imagine a standard telephone book that
allows browsing trough complete set of data, sorted by surname (like a real
book does). Ther is an index on surname field, so server has no problems with
sorting & such.
<<<
This is not a safe assumption. For example, OpenLDAP's indexing mechanism
doesn't preserve ordering information, so sorting of indexed attributes
doesn't come for free. The server uses hashes for indexing, to save on
storage requirements. If indexing were also order-preserving, the space
required (both in-RAM and on-disk) would be quite a bit higher.

>>>
 Now let's look at the client-side solutions in case there is no SSS:

1) In case my client application is on the web server, there could possibly
even more LDAP servers than clients, so the above assumption is wrong.
<<<
Clearly you must design your network to best serve your needs, but it is a
very rare circumstance when you need more LDAP servers than web servers to
accomodate your total client load. I stand by my original point.

>>>
Let's continue: the only sensible way of writing a web-based telephon book
app that allows browsing of complete data would (without SSS) be to get ALL
the data from LDAP server once in the while, save it to a local DB and work
with the local data. This is somewhat ugly, but it works, because our client
application itself is a server to many web-clients, and thus needs to get the
data only once in a while.
<<<
I would say it's very rare that any client wants to browse the complete data.
When was the last time you opened a paper telephone book and read it cover to
cover, let alone reading an entire single page of entries?

>>>
2) Situation is much worse in case of "real" client applications sitting on
local desktop machines: above receipt does not work, because each client
would have to get a complete copy of data. First, this would cause very slow
client start, and second this would kill the network.

So, clients would have to

1) send a search request for a limited subset of data. something like "gimme
all the entries where surname is starting with "Ha", or maybe with "Hav"
(depends on the data set size, so we need to make an assumption on that too).
<<<
(1) sounds like the most sensible thing to do anyway, since generally people
who look in telephone directories are searching for very specific things.

>>>
2) If the returned set is too small, go back to step 1, and ask for the next
bunch of data.
3) When you get enough data, sort them and show to user.
<<<
What is "too small" vs "enough" ? If I want John Smith's phone number, and my
query only returns 5 entries, that's excellent; I only have to guess from 5
choices which John Smith is the right one. Why should I wait for an
irrelevant 15 other entries to be collected before the GUI displays any
information?

>>>
Wouldn't this mode of operation actually cause even more work on the server
side than returning exactly N entries from indexed data set would?
<<<
Aside from the actual time spent parsing the request, no. And the request
parsing overhead will be invisible to the human user if your UI displays the
results as soon as they arrive.

>>>
>Or you can choose to let the client deal with it. I like this approach,
>because while server-side sorting results in many clients seeing poor
>response, client-side sorting results in all clients seeing equally fast
>server response.

Or maybe even poorer response, because clients are asking for more data then
they really need, and/or forced to send several search requests instead of
just one? :-)
<<<
Having a poorly designed client does not mean the server needs to be fixed.

>>>
Maybe this kind of application simply shouldn't be done with LDAP?

regards
        Denis
PS: Yes, I can see that things get REALLY funny as soon as we start working
with references, i.e. as soon as the data isn't all on a single server.
<<<
That realization should tell you something...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support