我正在准备一个教室wifi系统的负载testing。 学生在课程开始时都会打开笔记本电脑，启动networking浏览器，然后他们开始上课 – 这包括下载基于闪存的课程（从学校内的服务器），一般下载2到2 MB。
在某些情况下，加载时间延长到5或10分钟。 所以我想监视系统的各个部分，充满信心地说出瓶颈，有多less客户可以合理地使用一个wifi接入点。 因此，我们计划在多达50个客户端上运行testing，看看会发生什么（我知道大多数人每个接入点推荐20-25个客户端，但是客户端要testing这个 – 我想获得好的数据以显示客户端不pipe怎样）。
我已经知道如何监视服务器。 WiFi接入点支持SNMP，似乎提供了相当多的variables，但我不希望有太多的趟过。
所以问题是，什么是WiFi相关的variables是关键的监测来描述什么时候系统过载，客户正在等待，碰撞正在发生等？
我很高兴被告知应该在那里的通用名称，并通过这些文件自己search，但是如果您想要/需要查看详细信息，那么我们使用的接入点是Ubiquity Nanostation 2 。 Ubiquity产品的MIB文件从其SNMP页面的底部链接。 尽pipe我也发现他们似乎至less支持Mikrotik MIB的一部分。
简单的方法是定期监视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>来发现当前设置的速率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端的重试和错误的特定信息，您可以阅读IEEE802dot11 MIB的dot11Counters表，特别是相应实例的dot11RetryCount ， dot11FailedCount和dot11FailedCount值。
802.11在帧传输之前没有任何冲突，而是物理载波侦听和可选的RTS / CTS握手 。 监测dot11RTSFailureCount会给你一个粗略的认识，即RTS请求不被CTS回复的频率，因此不会授予发送站的信道。
请注意，如果您的接入点产生绝大多数stream量（即站点主要是接收数据），则您可能会看到相对较less的重试次数和RTS故障。 您可能需要查看无线接口处的IF-MIB::ifOutDiscards.<ifIndex>或有线接口处的IF-MIB::ifInDiscards.<ifIndex> ，以及这些数字在缓冲区满时将递增，不能接收任何额外的帧（即，AP正在以全速率发送，但在以太网接口处的帧保持到更快的速率）。
如果您所要做的只是向客户端certificate他们正在重载AP，则可以使用dot11RetryCount和dot11MultipleRetryCount OID。
dot11RetryCount – 1.2.840.10036.2.2.1.4
dot11MultipleRetryCount – 1.2.840.10036.2.2.1.5
这会让你粗略地估计空气堵塞的程度。 一旦重试计数达到dot11TransmittedFrameCount的10％以上，您将开始看到减速。
这里是思科的MIB对象步行者 – 如果你需要弄清楚其他的OID来检查，这应该会有所帮助。