Click here to Skip to main content
15,303,825 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hello all,

I want to share my experience on a distributed system and the challenge that we faced as a team. We have built a web-application that is managed centrally. Installed and runs off from a central server - works fine or does what is expected in terms of functionality. However, we are being challenged on performance issues. We are getting network latency - before our new web-application gets deployed, there is a legacy standalone or desktop system that runs on multiple branches and states as a distributed system. The legacy does not have a performance issue because the application and database are on the same local network.

However, for the centralized application which is the new one, we have identified that some branches are slow, and we also have identified mainly because of the network issue but we have to overcome the problem at the same time. We are getting slow response times for some reports and/or requests.

What options do we have to give as a solution(s) for these poor performance sufferings?


What I have tried:

caching using redis, query optimization, and reduced chatty requests and used dapper
Updated 30-Mar-21 2:27am
Gerry Schmitz 30-Mar-21 11:42am
Before trying to fix "slow", you need to identify "why" slow. You haven't. You're trying to fix a "problem" you don't understand. Not possible.
Yonathan1111 2-Apr-21 7:26am
Okay, I thought I was clear on my statement, but here I will try to explain more what we identified so far as our main performance problem.
1. Network Latency: This is the major and known problem that we have because many branches are performing seamlessly or their response time is acceptable for users as well as it is matching the standards.
2. Query: This is another area where we are working as a team there are some queries that need to be optimized.

We are not guessing nor
Dave Kreskowiak 30-Mar-21 12:47pm
The legacy does not have a performance issue because the application and database are on the same local network
NEVER make that assumption. So what if they are on the same network? Proper design of your database, app, and any middleware is what lends to the performance of the overall app, not just "it's all on the same network".

You're going to have to instrument your code and get profilers looks at every aspect of your entire application, end-to-end, to see where the bottlenecks are and what the impacts to your application are.
Yonathan1111 2-Apr-21 7:35am
Hi, I did not make any assumptions, we have tested our system within the local area network and it performed well and the legacy system does not have any performance problem.
The problem comes when users use ours from a different network due to two or three cases as I have mentioned under the above comment.
Dave Kreskowiak 2-Apr-21 10:53am
There is so much that can impact your app performance that's it impossible to tell you specifically what to look at.

You're going to have to look at EVERYTHING between the client machine and your servers, wherever they may be.
diginet0 8-Apr-21 13:12pm
You do not describe which kind of network issue You have, but because You mentioned that the branches are slow, seems to be a bandwidth issue. Normally a network problem has to be resolved as a network issue, what means increase the bandwidth of the connection on the slow branches. Other more sophisticated arrangements are to view your complete network topology and look if you can connect slow branches to some regional branches that have good response time. In that case usually this connection could be less expensive that a national one and you can purchase more bandwith for such connections.
By other hand You also can send less data, and that means compress data at both ends. There are solution that allows to create vpns with compressed data (Ziproxy, X2Go etc..).
From the SQL point of view, that involves a complete design constrain to reduce the data flow to the minimum. If some data is only for branches and it can be consolidated at the end of the day, then You can have some small server for the branch with such data avoiding constant data flow between the central site and the branch.
Yonathan1111 7-Feb-22 8:25am
thanks for your reply, and I apologize for my late response...long story in short..we resolved the issue...what we did is we deployed a datalayer api that runs on the each machine and our main/centeral api connects to this via a REST the main game changer here is that we used to establish a direct odbc connection to those machines and replaced this with REST in other words, the actual data fetching queries reside within each machine does not appear in the wire...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900