你们的Radius Manager最多带了多少用户
本帖最后由 qiznstar 于 2011-8-27 20:33 编辑调查一下，本人刚刚装上了3.8版的阿湘版，发现其中的核心认证文件 freeradius有诸多的配置方面的问题。
freeradius采用了默认的配置，其数据库并发数采用默认的5个，这对用户量比较大的来说是远远不够的。
再次发现mysql的配置文件，其中还是采用了默认的配置，这对多台ROS，大量用户来讲会造成统计上的失误。
众所周知，Radius采取的是udp数据包，udp是发出去不管的不可靠的传输方式，而freeradius的默认配置文件仍然以可靠为前提的。
# accounting_update_query - 计账更新操作
# accounting_update_query_alt - 计账更新失败后的操作
# accounting_start_query - 开始计账的操作
# accounting_start_query_alt - 开始计账失败后的操作
# accounting_stop_query -停止计账的操作
# accounting_stop_query_alt - 停止计账失败后的操作
计账更新操作是用的更新语句
更新失败后用的是插入语句
开始计账用的是插入语句
插入失败表示存在了于是用更新语句
计账停止后用的更新语句
停止失败后用的是插入语句
其中暂且不说更新语句的毛病
先只说更新失败后的插入语句的毛病，其中所有的插入语句前提条件是更新失败。
那么有一个隐患就是，有没有可能在数据库十分繁忙的时候，数次的更新的确失败了，而数次的插入却生效了呢？完全有可能。
其中条件语句也有一些问题。
计账更新的操作只根据ID，用户名，NAS的IP就来判断，虽然不是很高的机率，但仍有可能造成重复问题，比如一条已经下线了的计录，其中的acctstoptime应该不为空了，那么这个用户可能拔上来的acctsessionid与记录上的重复。
诸如此类，个人觉得RM无法带大量用户，尤其是如果停机后数百以上用户同时上线，更会造成统计结果不准确。
很简单的测试，大家用RM开一个账号，允许拔500次，然后虚拟机另装台ROS，脚本一次性加入500个同样的拔号账号，然后回到RM后台看在线用户是否准确，几乎包不准确。 对这个很感兴趣，有谁做过真正的试验
本帖最后由 47771885 于 2011-8-27 21:23 编辑
.....演示。。。。。。根据 软硬件配置情况略有差异 本帖最后由 qiznstar 于 2011-8-27 21:31 编辑
这个差异绝对不是软件问题，是因为重复的insert，插入，我有反复测试过，测试也很简单，你把ROS用户全拔上后，发现统计不准确，这时你把所有的拔号账号禁用，然后会发现RM里面仍有大量账号在线。 随便贴一个吧，此机硬件非常一般。
带几千个用户在线是没问题的，同时并发数测试一般环境意义不大。优化下mysql 就能提供N多。
用户数不统一，还要考虑routeros的性能，是否已经发送了上线记录到radius。 如果在线用户数统计错误，将会造成有些用户拔不上号，因为RM里面记录了他是在线的，而他真不在线
认真学习 认真记录 认真收藏!:lol qiznstar 发表于 2011-8-27 21:41 static/image/common/back.gif
如果在线用户数统计错误，将会造成有些用户拔不上号，因为RM里面记录了他是在线的，而他真不在线
出现RouterOS内不在线，radius manager内用户在线的情况，基本只能是出现在用户离线时。就算是硬件故障几百个用户同时离线，radius manager没能及时更新用户离线记录。radius manager也会在 10（默认）分钟内将用户置离线。
几千个用户的网络，根本就不必担心 radius manager 效率问题。 本帖最后由 qiznstar 于 2011-8-27 22:23 编辑
硬件故障归硬件故障，不能把正常情况下的故障归硬件故障来处理，这个不够严谨，并非没有解决办法，这也是我们做认证系统时，技术员测试出来的问题，解决方案也下载得到，我想阿湘版主的下一个版本就能完全解决了，配置优化的问题，不关RM的事，不能使用默认的配置，带机量过小。 qiznstar 发表于 2011-8-27 22:12 static/image/common/back.gif
硬件故障归硬件故障，不能把正常情况下的故障归硬件故障来处理，这个不够严谨，并非没有解决办法，这也是我 ...
不好说我只能做我 知道的 环境不一样的 嘿嘿或许到那依旧 metro的3.9V2版本生成卡会出错，是哪里的问题呢？:Q
FPDF error: Some data has already been output, can't send PDF file 楼主您所说的情况，正常情况下不会发生，出现这样的情况只能是硬件故障。而你测试时所出现的问题Radius Manager官方也考虑了解决方法，默认是10分钟未收到用户的状态更新数据，就认为是用户已经离线，置用户为离线状态，这个默认时间可以修改。
mysql的配置问题，在mysql的安装文档中已经说明了，安装者根据硬件情况自行调整，并且已经带有常规环境的配置模板，非要使用默认的最优硬件兼容方式，那就是安装者自己的问题。radius manager 是使用外挂模块的方式进行的用户认证 状态更新等工作，虽然对效率有点影响，也许官方是出于保密的缘故，在不修改Freeradius源文件的基础上实现了一些其他功能，这样做也比较合理。
这些问题并没归咎到硬件故障。根本就不算是问题，也许是楼主你自己开发程序遇到了问题，想借鉴其他系统的解决方式而已吧。 本帖最后由 qiznstar 于 2011-8-28 11:42 编辑
无语------------------- 本帖最后由 qiznstar 于 2011-8-28 11:42 编辑
无语-------------------