可以做哪些典型的硬件改进来提高Web应用程序的性能？

Question

我们在Tomcat8.5中运行了一个基于Ajax的Java /Hibernate应用程序。该应用程序的性能是可以接受的，但不是闪电般的速度。一个典型的插入记录需要3-4秒。

05 Nov 2019 14:55:41,686 INFO  Insert Start
...
05 Nov 2019 14:55:45,766 INFO  Insert End

我们有所有标准的东西，比如DB索引等等。它们都在工作。

没有人抱怨，但它不是像StackOverflow.com这样的超级流畅的网络应用程序。StackOverflow速度如此之快，所有操作都需要不到2秒的时间。

哪些硬件改进可以将Web应用程序提升到更高的水平？

• DB:增加DB服务器上的内存和CPU？但有人告诉我这不会有帮助的。
• 增加JVM堆大小？已完成: 2GB
• 猫盒硬件-内存和CPU？

我现在了解的另一件事是Hibernate (和类似的ORMs)对于执行程序来说是个坏主意。它们很受欢迎，但如果没有它们，应用程序会有更多的性能提升。

Answer 1

在将性能问题归咎于Hibernate之前，您应该分析应用程序。通过分析给定的请求(如果整个应用程序感觉缓慢，只需接受任何请求)，您就可以更准确地了解什么是慢的。根据您的发现，改进性能的解决方案将完全不同。下面是一些例子：

• 请求正在执行四个请求，然后第五个请求执行了三千次，因为一些开发人员误解了评估是多么的懒惰。通过修改代码，请求的数量可以减少到5个。(这个例子实际上来自几年前我审计过的一个实际应用程序。)
• 请求要求从数据库获取太多内容；本质上，当需要一个条目时，它只是加载包含大约50万项的整个表，然后在其中进行搜索。(不出所料，这个例子来自于前面提到的同一个项目。)
• 请求花费时间使用CPU。如果是这样的话，分析将确定使用CPU时间的位置。从那里，您可以开始优化您的应用程序。
• 请求经常使用内存。检查数据结构。
• 该请求向其他服务发出其他请求。检查为什么，如果是这样的话，其他服务需要太长时间才能做出响应。
• 即使在执行一些非常基本的查询时，请求也会对数据库进行大量等待，而数据库则驻留在功能非常强大的硬件上。检查应用程序服务器和数据库服务器之间的连接。(例如，在美国托管应用服务器，在印度托管数据库服务器，在性能方面不是最好的事情。)
• 请求执行大量磁盘写入操作。检查到底记录了什么:记录大量日志，忘记生产中的“详细”日志级别不是一个好主意，特别是如果日志配置为将每条消息都刷新到磁盘上。(在一个项目中发生过一次，当时一位程序员想要调试生产中一个奇怪的崩溃，一旦问题解决了，就忘记了重置日志配置。)

这些只是少数几个例子，可能会发生在罩下。同样，在尝试优化之前，您必须精确地找出导致缓慢的原因，特别是如果您唯一的优化想法是切换到另一种技术或要求更昂贵的硬件。一旦您找到了瓶颈，您可能会找到解决它的方法。这可能是代码或配置中的简单更改。也许你需要更昂贵的硬件。

还有几个项目中的一些轶事：

• 很久以前，一个程序员团队开发了一个web应用程序。它有点慢，客户担心它的性能。因为其中一个人读了很多关于并行计算好处的文章，所以团队决定以这种方式优化这个应用程序。然后，他们花了几个月的时间修复出现的错误，这些错误是在代码并行运行时出现的，这段代码从来不是用于多线程的。不幸的是，表现并没有改善。在过去的六个月里，这些家伙抱怨他们没有应有的硬件，他们利用这个机会获得了八核处理器，取代了旧的四核处理器，但是应用程序似乎变得更慢了。最后，另一个团队的开发人员想出了办法。问题不是CPU，而是内存(特别是因为大量不必要的内存分配)。然而，当应用程序被移动到八核CPU时，应用程序也被重新配置，因此它花费了更多的时间来创建线程和线程之间的通信，使得它确实变得更慢。
• 我的一个项目非常慢，而应用程序甚至不用那么多CPU或内存:即使是一个简单的“Hello”请求也需要大约两秒钟的时间。过了一段时间，我发现问题是由于应用程序中的一个bug，加上一个完全疯狂的IIS配置，迫使IIS在每次请求之后循环应用程序池，使应用程序变得非常笨拙。修复错误和正确设置配置有助于将请求减少到几十毫秒。

Answer 2

你可能不会喜欢这个答案，但是.从4秒到2秒可能需要一次架构大修。本质上，这可能和在Tomcat8.5中运行的Java /Hibernate应用程序的速度一样快。

示例：

IIS应用程序在ASP.NET和Server上运行:每页4至7秒。

在IIS和Server上运行的相同的应用程序(就像堆栈溢出一样)：每页1到3秒。

Answer 3

调试性能问题的第一步是了解体系结构中的瓶颈。在单块应用程序(即传统的n层开发)中，您有几个潜在的瓶颈：

• CPU负载
• 内存利用
• 网络带宽
• 磁盘速度

如果您的应用程序需要花4秒时间来响应请求，那么请查看这三件事情，找出什么是最大的。每个项目可能有不同的原因：

• CPU最高值：
  • 通过在分析器中寻找热点来寻找效率低下的算法
  • 将您的CPU增加到一个更快的模型(今天这个选项非常有限)

• 内存最大值：
  • 确保您没有交换到磁盘，这是非常慢的。
  • 增加JVM或服务器的内存
  • 使用内存分析器查找内存泄漏(即在垃圾收集之后没有回收的内存)。

• 网络上限：
  • 再加一张网卡？
  • 如果在VM环境中，将您的数据库VM与您的应用VM配置起来，以利用高速的VM网络。

• 磁盘最大值：
  • 确保数据库中有索引，以防止全表扫描。
  • 尽量减少磁盘的使用
  • 获得更快的磁盘(SSD可能值得投资，或者使用RAM磁盘作为临时文件)

如果所有这些都没有达到最大值，而且仍然存在性能问题，那么很有可能您会受到资源锁定的影响。如果一个人正在更新一个表，而另一个人正在查询该表，则有可能更新记录(S)会导致另一个人等待。如果您能够处理脏读取，则可以减少数据库中的锁定开销。

更大的枪炮

在一个单一的环境中，你将不可避免地遇到更大的硬件所能达到的极限。在这一点上，你真的需要考虑扩大规模。堆栈溢出可以使系统扩展并保持性能。您可以选择一个完整的微服务路线，或者只在多台服务器上托管您的单块应用程序。

您必须努力实现扩展的主要目的是完全避免服务器端会话。在“无共享”环境中，没有理由有服务器会话。进入会话变量的信息要么进入数据库，要么存储在浏览器的前端代码中。

您会想要开始使用集群。具有多个集群节点的数据库可以将工作分散到每个节点，以平滑负载。这组应用服务器可以简单地承载应用程序的额外副本，并在前面使用一个负载均衡器。不需要任何会话亲和力，您可以使用简单的循环平衡，这是快速的。

接下来，您将需要查看缓存服务器，如Redis或其他类似的服务器。如果您的资源需要时间整合，但不要经常更改，这是使响应时间非常快的最后一块拼图。

如果你想到网络上的任何快速响应站点，我保证他们已经投入了大量的资金来扩大规模，而不是扩大规模。他们这样做的程度与每个环境都有很大的不同。例如，Stack能够在其核心上使用混合单块体系结构做很多事情，但是它们在9种不同的web服务器(参考文献)上托管。

底线是，当您投资于扩展所需的更改类型时，它会花费大量的精力，而您的日常托管成本也会增加。