NetSuite 为什么这么慢？

Gartner 估计 IT 停机成本为每分钟 9,000 美元。至少对大型企业来说是这样。如果你认为这个数字听起来很糟糕，ITIC 的 2024 年研究表明情况变得更糟了：超过 90% 的中型和大型公司在系统出现故障时每小时会损失超过 300,000 美元。

再读一遍。

所以当你的 NetSuite 实例需要 15 秒来保存销售订单，或者仪表板每天早上似乎要旋转很长时间时，你不仅仅是感到烦恼。你实际上在亏损。你的财务团队陷入困境。运营部门感到沮丧。在某个地方，有人认真考虑整个 ERP 是否是个错误。

但这里是令人不适的事实：这并不总是 NetSuite 的错。嗯……至少不是核心平台的错。

性能瓶颈的三个位置

服务器是 NetSuite 进行处理的地方。这是 Oracle 的基础设施，但也包括每个在加载页面或保存记录时触发的脚本、工作流和计算。如果你的服务器时间很高，你的自定义堆栈中的某些内容可能在消耗处理周期。

网络是你和 NetSuite 数据中心之间的管道。你的互联网连接、你的 VPN、你的企业防火墙检查每个数据包。如果网络时间占主导地位，那就不是 Oracle 的问题。

客户端是你的浏览器、你的机器、你的扩展程序。NetSuite 在浏览器中运行，浏览器可能很慢。旧笔记本电脑、装有 47 个扩展的 Chrome、三周没有重启的机器（因为 Windows"快速启动"将所有内容保留在内存中），等等。这些都会累积起来。

当 NetSuite 运行缓慢时，通常是这三个原因之一——有时是两个，偶尔是全部三个。第一步是找出你实际面对的是哪个问题。

如何准确看到什么在拖累系统

NetSuite 提供了一个内置诊断工具，大多数人不知道存在。双击任何页面左上角的 Oracle NetSuite 徽标。

性能详情窗口会弹出。它显示页面加载耗时，按服务器时间、网络时间和客户端时间分解。根据你的版本，你可能还会看到按组件分解的服务器端执行情况。

如果服务器时间占总时间的 70% 或以上，你有自定义技术债。如果网络是罪魁祸首，与你的 IT 团队讨论你的连接。如果客户端时间较高，可能是时候清除你的缓存、重启机器或放弃一些浏览器扩展。

在做任何其他事情之前，检查你的性能详情。

没有人想承认的脚本问题

我们见过 NetSuite 实例，其中单个记录类型附加了 25 个脚本和 10 个工作流。每次有人打开该记录，每次他们保存它，所有这些自动化都会触发。其中一些可能做同样的事情。其中一些是多年前由已经离职的顾问编写的。现在没有人知道其中一半做什么了。

这被称为自定义技术债，它是 NetSuite 性能的无声杀手。

检查你的脚本部署（自定义 > 脚本 > 脚本部署）和工作流列表（设置 > 工作流 > 工作流），以查看哪些记录类型附加了最多的自动化。如果你发现一条记录在脚本和工作流组合中有两位数的计数，那就是你开始的地方。

修复并不总是很有趣。你需要真正了解 SuiteScript 的人去查看这些部署，找出哪些是冗余的，并进行整合。九个工作流做重叠的事情通常可以变成两个。但你无法修复看不见的东西，这个页面向你确切展示了问题所在。

服务层升级的神话

NetSuite 有服务层：Standard、Premium、Exclusive。一些客户假设如果他们为更高的层付费，NetSuite 就会运行更快。更多的钱，更多的服务器，更好的性能。合理，对吧？

不幸的是，事实并非如此。

更高的层通常会为你提供更多的存储空间、更多的并发 API 连接，有时还有更好的支持 SLA（用户许可证根据你的合同单独购买）。并发限制在你有集成竞争带宽时很重要。但如果你希望 Premium 层能让你的已保存搜索加载得更快，你几乎肯定会失望。

我们见过公司花费数千美元升级他们的层，只是发现日常性能没有明显差异。缓慢一直在他们的脚本中。在你真正诊断问题之前，存下你的钱。

隐藏的 5 秒税

当我们第一次遇到这个时，它让我们感到惊讶。

去年，一个客户带着全新的 NetSuite 实施来找我们。没有遗留脚本，没有工作流意大利面，干净的系统。但每次他们在采购订单上选择供应商时，页面需要五秒才能响应。没有旋转轮，只是……等待。

罪魁祸首是源字段。他们在子公司记录上有自定义字段，想在交易中显示。为了实现这一点，他们创建了根据供应商的分配从子公司获取数据的交易正文字段。

完全合理的方法。也是性能杀手。

交易单据上的每个源字段都会增加延迟。你要求 NetSuite 在每次选择供应商或客户时去查找相关记录中的数据。我们见过单个单据上几个源字段添加了多秒供应商选择的情况 - 影响因配置而异，但它会复合。

修复方法是审计你的交易单据并询问每个源字段是否真的有必要。有时你可以将该信息移动到不同的上下文。有时你只需要接受没有它。但如果你的交易很慢，你已经排除了脚本，检查你的源字段。

你今天可以做的快速获胜

在你引入顾问（或我们）或向 NetSuite 支持开工单之前，试试这些：

• 清除你的浏览器缓存。NetSuite 在本地缓存大量数据，有时该缓存会过期或损坏。打开隐身窗口，看看相同的页面是否加载更快。如果是这样，清除你的常规浏览器缓存。
• 重启你的计算机。Windows 快速启动即使在你"关闭"时也会将进程保留在内存中。你的浏览器和在其中运行的任何客户端脚本正在处理已累积的任何垃圾。真正的重启（按住 Shift 同时点击关闭，或使用重启）会清除这些。
• 检查你的扩展程序。浏览器扩展在每个页面上运行，包括 NetSuite。如果你同时运行了广告拦截器、密码管理器、生产力工具和谁知道还有什么，他们正在竞争资源。
• 你的重型流程是否与用户竞争？大型数据导入、批量更新、复杂报告。这些应该在晚上或清晨运行，而不是在下午 2 点每个人都试图使用系统时。不要让每个人都与百万条记录的 CSV 导入竞争。

何时寻求帮助

有时问题比你在内部能够修复的要深得多。

如果你检查了你的性能详情，服务器时间一直很高，如果你审计了你的脚本部署和工作流并发现了重叠的自动化，如果你尝试了快速获胜但没有改变……你可能正在处理需要专家关注的架构问题。

NetSuite 的 APM SuiteApp 提供了对脚本执行时间、页面加载模式和系统健康随时间变化更深入的可见性。它作为 SuiteApp 下载提供（检查你账户的访问权限），值得安装，即使你没有危机也只是为了建立基线。

但如果你被自定义技术债淹没，没有内部专业知识来解决它，那就是你需要性能审计的时候。有人可以查看你的整个配置，确定什么在拖累你，并构建补救计划。

停止等待

缓慢的 NetSuite 几乎从不是个谜。诊断工具存在。常见原因是众所周知的。脚本、工作流、源字段、网络问题、客户端臃肿。通常是其中之一，通常是多个。

你可以继续看那个轮子旋转，或者你可以做些什么。

如果你厌倦了等待，如果你担心那个缓慢正在以生产力和士气成本给你造成什么，我们可以帮助你。我们的 NetSuite Health Check 深入挖掘你的配置，识别瓶颈，并为你提供通往更快系统的清晰路径。

因为没有人应该仅仅为了保存一个销售订单就花 15 秒看旋转轮。