Remote client is much slower than leech.

Remote client is much slower than leech.

book

Article ID: KB0086040

calendar_today

Updated On:

Products Versions
TIBCO ActiveSpaces -
Not Applicable -

Description

Description:
Switched from joining an AS cluster as leech to joining as a remote client and observed that performance is degraded by 50% for writes and 100-150% for reads (get and query). Why is a remote client slower than a regular leech connection.


Symptoms:
Remote client is slower then regular leech connection.
Cause:
A remote client connects to a member within the cluster and that member acts as a proxy for the remote client. The remote client forwards its request to the proxy who then invokes the request as if it were its own. When the request is complete the proxy then forwards the result back to the remote client. There is generally no load balancing required since the proxy acts as a pass through. However, there is some CPU overhead for acting as a pass through so it is advised to distribute the remote clients to connect to different proxy members if possible.

Resolution

With a leech client, the nodes participating in execution of the request are client and the seeder. With a remote client, the proxy is also present in the execution path. Having an extra node in the path leads to more latency for each transaction due to the processing at the proxy and the extra TCP hop needed to transport the messages between the remote client and the proxy.

The attached (Filename:Remote-client_status.jpg) chart shows the following:

The graph is the time for 250k sequential puts with leech and remote client as the  replication count is increased.
X-axis: replication count
Y-axis: Time taken for 250k puts

It shows that the delay introduced by the remote client is constant irrespective of the replication so the remote client impacts only the latency and not the though put. The effects of this latency increase can be minimized by having the client do multiple concurrent requests. This can be achieved using any of the following:
  • Use batch requests like (putAll, getAll etc)
  • Having multiple threads issuing these requests concurrently.
  • Have multiple instances of the client application
Any of these approaches would alleviate the throughput reduction that would be associated with the increased latency.

Issue/Introduction

Remote client is much slower than leech.

Additional Information

Remote client documentation from developer guide

Attachments

Remote client is much slower than leech. get_app