设置了共享实例池为16（逻辑核8）每个实例缓存150个服务
发布了2800个共享实例的服务。都采用单图层的，使用pro生成的sd文件。
服务数量截图（较早的某些时候）
服务器为笔记本T480 cpu i7 8代低电压版 4核双线程 压测时状态为100% 内存占用不高。计算机需提供良好散热。
用Jmeter进行压测
预先压测
首先，预先进行编号为0-800的服务压力测试600秒，迫使这800个服务进入共享实例池的缓存，看是否存在响应超时或失败或服务器挂死情况。
查询接口
/arcgis/rest/services/MapService${__Random(0,800,)}/MapServer/0/query?
32个线程持续查询600秒，0-800个服务之间的随机服务。
吞吐量为每秒请求18.8个，服务平均响应时间1.7秒左右，无异常情况。
正式测试
1.首先为了证实每个共享实例的缓存服务数的作用，测试超出该额定服务数量范围导致的性能下降。
1.1.测试每个实例缓存的服务数量导致的性能下降，首先是基准测试，16实例，缓存服务数50，每秒16个跨度为800。
1.1 池化设置
查询请求地址
/arcgis/rest/services/MapService${__Random(0,800,)}/MapServer/0/query?
16个线程查询0-800个服务之间的随机服务接口，持续600秒
平均响应时间834毫秒，响应时间中位数860毫秒
16个线程查询0-800个服务之间的随机服务接口，持续600秒
1.2.其他参数不变，更改服务的跨度为0-1600。主要用来测试请求的服务多样性在预测的范围内并发访问量增加，导致的响应时间变长情况。
/arcgis/rest/services/MapService${__Random(0,1600,)}/MapServer/0/query?
每秒16个线程查询0-1600个服务之间的随机服务接口，持续600秒
可以观察到平均响应时间不断增长，由860增长到891，这是请求无法击中共享实例缓存的服务名的表现。命中缓存的概率为50%
16个线程查询0-1600个服务之间的随机服务接口，持续600秒
1.3.其他参数不变，更改跨度为2400
/arcgis/rest/services/MapService${__Random(0,2400,)}/MapServer/0/query?
每秒16个线程查询0-2400个服务之间的随机服务接口，持续600秒
可以观察到吞吐量变小，平均响应时间比之前还长了一些。
16个线程查询0-2400个服务之间的随机服务接口，持续600秒
2.1.测试调整增大每个共享实例缓存的服务数导致的性能变化，16实例，缓存服务数150，16个线程发请求，在0-2400个服务之间。
将50调整为150
/arcgis/rest/services/MapService${__Random(0,2400,)}/MapServer/0/query?
先压一次让2400个服务进入缓存，再测。
调整共享实例的缓存服务数由50变为150，压测时CPU始终100%，ArcSOC.exe占用的内存无明显增长。句柄数由143300变为145700。（测完回去看看50个的句柄）
性能却出现了下降。
调大共享实例缓存的服务数为150以后性能却明显下降
2.2.猜想是SOC 最大 heapsize 64MB的限制。改为128再拿0-2400压测。请求不变，只是改了服务器配置
调大SOC Maximum heapSize
增大SOC最大堆栈内存后，性能有了一点提升
2.3.继续调大SOC最大堆栈内存为256。请求不变，只是改了服务器端配置，再进行测试。
基本无提升
基本无提升。
3.由于客观硬件条件限制，为避免出现cpu100%的情况，把共享实例池的实例数设置为8，专注于测试每个实例缓存的服务数增大带来的影响。
修改为8实例数，50缓存的服务数，和150缓存的服务数做对比。
3.1 使用8实例，50缓存的服务数，第0-1200范围的服务。8线程并发去查询，持续600秒。
减小为8实例，排除CPU瓶颈影响
查询请求
/arcgis/rest/services/MapService${__Random(0,1200,)}/MapServer/0/query?
8实例50缓存服务数随机查1200个服务的性能
3.2 使用8实例，每个实例150个缓存的服务数，第0-1200范围内的服务，8线程并发查询，持续600秒。
性能还是有所下降
4.测范围等于每个共享实例的缓存服务数，请求 0-150。为了探求150的设置 和 默认的50个服务设置的区别。
查询请求
/arcgis/rest/services/MapService${__Random(0,150,)}/MapServer/0/query?
共享实例设置
结果
充分命中缓存
到这里，结论已经很明显了。这才是全部命中缓存的性能。每个共享实例的缓存服务数要是想要充分命中，达到最大性能，所请求的服务必须在其缓存的服务数范围之内。虽然是共享实例数，但其中的每个实例的缓存的服务不一定和处理你当前请求的实例恰巧命中，推测只有1/8的概率命中缓存。
官方文档提到：
共享实例池适用于兼容的地图服务，例如：
· 不经常使用的服务。 因部署而异，但对于大多数部署来说，意味着平均每分钟的服务请求数少于一个。
· 最小专用实例数已设置为零的服务。
· 大多数缓存地图服务。
相比之下，专用实例池仍然是以下服务的最佳选择：
· 在服务级别协议下签约的服务。
· 频繁使用的服务（近乎连续请求或计算密集型请求）。
· 最小专用实例数已设置为较高值的服务。
· 与共享实例池不兼容的所有服务（请参照以上定义）。
我们对共享实例进行压测其实只是为了探究共享实例池设置参数对性能的影响，真正应对压测的还应该是专用实例的服务（适用于近乎连续请求）。中间进行16实例变成8实例的调整带来了性能提升以外让人联想到了共享实例池中的每个实例的缓存是分开的，其信息不同步。16实例减小变为8实例反而带来了性能提升其实只是由于缓存的命中率由原来的1/16增长到了1/8。
经过本次测试得出一个使用共享实例性能提升技巧的结论：如果想要充分提高共享实例的性能，可以适当减小每台机器的共享实例数，和增大每个共享实例的缓存服务数，来增加请求的服务命中实例的缓存的概率。得到最佳的性能。
网友评论