我正在为教室 wifi 系统的负载测试做准备。学生们在课程开始时都打开笔记本电脑，启动网络浏览器，然后开始上课 - 这需要下载基于 flash 的课程（从学校内的服务器下载），通常下载量为 0.5 到 2 MB。
在某些情况下，加载时间会延长到 5 分钟或 10 分钟。因此，我希望监控系统的所有部分，以便自信地判断瓶颈在哪里，以及有多少客户端可以合理地使用单个 wifi 接入点。因此，我们计划对最多 50 个客户端进行测试，看看会发生什么（我知道大多数人建议每个接入点使用 20-25 个客户端，但客户希望测试这一点 - 并且我希望获得良好的数据，以便以某种方式向客户展示）。
我已经知道如何监控服务器。wifi 接入点支持 SNMP，似乎提供了相当多的变量，但我不想费太多功夫。
所以问题是，当系统过载、客户端等待、发生冲突等时，哪些与 wifi 相关的变量是需要监控的关键变量？
我很高兴被告知应该在那里的通用名称并亲自搜索文件，但如果您想要/需要查看详细信息，那么我们使用的接入点是Ubiquity Nanostation 2。Ubiquity 产品的 MIB 文件链接自他们的 SNMP 页面。尽管我也发现他们似乎至少支持部分微机电系统。
答案1
简单的方法是定期监控IF-MIB::ifInOctets.<ifIndex>/ IF-MIB::ifOutOctets.<ifIndex>OID 并检查可用带宽。从链接的 MikroTik MIB 中，您可以通过读取 mtxrWlStatTxRate:1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>和 mtxrWlStatRxRate:来发现当前设置的速率1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>。这当然不会考虑无线细节，但可以让您大致了解接口上的总可用带宽是否是瓶颈（如果您看到使用量接近总通道容量，则很可能是瓶颈）。
一般来说，除非您的站点或天线位置不佳，且所选信道频率下的以太干净，否则您可以预期单个 G 信道（54 MBps 2,4 GHz）的吞吐量约为 2-3 MB/s。
如果您需要有关 AP 端重试和错误的更多具体信息，您可以阅读dot11CountersIEEE802dot11 MIB 表 - 特别是相应实例的dot11RetryCount、dot11MultipleRetryCount和值。dot11FailedCount
802.11 不存在任何冲突，但存在物理载波侦听和可选的RTS/CTS 握手在传输帧之前。监控将dot11RTSFailureCount让您大致了解 CTS 未回复 RTS 请求的频率，从而不向发送站授予信道。
请注意，如果您的接入点生成了绝大部分流量（即站点主要接收数据），您可能会看到相对较少的重试次数和 RTS 失败次数。您可能希望查看IF-MIB::ifOutDiscards.<ifIndex>无线接口或IF-MIB::ifInDiscards.<ifIndex>有线接口，因为只要缓冲区已满且无法接收任何额外帧（即 AP 以全速发送，但以太网接口上的帧以更快的速率到达），这些数字就会增加。
答案2
如果您要做的只是向客户端证明他们正在使 AP 超载，那么您可以使用 dot11RetryCount 和 dot11MultipleRetryCount OID。
dot11RetryCount - 1.2.840.10036.2.2.1.4
dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5
这将为您提供空中拥堵程度的粗略估计。一旦重试次数达到 dot11TransmittedFrameCount 的 10% 以上，您将开始看到速度变慢。
这是 Cisco 的 MIB 对象步行器 - 如果您需要找出要检查的其他 OID，它应该会有所帮助。