Jim | 28 Nov 13:23
Favicon

How does remote server work?

I'm concerned that there will be a performance hit if there is a large 
amount of data transferred over a slow link.  Does the actual search 
occur on the client or the server side?  If on the client side, then how 
much data is transferred?  If it's on the server side then can I assume 
that a small amount of data is pushed to the server and just the results 
returned?

Thanks,
Jim.
Olly Betts | 30 Nov 06:11
Favicon
Gravatar

Re: How does remote server work?


On Sat, Nov 28, 2009 at 07:23:22AM -0500, Jim wrote: > I'm concerned that there will be a performance hit if there is a large > amount of data transferred over a slow link. Does the actual search > occur on the client or the server side? If on the client side, then how > much data is transferred? If it's on the server side then can I assume > that a small amount of data is pushed to the server and just the results > returned?
A search is performed on the server and the resulting MSet serialised and returned to the client. If there are other sub-databases (local or remote), the results are merged to give the final MSet. So it should behave fairly well on slower connections. We also try to minimise the number of exchanges required for the benefit of high latency connections. If you find it is slower than you'd like, all the messages are sent and received by the same mechanism, so you could easily dump out the message type and size to see what is going on. Cheers, Olly
Jim | 1 Dec 20:33
Favicon

Re: How does remote server work?


Olly Betts wrote: > On Sat, Nov 28, 2009 at 07:23:22AM -0500, Jim wrote: > >> I'm concerned that there will be a performance hit if there is a large >> amount of data transferred over a slow link. Does the actual search >> occur on the client or the server side? If on the client side, then how >> much data is transferred? If it's on the server side then can I assume >> that a small amount of data is pushed to the server and just the results >> returned? >> > > A search is performed on the server and the resulting MSet serialised and > returned to the client. If there are other sub-databases (local or > remote), the results are merged to give the final MSet. So it should > behave fairly well on slower connections. We also try to minimise the > number of exchanges required for the benefit of high latency connections. > > If you find it is slower than you'd like, all the messages are sent and > received by the same mechanism, so you could easily dump out the message > type and size to see what is going on. > > Cheers, > Olly > >
Thanks, I am sure that will work fine. I was just concerned that it might want to transfer large blocks of the index files. The connection isn't that slow but gigabytes of data over even a fairly fast connection takes a while. Jim.

Gmane