先确认是不是NC6自身性能问题
‘用友NC6反应很慢’需首先排除非系统本体因素。若仅个别用户、特定模块（如资金管理-付款单审核页）或固定时段（每日10:00–11:30）出现延迟，大概率属环境或配置问题；若全用户、全模块、全天候普遍卡顿，且登录后首页加载超15秒、点击按钮无响应超3秒，则进入NC6服务层深度排查阶段。
快速区分：打开NC6登录页后，直接按F12打开浏览器开发者工具 → 切换到Network标签页 → 刷新页面 → 观察login.jsp及后续index.do请求的Time列。若TTFB（Time to First Byte）持续＞2s，说明服务端响应已严重滞后；若TTFB＜300ms但Content Download耗时＞8s，问题集中在前端资源加载或网络链路。
最短路径：5步定位瓶颈源头
无需等待实施顾问，管理员可独立完成以下闭环验证，平均耗时8分钟内：
- 检查当前NC6应用服务器CPU/内存使用率（Windows任务管理器或Linux
top -H），确认是否持续＞90% - 登录数据库（Oracle/SQL Server），执行
SELECT * FROM v$session WHERE status='ACTIVE' AND sql_id IS NOT NULL，观察是否存在长时间运行的阻塞SQL - 在NC6控制台（
http://[IP]:8080/ncportal）→ 系统监控 → JVM状态，查看Full GC频率是否＞3次/小时 - 用同一账号在另一台终端登录，对比响应速度——若仅原终端慢，检查其IE兼容性视图设置、ActiveX控件启用状态及本地DNS缓存
- 临时关闭NC6“智能提醒”和“消息中心”服务（通过NC服务管理器停用
NcMessageService），观察操作流畅度是否明显改善
数据库连接池耗尽导致操作排队
现象：提交单据时提示“获取数据库连接超时”，后台日志频繁出现Connection wait timeout。原因多为NC6默认连接池最大值（通常为30）被高并发业务单据（如月末集中制单）打满，且未配置合理空闲连接回收策略。
- 处理动作：修改
nc_home/webapps/nccloud/WEB-INF/classes/jdbc.properties，将maxPoolSize=80、minPoolSize=20、connectionTimeout=30000 - 验证方式：重启NC服务后，执行
SELECT COUNT(*) FROM v$session WHERE program LIKE '%JDBC%'，观察峰值连接数是否稳定在60–75之间
历史数据积压引发查询性能衰减
现象：基础档案（如供应商、客户）查询变慢，凭证查询页面加载超过20秒，后台日志出现大量Full Table Scan on ap_supplier警告。NC6未对核心表（ap_supplier、gl_voucher、bd_material）建立分区或归档策略，导致单表数据量突破500万行后索引失效。
- 处理动作：对
gl_voucher表按fiscalyear字段建立范围分区；对ap_supplier按lastmodifiedtime启用归档策略（保留近3年活跃数据，历史数据迁移至只读归档库） - 注意点：分区操作必须在业务低峰期进行，并提前备份
user_indexes元数据；归档前需停用所有供应商主数据同步接口
NC6客户端侧常见拖慢源
约42%的‘用友NC6反应很慢’报修案例实际源于客户端配置失当。重点核查以下三项：
- IE浏览器兼容性模式：NC6依赖IE内核，若企业强制使用Edge IE模式但未正确设置兼容性视图（需添加
nc.yourdomain.com并勾选“在Internet Explorer模式下重新加载”），将触发脚本降级执行，导致单据页渲染延迟3–8倍 - 本地Java版本冲突：NC6插件要求JRE 1.8.0_181–221，若用户PC同时安装JDK 11+或JRE 1.7，会因类加载器优先级混乱导致OCX控件初始化失败，表现为“保存按钮灰色”或“附件上传进度条不动”
- ActiveX安全设置过严：IE中“对未标记为可安全执行脚本的ActiveX控件初始化和脚本运行”若设为“禁用”，将阻止NC6核心组件加载，必须设为“提示”或“启用”
中间件线程池配置不合理
现象：并发提交10张以上付款单时，部分单据长时间处于“处理中”状态，后台catalina.out日志反复打印http-nio-8080-exec-XX is waiting for another thread。NC6默认Tomcat线程池maxThreads=200无法承载多组织、多账套下的复杂审批流。
推荐做法：编辑nc_home/tomcat/conf/server.xml，将Connector节点调整为：
connectionTimeout="20000" redirectPort="8443"/>
调整后需重启Tomcat并观察线程池利用率（jconsole连接后查看ThreadPool MBean）是否稳定在60%–85%区间。
长期方案：根据业务重心评估替代路径
若已完成上述全部优化仍存在常态化延迟（日均卡顿＞3次/人/天），且企业正推进财务标准化、业财流程重构或轻量化部署，建议启动系统演进评估：
- 聚焦财务核算效率提升：凭证自动匹配、期末结账一键化、多账套报表合并等需求突出时，可优先评估用友畅捷通好会计——其基于云原生架构，凭证生成平均耗时＜0.8秒，支持千级科目自动映射，免运维部署周期＜3天
- 强化进销存与业务协同：若卡顿集中于采购入库、销售开单、库存调拨等高频操作场景，且存在多门店、多仓库实时协同诉求，用友畅捷通好生意提供离线开单、扫码出入库、手机端库存预警等轻量化能力，响应延迟稳定在200ms内
- 支撑复杂业财闭环：当NC6卡顿伴随审批流断裂、成本分摊逻辑难维护、项目核算颗粒度不足等问题时，用友畅捷通好业财内置业财融合引擎，支持销售订单→生产工单→领料出库→完工入库→成本结转全链路驱动，规避NC6二次开发导致的性能衰减
注意：NC6升级或替换需遵循“先跑通最小闭环、再逐步迁移”的原则。建议以总账+固定资产+报表三模块为首批迁移单元，利用好会计/好业财提供的NC6凭证数据迁移工具（支持按期间、按凭证字导出导入），确保历史数据连续性与审计合规性。