代码运行如此缓慢的5个原因以及如何修复

如果您精心设计的应用程序在部署后运行缓慢，则有五个常见原因，使其在开发计算机上运行良好，但在生产中却完全陷入了困境。

当然，还有其他原因导致您的软件在生产中无法正常运行，但这是当开发人员说“它在我的机器上运行良好”然后发现大量生产对软件的重大责任时，我看到的最主要的原因。规模问题。

[InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付 。 • CI / CD的5个常见陷阱以及如何避免它们 。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

原因1：你有一个大话题

在某些现代框架（例如Node.js ）中，可以为您处理线程 。 您应该在正确的时间进行正确的非阻塞I / O调用来执行操作，并使您的主代码行免于繁重的工作。 否则，您可能会开始使实际线程系统匮乏。

如果您有此问题，它会提出一些问题。 最基本的是：如果要在Node.js中运行的某些JavaScript内执行主要算法，那么Node.js和（gasp）JavaScript是否是在此处使用的正确技术？ 如有必要，您需要了解Node.js如何处理并发以及如何避免阻塞事件循环 。 您需要学习如何将工作提交到工作池 。 您甚至可能必须学习（加油！）有关线程的知识 。

原因2：您的数据库是！@＃$

有很多原因可导致数据库崩溃。 首先也是最明显的是缺少索引。 如果您使用的是SQL数据库，则应了解索引的工作方式。 如果您的where子句中包含三个键/值对，并使用不同的值反复运行它，则where子句可能应该是索引。 例如：

select … from customer c where c.firstname = :fname and c.lastname = :lname and c.state = :state

您可能有三个索引（并且可能有这样做的理由）。 但是，这仍然会导致索引合并-意味着必须合并三个搜索的结果。 相反，请考虑在一个索引中包括所有三个字段的索引。 所有这些都需要警告：索引的确会减慢插入和更新的速度。

另一个常见原因是您的架构完全错误设计。 我曾经在一个largeMongoDB项目中，客户在其中设计了类似于RDBMS的架构。

没有合理执行任何操作，因为MongoDB并不是为了联接表而做一些简单的事情，例如查找电话号码； 它被设计为在客户文档中具有该权限作为属性。 如果您的架构设计不正确，则您的应用程序将无法在其上正常运行。

在现代应用程序中，开发人员的偏好与数据库选择有很大关系，但并不是每个应用程序在每种类型的数据库上都表现出色：

• 如果要进行层次查询或查找两行之间的关系，则不应使用RDBMS。
• 如果您基本上是在键值存储的顶部重新实现表，请停止。
• 如果您主要是朋友（FoaF）查询，也许您需要一个图表
• 如果您要使用Foo%搜索之类的条件字段名称进行大量查询，请改用Apache Solr之类的索引（是的，这是我公司的产品）（至少对于该部分而言）。

导致数据库崩溃的另一个不太明显的原因是您也尝试打开

一次有很多连接。 例如，如果您在本地有一个数据库连接池可以打开100个连接，但是您有15个应用程序服务器都打开了100个连接，那么必须立即打开1500个连接。 可能效果不佳。 您可能一次需要这样做。 您的操作人员应该了解这一点，以及如何限制在给定时间到达应用服务器的流量（如何启动“热”而不是“热”）。

如果性能问题是数据库，则应该可以使用数据库监视工具找到它们，方法是记录查询返回时间，或者通过听DBA告诉您数据库无法处理所有这些连接。

了解您要写入的数据库以及它在架构和实践方面的特点。 选择适合该作业的一个或多个数据库。

原因3：您没有正确调整内存大小

大多数现代商业软件都在某种基于堆栈的虚拟机上运行。 我说的不是VMware或Docker ，而是像Java虚拟机（JVM）。 在不详细介绍虚拟机内部工作原理的情况下，几乎所有虚拟机都需要您专用于一定数量的内存（称为堆）。 他们每次启动线程时也会使用其他类型的内存。 如果它们的堆内存不足，他们将在内存管理上花费更多的时间，这看起来（直到崩溃和刻录）就像应用程序变慢了。

在JVM上，您可以打开垃圾收集日志记录，这将向您显示正在运行多少个收集。 您也可以增加堆大小，但是要明智地这样做。

许多人认为堆是唯一的内存类型，但是还有JVM的-xss堆栈大小选项。 每个线程都会获得一定数量的堆栈内存。 如果

System Memory – (heap + otherstuff + (numthreads * numstack)) i<= 0

然后，当您抓住另一个线程时，将引发一种特殊的内存不足异常。 根据您所运行的库的类型，可能是一个没有扩展的线程池或一个没有扩展的数据库连接池，两者看上去都像是速度变慢了。 好消息是，这是在任何日志中捕获的。

原因4：您调整线程或连接池的大小不正确

如果池中有1,000个并发用户和五个数据库连接，则可能在该池中有一个等待条件。 如果您有100个HTTP线程，TCP backlog设置为5，则在105个人尝试连接后，您将看到“连接被拒绝”的消息，但是在此之前情况会变得很慢。 此外，某些软件具有许多“接受”线程，它们基本上是“接听电话并将其交给其他线程之一”。 通常有一个，也许两个。

对于这些数字的大小没有严格的规定，但是在比例上是合理的。 在执行此操作时，还请记住原因3，因为您可能会遇到其他限制。

原因5：您没有正确设置限制和文件句柄

大多数操作系统对允许操作系统用户打开的线程和文件数量有限制 。 如果您在此极限下运行，事情就会变慢，然后才失败。 您应该在日志中看到它，并且有一些工具可以显示正在使用的文件锁和句柄。

From: https://www.infoworld.com/article/3277526/5-reasons-why-your-code-is-running-so-slowlyand-how-to-fix-it.html