I have a set of layers that resides within two different enterprises SDEdatabases (SQL). these layers are consumed by a map service (contains more than 20 layers) through the ArcGIS server 10.6. The map service is very smooth and fast on one of the ArcGIS servers. but on the second one, there is one layer (Streets > 1.5 million records) that causes display slowness on the low zoom levels.
ArcGIS manager logs do not register any error.
kindly advise what does affect the connection between the ArcGIS server and the SDE database? and what could be the reason for the slowness in the above map service?
thank You.
A couple of questions for you:
hello, john,
1. servers are on the same data center but I don't know exactly if they have the same specs
2. No
3. I am not using anything. it is just a simple map service used for display without feature editing.
4. I tried to simplify the layer but I didn't try it yet. (noting that the same layer is working well in another database)
Thank You.
I have a few more question in addition to what @John_Spence asked.
1. by 'on the low zoom levels', I assume you meant when you zoom in to larger scales (i.e. smaller geographic region), right? I'm sorry this thing is always confusing, I just to need to make sure of.
2. I assume you have some visible scale range set, so that you will not draw all 1.5 million lines when zoom out to larger areas (i.e. smaller scales)?
3. the extent/scale where you observe slowness, how many features you are typically drawing? Also, important how many vertices you have - that increases the size of the payload while transferring from database and slow down the performance. (I believe that is what John was talking about)
4. can you also profile/trace it from the database side, see what kind of requests being sent by map service and how database reacting to them?
5. finally if you set Server log level to Verbose, you will see map service reports how much time it takes to execute a query, fetch data and draw features... That should give you good clues to find out whether the bottlenecks are.
hope this helps
Hello,
1. Yes I mean zoom in to larger scales (i.e. smaller geographic region)
2. of course I am using scale dependency for each layer
3. at 1/50,000 I have ~30,000 features (polylines) and vertices count (~60,000 BOTH-ENDS)
at 1/7,500 I have ~1,200 features (polylines) and vertices count (~2400 BOTH-ENDS)
4. what is the best way/tools to trace
5. verbose option didn't show any log data. the only thing that shows log data is the warning option.
the stranger thing is that the same layers are very fast within a different database and map service.!!
Thank You.
Thanks @ElieRizk
3. ah! So, they are polylines with start and end vertices. Out of curiosity, how long it takes to draw all 30k features at 1:50,000 in your other map service?
4. I usually work with SQL Server as my backend database. It comes with SQL Server Profiler.
I'm not sure how to trace/profile for other databases such as Oracle/PostgreSQL.
5. Here is what I did?
a) Set Log Level to Verbose from Settings.
b) Add Time Elapsed from Columns
c) Make an Export call
d) Set Log Filter to Verbose and click Query
the stranger thing is that the same layers are very fast within a different database and map service.!!
Yes, that is strange. Please start with Server log, that should give you clue about what is taking more time - drawing or data access. I'd suggest to get the same matrices from both map services to compare. If you see it is data access that is taking more time. Then you can do database trace.
@TanuHoque Hello.
I followed your listed steps above and I noticed a frequent display of the below messages especially when zooming to larger zoom scales:
1. String request successfully processed. Response size is 381 characters
2. An existing connection was forcibly closed by the remote host
and I attached some images to show the response time at different larger zoom levels.
@ElieRizksorry for the delay.
In your screenshots, I don't see elapsed times for data access and execution. Can you compare those numbers with the machine where everything runs fine.
2. An existing connection was forcibly closed by the remote host
do you see the same error message on the other machine?
do you suppose that the SQL version might cause this issue?
that might be a possibility.
I think it is better to reach out to Esri Support and have them take a look. This kind of issues are hard to debug over community posts. Sorry couldn't help much.