SuperMap发布三维服务?切片缓存性能咋优化?

wowwwai GIS研习社 · 工具流程与项目排障

在实际项目里，很多同学都会遇到“SuperMap发布三维服务?切片缓存性能咋优化?”这个问题：iServer 上服务能发布出来，但三维场景打开慢、首次加载白屏久、倾斜摄影或 BIM 模型切片请求数量巨大，服务器 CPU、磁盘 I/O 和网络带宽很快被打满。

本文以 SuperMap iServer 发布三维服务后的切片缓存性能优化为主线，重点讲清楚三维切片缓存为什么会慢、应该从数据、缓存、服务、服务器和前端加载几个层面怎么排查。适合正在使用 SuperMap iDesktop、SuperMap iServer、SuperMap iClient3D for WebGL 或 SuperMap 三维场景服务的 GIS 工程师参考。

引言：SuperMap发布三维服务后为什么会卡

SuperMap 三维服务卡顿，通常不是“发布服务”这一步本身的问题，而是三维数据体量、切片层级、缓存存储、服务并发、网络传输和前端渲染共同作用的结果。

常见现象包括：

• 三维场景首次打开很慢，长时间停留在空白或低精度模型。
• 倾斜摄影数据加载到一定范围后明显卡顿。
• 浏览器开发者工具里可以看到大量切片请求排队。
• iServer 所在机器磁盘读写很高，但 CPU 并不一定满载。
• 局域网访问正常，公网访问三维服务明显变慢。
• 同一份数据在小范围测试没问题，发布到全市、全园区或全矿区范围后性能急剧下降。

优化 SuperMap 三维服务切片缓存性能，不能只看一个参数。更合理的思路是：先确认数据和缓存是否合理，再检查 iServer 服务配置，最后优化前端加载策略和服务器资源。

背景：三维服务、三维切片缓存和前端加载的关系

在 SuperMap 体系中，三维数据通常会经过数据处理和缓存生成，再通过 SuperMap iServer 发布为三维服务，最后由 SuperMap iClient3D for WebGL 或其他三维客户端进行加载。

这里有三个关键概念需要区分：

• 三维数据源：例如倾斜摄影模型、BIM、精模、地形、影像、矢量图层等原始或处理后的数据。
• 三维切片缓存：为了让大体量三维数据可以分级、分块加载而生成的缓存文件，例如 S3M 相关缓存。
• 三维服务：iServer 对外发布的访问接口，客户端通过请求服务地址获取场景、图层和切片资源。

如果三维切片缓存本身层级过深、瓦片过碎、纹理过大，后续即使服务器配置很高，也很难获得理想性能。反过来，如果缓存设计合理，但 iServer 部署在低 I/O 磁盘或带宽不足的环境中，也会出现三维服务加载慢的问题。

原理：SuperMap三维切片缓存性能主要受哪些因素影响

SuperMap发布三维服务的性能，本质上取决于“客户端在当前视角下需要请求多少切片、每个切片多大、服务器能多快返回、浏览器能多快解析和渲染”。可以拆成以下几个方面。

1. 切片层级和空间范围

三维切片通常按不同细节层级组织。视角越近，请求的高精度切片越多；范围越大，需要参与调度的切片也越多。

如果缓存层级过细，客户端会产生大量小文件请求；如果层级过粗，单个切片文件过大，首次加载和解压解析时间会变长。因此切片缓存性能优化的核心之一，就是让切片层级与实际浏览尺度匹配。

2. 模型复杂度和纹理大小

倾斜摄影、BIM 和精细化模型常见问题是面数高、纹理多、贴图分辨率大。即使缓存服务返回很快，浏览器端也可能因为 GPU 压力过大而掉帧。

如果用户主要用于城市级浏览，没有必要在远距离就加载过高精度模型。应通过模型简化、LOD 层级和纹理压缩来控制负载。

3. 缓存存储介质

三维切片缓存通常包含大量文件。机械硬盘在大量随机读场景下容易成为瓶颈。SSD、NVMe、本地高速磁盘通常比普通网络盘更适合承载三维缓存。

如果缓存目录放在共享盘、低速 NAS 或云盘挂载目录上，iServer 响应可能会被磁盘 I/O 拖慢。

4. iServer 并发和 JVM 资源

SuperMap iServer 运行在 Java 环境中。并发请求较高时，线程、内存、连接数、垃圾回收都会影响服务稳定性。三维切片文件请求数量多，尤其容易暴露服务端并发配置不足的问题。

5. 网络传输和浏览器请求限制

WebGL 三维场景会连续请求大量资源。公网访问时，带宽、延迟、HTTP 压缩、浏览器并发连接数、代理服务器缓存策略都会影响加载速度。

如果前端页面和 iServer 不在同一个网络区域，跨网访问会进一步增加延迟。

步骤：SuperMap发布三维服务切片缓存性能优化流程

步骤一：先判断瓶颈在数据、服务端还是前端

不要一开始就调整服务器参数。建议先做一个简单定位：

1. 在 iServer 所在服务器本机访问三维服务，观察加载速度。
2. 在同一局域网客户端访问，观察是否明显变慢。
3. 在公网或业务用户网络访问，观察是否继续变慢。
4. 打开浏览器开发者工具，查看三维切片请求数量、单个请求耗时和失败请求。
5. 打开服务器监控，观察 CPU、内存、磁盘 I/O、网络带宽。

判断逻辑可以这样看：

• 本机访问也慢：优先检查三维缓存、磁盘 I/O、iServer 配置。
• 本机快、局域网慢：重点检查网络、带宽、防火墙和代理。
• 服务返回快但页面卡：重点检查前端渲染、模型复杂度、显卡性能。
• 请求大量 404 或失败：重点检查缓存路径、服务发布路径和资源引用。

步骤二：优化三维数据再生成缓存

三维服务性能优化最有效的动作，往往发生在发布服务之前。建议对数据做以下处理：

• 删除无用模型、重复模型、隐藏构件和业务上不需要的细节。
• 对 BIM 或精模进行轻量化处理，减少构件数量和三角面数量。
• 对倾斜摄影数据检查空洞、重叠、异常纹理和坐标偏移。
• 控制纹理分辨率，避免大量超大贴图进入缓存。
• 根据实际业务视距设置合理的 LOD 层级。
• 按区域、楼栋、地块或项目边界拆分大型数据集。

如果原始数据非常重，直接发布三维服务后再调 iServer，通常只能缓解，不能根治。

步骤三：合理设置三维切片缓存层级

生成三维切片缓存时，要根据实际应用场景选择层级和精度。比如：

• 城市级三维浏览：优先保证中远距离快速加载，不宜过早加载高精度细节。
• 园区级管理：需要兼顾建筑外观和局部细节，可按园区范围设置精度。
• 室内 BIM 查询：需要构件级操作，但应避免一次加载完整超大 BIM。
• 倾斜摄影浏览：重点控制瓦片大小、纹理大小和层级切换。

检查缓存是否合理，可以关注两个指标：

• 单个切片文件是否过大：过大会导致等待时间长，尤其在公网环境下明显。
• 切片文件数量是否过多：过多会导致浏览器请求排队和服务器随机读压力变大。

如果出现“文件又多又大”的情况，通常说明源数据轻量化不足或切片参数不合理，需要回到数据处理阶段重新优化。

步骤四：把三维缓存放在高性能存储上

SuperMap 三维切片缓存对磁盘随机读较敏感。建议：

• 优先使用 SSD 或 NVMe 磁盘存放三维缓存目录。
• 避免把高访问量缓存放在普通机械硬盘上。
• 避免把缓存目录放在不稳定或延迟较高的网络共享路径。
• 缓存目录和系统盘尽量分离，避免系统日志、数据库、临时文件争抢 I/O。
• 对多项目缓存进行目录分层管理，便于迁移、备份和排查。

如果项目条件允许，可以将热点三维缓存部署到更靠近用户的服务器或缓存节点，减少跨区域访问延迟。

步骤五：检查 iServer 服务发布和资源路径

发布 SuperMap 三维服务后，应检查服务是否正常引用缓存资源：

1. 登录 iServer 管理页面，确认三维服务处于正常运行状态。
2. 检查三维场景服务地址是否能正常访问。
3. 检查三维图层对应的缓存目录是否存在且权限正确。
4. 在浏览器开发者工具中查看是否有 404、403、500 等错误。
5. 确认反向代理或网关没有错误改写服务路径。

如果三维服务在内网地址正常，但通过域名访问异常，要重点检查代理配置、跨域设置、端口映射和上下文路径。

步骤六：调整 iServer 并发和运行资源

当切片缓存和数据本身已经合理，但访问人数增加后仍然变慢，可以考虑服务端资源优化。

• 为 iServer 分配足够内存，避免高并发下频繁垃圾回收。
• 根据服务器 CPU 和访问压力调整并发处理能力。
• 避免在同一台机器上同时运行高负载数据库、影像服务、三维服务和分析任务。
• 将高访问量三维服务与后台处理任务分离部署。
• 使用系统监控工具持续观察 CPU、内存、磁盘 I/O 和网络带宽。

需要注意，iServer 参数调整应结合具体版本和部署文档操作，不建议盲目复制其他项目的 JVM 参数。不同数据规模、访问量和硬件环境下，最优配置并不相同。

步骤七：前端 WebGL 加载策略也要优化

很多 SuperMap 三维服务加载慢，最后瓶颈其实在前端。前端页面应避免“一打开就加载所有内容”。

建议的前端策略包括：

• 按业务需要分图层加载，不要默认加载所有三维图层。
• 远距离隐藏高精度模型，靠近后再显示细节图层。
• 按行政区、园区、楼栋或专题开关控制三维数据加载。
• 关闭不必要的动态效果、阴影、后处理和高频刷新。
• 对查询、定位、飞行路径等操作设置合理的加载范围。
• 在低性能电脑上提供简化模式或低精度图层。

如果用户只是查看宏观范围，不应让浏览器加载完整 BIM 构件级数据。三维场景越复杂，越需要“按需加载”。

步骤八：使用浏览器开发者工具验证优化效果

优化后不要只凭感觉判断，应通过浏览器开发者工具进行验证：

1. 打开三维页面，进入网络请求面板。
2. 刷新页面，观察首次加载请求总数和总耗时。
3. 查看三维切片资源是否存在大量等待、失败或重复请求。
4. 切换视角，观察新增切片请求是否稳定返回。
5. 进入性能面板，检查是否存在明显长任务和渲染卡顿。

如果服务端响应时间已经下降，但帧率仍然低，说明下一步应继续做模型轻量化和前端渲染优化，而不是继续增加服务器配置。

常见坑：SuperMap三维服务切片缓存优化容易忽略的问题

坑一：把所有问题都归因于 iServer

iServer 是服务发布和访问入口，但三维性能不是只由 iServer 决定。数据过重、缓存不合理、磁盘太慢、前端一次加载太多，都可能让三维服务看起来“很慢”。

坑二：缓存目录放在低速网络盘

三维切片缓存包含大量文件。低速网络盘在随机读取时延迟较高，容易导致请求排队。生产环境应优先使用本地高速磁盘或经过验证的高性能存储。

坑三：三维模型没有做轻量化

BIM 和精模如果直接发布，常常包含大量业务无关构件。比如螺丝、管线细节、室内隐藏构件等，在普通三维浏览中并不需要全部加载。

坑四：切片层级追求越精细越好

层级越精细不等于性能越好。过细会增加切片数量和请求数量，过粗又会导致单文件过大。应根据浏览距离和业务需求设置合理层级。

坑五：前端默认加载全部图层

很多项目把倾斜摄影、地形、影像、BIM、管线、专题符号全部默认打开。这样不仅加载慢，也会降低交互帧率。更好的方式是按业务场景分组加载。

坑六：只在内网测试，不做真实用户网络测试

内网访问快，不代表公网访问快。三维服务上线前应使用真实用户网络、真实浏览器和真实硬件进行测试，尤其要关注带宽、延迟和显卡性能。

方法比较：不同优化手段适合解决什么问题

优化方法	主要解决的问题	适用场景	注意事项
模型轻量化	模型过重、浏览器渲染卡顿	BIM、精模、倾斜摄影	要保留业务必要细节，避免过度简化
重新生成三维切片缓存	切片层级不合理、文件过大或过碎	缓存设计不佳、范围过大	需要重新评估浏览尺度和精度需求
更换高速磁盘	磁盘随机读慢、请求排队	大量三维切片文件访问	优先使用 SSD 或 NVMe，并监控 I/O
iServer 资源调优	并发访问慢、内存不足、服务不稳定	多用户访问、生产环境	应结合版本文档和监控数据调整
前端按需加载	首次加载慢、图层过多、帧率低	WebGL 三维应用	需要和业务功能设计结合
网络与代理优化	公网慢、跨区域访问慢	外网发布、跨地市访问	检查带宽、缓存策略、跨域和代理路径

如果只能优先做一件事，建议先看数据和缓存。因为三维数据本身过重时，后续所有环节都会被拖累。

检查清单：发布前后逐项排查切片缓存性能

数据处理检查

• 是否删除了无用模型、重复模型和隐藏构件？
• 是否对 BIM、精模或倾斜摄影做了轻量化？
• 纹理大小是否符合业务需求，是否存在超大贴图？
• 坐标系、单位、高程基准是否正确？
• 是否按区域或业务单元拆分了超大数据？

缓存生成检查

• 三维切片缓存层级是否与浏览尺度匹配？
• 是否存在单个切片文件过大的情况？
• 是否存在切片文件数量异常过多的情况？
• 缓存目录结构是否清晰，便于迁移和维护？
• 是否在测试环境验证过缓存加载效果？

iServer 发布检查

• 三维服务是否正常启动？
• 服务地址是否能在浏览器中正常访问？
• 缓存目录权限是否正确？
• 是否存在 404、403、500 等请求错误？
• 反向代理、域名、端口和上下文路径是否一致？

服务器资源检查

• CPU 是否长期满载？
• 内存是否不足或频繁触发回收？
• 磁盘 I/O 是否成为瓶颈？
• 网络带宽是否接近上限？
• 三维服务是否与其他高负载服务混跑？

前端加载检查

• 页面是否默认加载了所有三维图层？
• 是否按视距、范围或业务开关加载图层？
• 是否存在大量重复请求或失败请求？
• 低性能电脑是否有简化模式？
• 浏览器端是否出现明显 GPU 或渲染瓶颈？

FAQ：SuperMap发布三维服务和切片缓存优化常见问题

1. SuperMap发布三维服务后第一次打开慢，正常吗？

第一次打开慢比较常见，因为客户端需要请求场景配置、图层信息和初始视角范围内的三维切片。但如果每次打开都很慢，或者切换视角后持续卡顿，就需要检查切片缓存、磁盘 I/O、网络和前端加载策略。

2. 三维切片缓存是不是越精细越好？

不是。三维切片缓存要和应用场景匹配。城市级浏览不需要在远距离加载构件级细节；BIM 构件查询也不应该一次加载全域高精度数据。过精细会增加请求数量和渲染压力。

3. 为什么局域网访问很快，公网访问 SuperMap 三维服务很慢？

公网访问受带宽、延迟、代理、跨区域链路和浏览器请求限制影响更明显。应检查三维切片文件大小、请求数量、服务器出口带宽、反向代理缓存策略以及用户侧网络质量。

4. 提高服务器 CPU 能解决三维服务卡顿吗？

不一定。如果瓶颈在磁盘随机读、网络带宽或浏览器渲染，提高 CPU 效果有限。建议先通过监控确认瓶颈位置，再决定是升级 CPU、内存、磁盘还是优化数据和前端。

5. 倾斜摄影三维服务加载慢，优先查什么？

优先查三项：源数据是否过重，三维切片缓存是否合理，缓存目录所在磁盘是否足够快。倾斜摄影数据体量通常较大，如果纹理和层级没有控制好，很容易造成请求多、文件大、渲染慢。

6. BIM 发布成三维服务后特别卡，怎么处理？

建议先做 BIM 轻量化。删除业务无关构件，按专业、楼层或楼栋拆分，控制构件数量和纹理资源，再生成适合 Web 端加载的三维切片缓存。不要把完整设计级 BIM 原样用于普通 Web 三维浏览。

7. 是否需要使用 CDN 优化 SuperMap 三维切片缓存？

如果用户分布广、访问量高、切片资源相对静态，可以考虑静态资源缓存或边缘分发方案。但在实施前要确认服务授权、资源路径、缓存更新策略和安全访问要求，避免缓存不一致或访问失败。

8. 如何判断是服务端慢还是前端渲染慢？

可以看浏览器开发者工具。如果切片请求返回时间很长，偏向服务端、磁盘或网络问题；如果请求返回较快但画面仍然掉帧，偏向模型复杂度、显卡性能或前端渲染问题。

结论：优化SuperMap三维服务要从缓存链路整体入手

SuperMap发布三维服务后的切片缓存性能优化，不是单独修改某个按钮或参数就能完成的工作。正确做法是沿着“数据处理、缓存生成、iServer 发布、服务器资源、网络传输、前端加载”这条链路逐项排查。

对于大多数项目，优先级建议是：先做三维数据轻量化，再检查三维切片缓存层级和文件大小，然后把缓存放到高性能磁盘，最后结合 iServer 并发、网络环境和前端按需加载策略继续优化。

如果你在项目中遇到 SuperMap 三维服务加载慢，不要只问“服务器配置够不够”，而要先问三个更关键的问题：数据是否足够轻、缓存是否足够合理、客户端是否只加载了当前需要的数据。把这三点做好，三维服务的稳定性和加载体验通常会有明显改善。