freeradius 的bug处理

目前freeradius 使用线程池多线程的方案处理，radius认证报文，自己内部维持一个状态机。网络模型为监听1812的认证端口，以及1813的计费端口。

目前发现收包IO线程和业务线程在udp socket 收发上存在锁竞争，毕竟业务线程调用send 发送报文， 多线程互斥， 主线程负责recv udp导致出现锁竞争。
目前已经改为：主线程负责io，业务线程只负责业务处理。
但是效果不是很明显，同样条件测试，cpu利用率从140%--->降低到130%，也就是单核70%降为单核65%。
perf 结果

注意：
其一：整体打印了函数调用的树状结构，并表征了一个符号占用的56.32%具体是由哪些采样的符号组成的。注意即使该符号没有被采样到，他也可能出现在这里，因为可能这个符号调用链的下层调用函数被采样到了，故而这个符号就会体现在这里，而且会把他所有调用到的函数被采样的结果加总起来，得到children这一列。

其二：其中children一列的总和，是可能大于100%的，因为对于每一个采样点，如果能获取到这个采样点完整的调用栈，就会把这个采样点的overhead加总到他的parent symbol的children那一列，而实际的调用栈可能是 A->B->C->D。如果D被采样到了，且比例是1.1%，而A,B,C都未被采样到。则 A,B,C的children那一列均是1.1%,D则self那一列和children那一列都是1.1%。都会呈现在上述report中，故而加总起来会超过100%。

如果不希望看到加总的结果，而只希望看到具体的符号被采样的比例，则可以使用如下的命令生成report
perf report --no-children > perf.txt #默认读取perf.data
perf report -i perf.data > perf.txt 这是分析报告。
来看下当前的分析报告；

根据log对比：

目前会调用filter username模块，目前看没用，

目前去掉filter模块后，cpu有所降低，但是dict_hashname 以及 strlcpy调用依旧频繁。
不好处理啊,

根据perf 结果细分析代码，在makefile中去掉verifyxxx相关逻辑，cpu使用率减少50%。----！！！---
目前剩下mallc 以及do_futex（线程池的锁等处理）

last: 目前通过去掉一些不用模块以及 优化相关代码、优化增加io线程，解决io时业务线程等待的问题， 性能有所提高，已经满足要求-------------------

last：目前只剩下malloc free 成为瓶颈点 可以使用内存次尝试一下，但是目前性能以及翻倍提升，满足需求，暂时就处理了

问题2：多线程使用udp socket 发包问题

1、socket内核实现有lock，防止并发访问资源

2、UDP数据报不像TCP，它是有边界的，即发送端的一个UDP数据报会完整的被接收端以一个UDP数据报的方式接收。

然而，并非一次写操作对应一个UDP数据报，应用程序可以通过MSG_MORE标记或者UDP_CORK选项将多次写操作的数据合并成一个UDP数据报发送。具体操作流程如下：
在调用sendmsg()时，flag参数中设置MSG_MORE标记，表示还有更多数据要发送。应用期望内核收到设置了该标记的数据时先不要将本次递交的数据发送给IP层，而是将其缓存，并且将后面连续的设定了该标记的数据合并成同一个UDP报文（一个IP报文，但是可能是多个IP片段）。直到没有设定该标记的发送时，将数据报发送给IP层；
类似的，在使能和关闭UDP_CORK选项期间发送的所有数据也要组合成一个UDP报文发送给IP。
注意：应用程序在使用这种方式的时候必须要注意多次组合的数据最好不要超过MTU，否则IP层就不得不将这些要组合的数据分成多个IP数据包发送出去，这样会造成性能的下降。
3、对于多线程IO，最好变成一个线程负责IO，其余线程负责业务处理。

In the context of UDP (User Datagram Protocol), "msg_more" refers to a flag that can be set in the UDP header to indicate that a message consists of multiple datagrams.
When a large message is sent using UDP, it may need to be divided into multiple datagrams to be transmitted over the network. The "msg_more" flag is used to indicate whether there are additional datagrams that belong to the same message.
If the "msg_more" flag is set to 1 (true), it means that there are more datagrams to follow. If it is set to 0 (false), it means that the current datagram is the last one in the message.
Receiving applications can use this flag to ensure that they have received all the datagrams belonging to a message before processing it.