考试系统学术报告-非结构化数据库

这个还的从我们的英语的第一次测试说起，第一次测试，测试人数170,8人，测试的有效数据100.其中呢，英语听力是怎么个状况，有人说听力很正常。没问题，有人说试抽出来了，听力过了5分钟才有，还有说干脆听不到。当时呢，我自己也在集体的测试中，具体的问题先

这个时候就体现了我们对问题的分析能力了。如何才能总结先前经验，快速发现问题，找到问题的原因，并解决它。

发现问题

方案一 ping服务器

我们注意看下面的这个图

你不是没有声音么，我们看看你是否能连接到服务器。

当时我们英语测试的时候其中之一发现的问题来自于ping 服务器的网址 ，大家可以依稀看到响应时间是404ms，而正常情况好似多少呢.

正常情况小于1ms

对比相差400多陪，而且中间还有断续或网络中断。这就是是病毒造成的。经过米老师的不懈努力，终于将这个arp病毒困死在了本机，出不去了，具体的方法是通过网络中心绑定端口。这个问题解决了后，英语听力基本是没有什么大问题了。

小范围的测试是没有问题 了，可是到了第二天考英语的时候，每次是在800人以上。服务器的承受压力，大家请看这幅图。这个是考生刚登陆系统时的截图。

方案二： 通过监视服务器的运行状态

问题二 抽提中音频延迟

上图 是开始听力测试的页面了。这个时候ping服务器还是会看到超过400的现状，但是不会有超时和断续的现象，这时候就是延迟的问题了。

查找原因

问题一解决了，再后来就得看自己的代码了，代码是否有问题呢。看了再说。

这个连接池是没有写在配置文件中的，而且大家请注意这个链接是每次进行链接时进行设置的，要写在配置文件中，方便修改。

如何修改呢，不同的数据库修改大体还是相同的 。

但是修改后进行更详细的测试还有没有测试出问题来。看来这个还不是主要的问题。后来在老师的带领下，考虑到了网络交换设备的转换， 服务器用的是1000M的，而我们的交换机和主机的转换确实100M的，这就大大降低了音频的传输效率，造成了延迟。所以我们就使用了隔开时间的抽提的方法。避免时间延迟。

以上的解决方法只是暂时的解决了问题，并没有根本的解决问题，更优的方法是。

请问这两个方案，我们曾经是否都听到或用过呢，可是我们自己在设计的时候为何就没有运用到实际中呢，联系实际，根据已有的参考他人设计的优点，作为自己的起点，以终为始，这是我们要学习的。

下图是Mongodb数据库管理可视化页面

更详细的数据库操作，请查看我的往期 博客。