proxy acct records best practices
Hello, I am a new user of freeradius ( no experience with the 1.x version at all ). I am in the process of setting up radius for accounting of voip records. Due to the nature of my system blocking must be avoided at all costs. With this in mind I have configure FR to write accounting records locally to a file then I have the records proxied to a remote freeradius instance where the records are written to a database. My question revolves around best practices and speed. Reading and shipping the records off box is very slow ( somewhere around 5 - 10 records per second ). I believe this may be caused by the latency between the proxy and the master which is around 150ms. Of course I could just insert the records in the DB across the WAN but am not sure whether this would be any faster. I'm convinced latency is the issue because even when I turn off the databasing of records on the master and only write to flat files the speed remains in the same range. Keeping in mind my newness to freeradius I thought it might be a good idea to ask the community for suggestions. Thanks T
TR Missner wrote:
I am a new user of freeradius ( no experience with the 1.x version at all ).
Don't use 1.x. Use the latest version.
I am in the process of setting up radius for accounting of voip records. Due to the nature of my system blocking must be avoided at all costs. With this in mind I have configure FR to write accounting records locally to a file then I have the records proxied to a remote freeradius instance where the records are written to a database. My question revolves around best practices and speed. Reading and shipping the records off box is very slow ( somewhere around 5 - 10 records per second ).
You've configured the server to use syslog. Don't. Syslog on some systems is limited to 5-10 log entries per second. This is because it syncs the logs to disk after each line of text.
I believe this may be caused by the latency between the proxy and the master which is around 150ms.
No.
Of course I could just insert the records in the DB across the WAN but am not sure whether this would be any faster. I'm convinced latency is the issue because even when I turn off the databasing of records on the master and only write to flat files the speed remains in the same range.
syslog. Alan DeKok.
Sorry I wasn't more clear.I am not using 1.x but most of the documentation refers to how things were done in 1.x and because of this means nothing to me. I am not using syslog. Accounting packets are being written to disk using the detail function. Then I am shipping them off to the other radius by setting the listen object on the detail file. Even with load_factor set to 100 the speed at which the detail is read is very slow. There are some notes in the copy-acct-to-home-server example that talk about automatic throttling of the reads depending on the backend. This is what led me to question latency. Is there any way to speed up the reading and shipping of acct records to another FR instance? Thanks again. TR On Fri, Mar 6, 2009 at 2:39 AM, Alan DeKok <aland@deployingradius.com>wrote:
TR Missner wrote:
I am a new user of freeradius ( no experience with the 1.x version at all ).
Don't use 1.x. Use the latest version.
I am in the process of setting up radius for accounting of voip records. Due to the nature of my system blocking must be avoided at all costs. With this in mind I have configure FR to write accounting records locally to a file then I have the records proxied to a remote freeradius instance where the records are written to a database. My question revolves around best practices and speed. Reading and shipping the records off box is very slow ( somewhere around 5 - 10 records per second ).
You've configured the server to use syslog. Don't. Syslog on some systems is limited to 5-10 log entries per second. This is because it syncs the logs to disk after each line of text.
I believe this may be caused by the latency between the proxy and the master which is around 150ms.
No.
Of course I could just insert the records in the DB across the WAN but am not sure whether this would be any faster. I'm convinced latency is the issue because even when I turn off the databasing of records on the master and only write to flat files the speed remains in the same range.
syslog.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
TR Missner wrote:
Accounting packets are being written to disk using the detail function. Then I am shipping them off to the other radius by setting the listen object on the detail file.
That should be fine.
Even with load_factor set to 100 the speed at which the detail is read is very slow. There are some notes in the copy-acct-to-home-server example that talk about automatic throttling of the reads depending on the backend. This is what led me to question latency.
It might be a latency issue.
Is there any way to speed up the reading and shipping of acct records to another FR instance?
Find out what the delay is, and fix it. I think we can add time statistics to a future version of the server: e.g. Where is it spending time? Which module? How fast does a home server respond? That kind of information can be used to debug this sort of issue. Alan DeKok.
Hi, {cut}
There are some notes in the copy-acct-to-home-server example that talk about automatic throttling of the reads depending on the backend. This is what led me to question latency.
It might be a latency issue.
Is there any way to speed up the reading and shipping of acct records to another FR instance?
Find out what the delay is, and fix it.
Are the packets read from detail file send sequentially, waiting for each individual response before sending next packet, or are the packets send in groups, and then potentially the re-try occurs for those that didn't receive the reply? Studying the packet flows with tcpdump suggests that former. If that is the case that with 150ms latency all you can get is about 6-7 packets a second. kind regards Pshem
Pshem Kowalczyk wrote:
Are the packets read from detail file send sequentially, waiting for each individual response before sending next packet, or are the packets send in groups, and then potentially the re-try occurs for those that didn't receive the reply?
Yes.
Studying the packet flows with tcpdump suggests that former. If that is the case that with 150ms latency all you can get is about 6-7 packets a second.
OK. It could updated to send more packets at once, but that would require source code changes. Alan DeKok.
participants (3)
-
Alan DeKok -
Pshem Kowalczyk -
TR Missner