Good afternoon,
Sorry if i can't explain my poblem in russian and hope i'll found a solution in english.
We're using UTM5 in our company with prepaid card (hotspot), and i have few questions abut this :
1. How many users can be logged simultaneously and managed by UTM ?
2. How to improve the MySQL database settings in order to accept approxymatly 500 simultaneous users ?
3. Wich log level is recommended for a production server ?
Thanks all for your reply
Best regards
Julien
UTM limit & perfs
Hi.
1. I have more than 10 000 users on standard UTM-Radius, and some ISP at this forum it is more 30 000, the truth already recommend FreeRadius
2. For 500 users standard options MySQL will suffice, also it depends on the equipment standing on your server. And use tuning-primer.sh http://www.day32.com/MySQL/
np
Bye
1. I have more than 10 000 users on standard UTM-Radius, and some ISP at this forum it is more 30 000, the truth already recommend FreeRadius
2. For 500 users standard options MySQL will suffice, also it depends on the equipment standing on your server. And use tuning-primer.sh http://www.day32.com/MySQL/
np
Bye
Xeon processor, 2gb RAM, 200 go hdd RAID (level???)bear писал(а):Hi.
... also it depends on the equipment standing on your server.
And i saw in the folder /netup/utm5/bin a file utm5_optimizer, do someone know what this file can do ?
And also, if you have some commons tips to optimize a UTM server...
Thanks
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
Your server OS needs the only optimization. It must give your UTM5 core process to use as many RAM as possible.
You can forget about utm5_optimizer since UTM5 has ability to use archived transactions, so the core performance isn't an issue. Some users on this forum reported, that the worst issue is web-interface, when one uses Hot-spot module.
I can't remember, if the issue was with CGI/Web-server performance, or the core process couldn't handle a large amount of connections.
So you should try to stress-test web-interface.
It works as follows(afaik):
1. user registers himself with the billing system via web.
2. hot-spot user MUST refresh his session with web-iface, so that billing server knows, that user is online.
3. if user wants go offline, he closes the session.
So, if the issue is that web-server or cgi-script works slowly, than you can set up some more servers, or tune up your web-server software(Apache/Lighttpd/IIS). If the problem is that the core can't handle lots of connections, than you can try to set up several cores. But this workaround is bad, cause you can't make several cores work with the same database. The core process caches the data, and there is nothing to do with it. Several cores,each serves only its own hot-spot users.
You can forget about utm5_optimizer since UTM5 has ability to use archived transactions, so the core performance isn't an issue. Some users on this forum reported, that the worst issue is web-interface, when one uses Hot-spot module.
I can't remember, if the issue was with CGI/Web-server performance, or the core process couldn't handle a large amount of connections.
So you should try to stress-test web-interface.
It works as follows(afaik):
1. user registers himself with the billing system via web.
2. hot-spot user MUST refresh his session with web-iface, so that billing server knows, that user is online.
3. if user wants go offline, he closes the session.
So, if the issue is that web-server or cgi-script works slowly, than you can set up some more servers, or tune up your web-server software(Apache/Lighttpd/IIS). If the problem is that the core can't handle lots of connections, than you can try to set up several cores. But this workaround is bad, cause you can't make several cores work with the same database. The core process caches the data, and there is nothing to do with it. Several cores,each serves only its own hot-spot users.
You can try to turn on MySQL query cache and play with MySQL InnoDB engine settings. If you have UTM Core and MySQL running on the same board with 2Gb RAM, set innodb_buffer_pool_size to 256M or higher for optimal performance, but very big values isn't recommended, it leads to lower performance because of swapping.