图书馆设计方法
Library design methodology
我想创建 "TRAP AGENT" 库。陷阱代理库跟踪客户端系统的各种参数。如果客户端系统的参数变化超过阈值，则客户端的陷阱代理库会向服务器通知该参数。例如，如果 CPU 使用量超过阈值，那么它会通知服务器 CPU 使用量已超过。我必须在客户端测量 50-100 个参数（如内存使用情况、网络使用情况等）。
现在我对设计有了基本的想法，但我仍然坚持整个库的设计。
我想到了以下解决方案：
- 我可以为每个参数创建一个线程（即每个线程将监视单个参数）。
- 我可以为每个参数创建一个进程（即每个进程将监控单个参数）。
- 我可以将各种参数分为不同的组，比如数据使用参数将归入网络组，CPU内存使用参数将归入系统组，然后为每个组创建线程。
现在第一个解决方案与第二个相比看起来不错。如果我采用第一种解决方案，那么当我想为 100 到 1000 个参数升级我的库时，它可能会失败。因为我当时必须创建1000个线程，这不是一个好的设计（我认为是这样；如果我错了请纠正我。）
第三个解决方案很好，但响应时间会很长，因为许多参数将在单线程中监控。
有没有更好的方法？
一般来说，为代码中的任何逻辑映射一对一生成线程是个坏主意。可以快速耗尽系统的可用线程。
在 .NET 中，这是使用线程池非常优雅地处理的：
Thread vs ThreadPool
这是一个 C++ 讨论，但概念是相同的：
Thread pooling in C++11
进程在 Windows 上的开销也很高。具有讽刺意味的是，这两种设计听起来都对您试图监控的资源造成了很大的负担。
线程（和进程）在您需要的地方提供并行性。例如，让 GUI 在某些后台任务 运行ning 时响应。但是如果你只是在后台监控并向服务器报告，为什么需要这么多的并行度？
您可以 运行 每次检查，一个接一个，在一个线程的紧密事件循环中。如果您担心不经常对值进行采样，我想说这实际上是一个好处。消耗 50% CPU 来监控你的 CPU 并没有帮助。如果您每隔几秒抽查一次值，这可能是很好的分辨率。
事实上，如果您要向服务器报告，高分辨率是没有帮助的。一旦某些值触发，您不希望通过每秒多次对服务器进行 HTTP 调用来对服务器进行拒绝服务攻击。
注意：这并不意味着您不能拥有可插拔架构。您可以创建一些表示检查资源的基础 class，然后为每个特定类型创建子class。您的事件循环可以遍历数组或对象列表，依次调用每个对象并聚合结果。在循环结束时，如果有任何超出范围，您将向服务器报告。
您可能希望添加逻辑以在陷阱命中后停止检查（或至少停止向服务器报告）某些 "cool down period"。您不想对您的服务器征税或向您的日志发送垃圾邮件。
您可以遵循以下方法：
1.You可以有两个线程，一个线程专门测量紧急参数，第二个线程监测非紧急参数。
因此紧急参数的响应时间会更短。
2.You可以定义3个threads.First线程监听高优先级（紧急参数），第二个线程监听中等优先级参数。最后一个线程将监视优先级最低的参数。
因此，与第一个解决方案相比，整体响应时间将得到改善。
3.If 响应时间不是问题，那么您可以监视单个参数中的所有参数 thread.But 在这种情况下，当您升级库以监视 100 到 1000 个参数时，响应时间变得最差。
所以在第一种情况下，非紧急情况的响应时间会更长 parameter.While 在第三种情况下，响应时间肯定会非常长。
所以方案2更好。
我想创建 "TRAP AGENT" 库。陷阱代理库跟踪客户端系统的各种参数。如果客户端系统的参数变化超过阈值，则客户端的陷阱代理库会向服务器通知该参数。例如，如果 CPU 使用量超过阈值，那么它会通知服务器 CPU 使用量已超过。我必须在客户端测量 50-100 个参数（如内存使用情况、网络使用情况等）。 现在我对设计有了基本的想法，但我仍然坚持整个库的设计。
我想到了以下解决方案：
- 我可以为每个参数创建一个线程（即每个线程将监视单个参数）。
- 我可以为每个参数创建一个进程（即每个进程将监控单个参数）。
- 我可以将各种参数分为不同的组，比如数据使用参数将归入网络组，CPU内存使用参数将归入系统组，然后为每个组创建线程。
现在第一个解决方案与第二个相比看起来不错。如果我采用第一种解决方案，那么当我想为 100 到 1000 个参数升级我的库时，它可能会失败。因为我当时必须创建1000个线程，这不是一个好的设计（我认为是这样；如果我错了请纠正我。）
第三个解决方案很好，但响应时间会很长，因为许多参数将在单线程中监控。
有没有更好的方法？
一般来说，为代码中的任何逻辑映射一对一生成线程是个坏主意。可以快速耗尽系统的可用线程。
在 .NET 中，这是使用线程池非常优雅地处理的： Thread vs ThreadPool
这是一个 C++ 讨论，但概念是相同的： Thread pooling in C++11
进程在 Windows 上的开销也很高。具有讽刺意味的是，这两种设计听起来都对您试图监控的资源造成了很大的负担。
线程（和进程）在您需要的地方提供并行性。例如，让 GUI 在某些后台任务 运行ning 时响应。但是如果你只是在后台监控并向服务器报告，为什么需要这么多的并行度？
您可以 运行 每次检查，一个接一个，在一个线程的紧密事件循环中。如果您担心不经常对值进行采样，我想说这实际上是一个好处。消耗 50% CPU 来监控你的 CPU 并没有帮助。如果您每隔几秒抽查一次值，这可能是很好的分辨率。
事实上，如果您要向服务器报告，高分辨率是没有帮助的。一旦某些值触发，您不希望通过每秒多次对服务器进行 HTTP 调用来对服务器进行拒绝服务攻击。
注意：这并不意味着您不能拥有可插拔架构。您可以创建一些表示检查资源的基础 class，然后为每个特定类型创建子class。您的事件循环可以遍历数组或对象列表，依次调用每个对象并聚合结果。在循环结束时，如果有任何超出范围，您将向服务器报告。
您可能希望添加逻辑以在陷阱命中后停止检查（或至少停止向服务器报告）某些 "cool down period"。您不想对您的服务器征税或向您的日志发送垃圾邮件。
您可以遵循以下方法：
1.You可以有两个线程，一个线程专门测量紧急参数，第二个线程监测非紧急参数。 因此紧急参数的响应时间会更短。
2.You可以定义3个threads.First线程监听高优先级（紧急参数），第二个线程监听中等优先级参数。最后一个线程将监视优先级最低的参数。 因此，与第一个解决方案相比，整体响应时间将得到改善。
3.If 响应时间不是问题，那么您可以监视单个参数中的所有参数 thread.But 在这种情况下，当您升级库以监视 100 到 1000 个参数时，响应时间变得最差。
所以在第一种情况下，非紧急情况的响应时间会更长 parameter.While 在第三种情况下，响应时间肯定会非常长。 所以方案2更好。