Log4j2 漏洞检测工具名单
发布时间：2022-02-11 11:45:55 所属栏目：安全 来源：互联网
导读：凡事都有其限度，对吧?汽车只能开这么快，进程只能使用这么多内存，程序员只能喝这么多咖啡。我们的生产力受到资源的限制，我们有能力更好或更差地利用它们。尽可能接近其极限使用我们的每一种资源是我们的目标，我们希望使用我们的 CPU 和内存的每一点，
|
凡事都有其限度，对吧?汽车只能开这么快，进程只能使用这么多内存，程序员只能喝这么多咖啡。我们的生产力受到资源的限制，我们有能力更好或更差地利用它们。尽可能接近其极限使用我们的每一种资源是我们的目标，我们希望使用我们的 CPU 和内存的每一点，否则我们会为昂贵的机器多付钱。 然而，若是我们使用了过多的资源，我们就有可能导致性能问题、服务不可用问题和程序宕机底崩溃问题。软件开发看似简单，但一旦遇到性能问题，就会变得非常棘手，这就是我们今天要讨论的内容。 定义最佳基准 让我们尝试描述我们的最佳应用程序行为。假设我们有许多服务器机器需要处理高吞吐量的请求。为简单起见，让我们暂时忘记高峰时间或周末。我们的服务器负载在一天中的所有时间都或多或少相同。我们为这些服务器机器支付了很多钱，我们希望从它们那里获得尽可能多的价值，这意味着处理尽可能多的请求。按照我们对简单性的承诺，我们还假设服务器仅使用内存和 CPU 来处理所述请求，并且没有其他瓶颈，例如慢速网络或锁争用。 在所描述的场景中，我们的最佳行为是在任何给定时间使用尽可能多的 CPU 和内存，对吗?这样，我们可以用更少的机器来处理相同数量的请求。但是您可能不想利用这些资源中的 99.9%，因为负载的轻微增加可能会导致性能问题、服务器崩溃、数据丢失和其他令人头疼的问题。所以我们应该选择一个有足够缓冲问题的数值。平均 85% 或 90% 的 CPU 和内存利用率听起来是正确的。 我们应该首先优化什么? 我们的应用程序不是为平等利用 CPU 和内存而构建的。或者到它托管的机器的确切限制。因此，您首先应该查看的是您的服务器是CPU-bound还是Memory-bound。当服务器受 CPU 限制时，这意味着服务器可以处理的吞吐量受到其 CPU 的限制。换句话说，如果您尝试处理更多请求，CPU 将在其他资源(如内存)达到其限制之前达到 100%。同样的逻辑也适用于Memory-bound服务器。服务器的吞吐量将受到它可以分配的内存的限制，当尝试处理更多负载时，在其他资源(如 CPU)达到其限制之前，该内存将达到 100%。 一旦你知道是什么限制了你的服务器的性能，你就会知道首先要尝试和优化什么。如果您的服务器受 CPU 限制，那么优化内存使用没有意义，因为它不会提高处理的吞吐量。事实上，它可能会损害吞吐量，因为您可能会因为更多的 CPU 利用率而提高内存使用率。对于内存受限的服务器也是如此，在这种情况下，您应该在查看 CPU 之前优化内存使用。 测量 .NET 服务器中的 CPU 和内存消耗 CPU 和内存的实际测量最简单的是使用Performance Counters[1]完成。CPU 使用率的指标是Process | % 处理器时间。内存有几个指标，但我建议查看Process | 私有字节。您可能还对.NET CLR 内存感兴趣 | # 代表托管内存的所有堆中的字节(CLR 占用的部分，而不是所有内存，即托管 + 本机内存)。 要查看性能计数器，您可以在 Windows 计算机上使用Process Explorer[2]或 PerfMon，或者在 .NET Core 服务器上使用dotnet-counters 。[3]如果您的应用程序部署在云中，您可以使用像Application Insights[4](Azure Monitor[5]的一部分)这样的 APM 工具来显示这些信息。或者，您可以在代码中获取性能计数器值并每 10 秒左右记录一次，使用Azure 数据资源管理器[6]之类的工具在图表中显示数据。 （编辑：源码门户网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
