[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

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.

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

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?

>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? :-)

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

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.