CppExplore

顶下！
先下来慢慢研究，以后用的着，呵呵

@xushiwei
你的测试代码对apr-pool不公平，首先（1）作为服务器，关心是长期运行后的性能，而不是开始几个请求的性能，一个服务器可能365天无间断服务，而只拿系统启动2分钟的性能来衡量1年的性能显然不合适，而apr-pool开始申请内存是直接new，释放的时候才组织内存池结构。（2）对于集中处理的情况（类似你的测试代码），内存的申请是从同一个池中申请的，而不是申请一块内存，就必须先申请一个池。
你的测试代码，（1）是针对apr-pool性能最差的建池阶段 （2）每申请一块内存，反复的从allocator创建销毁内存池，和实际的使用不相符
而你的内存池，则没有建池阶段，直接栈中建池，我认为用上面写过apr-pool测试代码用来测试，才对apr-pool公平。

其实我觉得对内存池做这种性能对比没意义，首先这是变长内存池，不需要考虑释放，性能对比也就只是测试申请阶段的性能，而变长内存池都是在已有大内存上的指针滑动，都是常数步骤内完成。因此和算法之间对比性能不同，完善的内存池之间根本就没有性能比较的必要。

@创
你的模型是不是和细分类2中（1）的模型类似啊，直接使用线程不更好嘛。如果是用epoll的话，直接单线程在epoll处wait就好。

以前去你blog上逛过，呵呵，多多交流！

struct, union的sizeof问题这个才是常识性的问题，尤其对于网络间传输的数据结构，这是必须知道的基础性问题。

@sgsoft
win上实现了socket上真正的AIO，*inx上基本上都没有针对socket实现真正的AIO。本文主要针对linux平台，其他平台不很熟悉，并且没机会接触，也无法写代码进行测试，因此AIO的模型就没涉及。
另详细分类2里的模型（5）模拟了AIO的实现，也就是proactor的模拟。

是啊 有问题就问题本身探讨 涉及到人身 甚至去猜测别人的水平 不利于解决问题啊 来来回回净扯蛋了

不好意思 请关注私人留言！

@饭中淹
牛啊 果然是最好的内存copy实现，竟然还实现了跨平台
要是加上inline 或者用包裹宏代替函数就更完美了 哈哈

@Fox
没看过memcpy strcpy库函数实现的，给出按位处理的想法很正常。就像去写strcpy，检测空指针、越界、返回结果指针就很好了，一定要求他给出类似库函数实现的高效不太现实，也没啥意义，就象研究茴香豆的茴有几种写法一样。反正实际开发中不用，就是虚无缥缈的想想。

呵呵
考察memcpy内存地址的字节对齐问题 对实际的开发有啥意义吗？

@8340
呵呵 不要着急 近期就马上写 呵呵 各种服务器网络模型和性能对比 一起常用的网络库 apr_poll libevent ace asio之类的使用 对比等。多谢关注啊

@xushiwei
麻烦做下修改再测试：
void doAprPools1(LogT& log)
{
log.print("===== APR Pools =====\n");
std::PerformanceCounter counter;
for (int i = 0; i < N; ++i)
{
apr_pool_t* alloc;
apr_pool_create(&alloc, m_pool);
int* p = (int*)apr_palloc(alloc, sizeof(int));
apr_pool_destroy(alloc);
}
counter.trace(log);
}
改成
void doAprPools1(LogT& log)
{
int i;
apr_pool_t* alloc;
apr_pool_create(&alloc, m_pool);
for (i = 0; i < N; ++i)
{
int* p = (int*)apr_palloc(alloc, sizeof(int));
}
apr_pool_destroy(alloc);

apr_pool_t* alloc2;
apr_pool_create(&alloc2, m_pool);
log.print("===== APR Pools =====\n");
std::PerformanceCounter counter;
for (i = 0; i < N; ++i)
{
int* p = (int*)apr_palloc(alloc2, sizeof(int));
}
counter.trace(log);
apr_pool_destroy(alloc2);
}
至于线程锁的使用开销，这里就先不考虑了。“apr_pool也是，显式构造allocator后不调用apr_allocator_mutex_set就是无锁的实现。 ”

@wk
一般backlog是两个队列大小的和，比如设置为5就是两个队列的长是5，队列满了，再有连接到来就拒绝。但是有的系统，你设置为5，实际队列大小可能是10，你设置为10，队列实际大小可能是20，就是有的系统有个系数。

莫非又不了了之了？

不错！
c语言的程序里经常是遍地的宏 遍地指针的精巧使用

宏还是非常不错的 类似c语言中的模版机制
内核里的经典数据结构及其算法，象SLIST LIST TAILQ之类的都是宏写的

很简单 未初始化的变量行为未定义，未定义就是怎么都可以
就象调式环境是true 并不能保证exe是true
在本机是true 并不能保证另一个机器上也是true

呵呵 我也是因为socket的原因 看的perl 现在服务器的陪测程序 都是用perl写的。特适合写陪测脚本。下面是我以前写的几个服务器的陪测脚本http://www.cppblog.com/CppExplore/archive/2007/12/04/37752.html

不错，如此简单，
简单的不适宜放在首页了 呵呵

@苦味酸
c#的问题建议去博客园问，这边看样子知道的不多。另有留言给你。

@铸铸平板
为啥在这里发广告呢
这里是c++技术blog，没人买生铁的。

这个要顶！

没有模版需求的时候 总也不知道使用它的原因
有需求的时候 自然就知道为何使用它
呵呵 顺其自然

“这里，我提出另外一种比较独特的做法，就是......”
呵呵，兄弟啊，我毕业答辩的时候，老师就反复的批评我们，“我提出.......”，“我发明......”之类的东西。
文中就是《unix网络编程》中的预派生进程阻塞在accept的方式嘛。
并且书中说明这种问题有惊群问题，可以前面加文件锁或者线程锁互斥，你文中加的是互斥锁。现在的linux从2.2.9版本起就不存在惊群问题而不需要加锁了，更好的是2.6内核的线程库中线程锁不陷入互斥状态的话就不会陷入内核态了，加不加性能一样。而win就没有这么好的线程锁。
多进程方式编程简单，程序健壮性相对比较好，但是切换开销比较大。现在的更倾向于预派生线程的方式。
另可以，起多个多线程的程序，bind不同port，前端部署lvs提供均衡负载一样可以达到更好的多进程效果。

php jsp asp asp.net之类的根本不能算是网络编程，也就是web编程，不需要多少知识深度，竞争也很激烈。
vc做图形开发还是非常有前途的，其他的不知道了。
c++ c编程 或者嵌入式都还是转向linux平台吧。

@火夜风舞
兄弟真实在。呵呵 ：）

@eXile
呵呵，还没用库。
是我最近正在梳理网络模型。这几天正在写各种模型的网络程序并测试性能。
等搞完这个再看各种库是如何实现这些模型以及其性能如何。

说错了 呵呵 三次握手在accept前就完成了 从完成队列里取而已

第一部分（2）的结论不太对。
主线程侦听，预派生的线程处理业务，这个称为模型A吧.
leader/follow这里称为B.
我服务器的4核的SMP，linux 2.6内核，测试工具ab，小压力的测试不说了，都能达到17000左右，测试项如下：
ab -c 4000 -n 40000 http://172.24.252.248:5000/
预派生线程数量都是4。
压力测试的结果是：
业务逻辑简单的时候（仅仅是读数据，然后resonse200OK）:
B模型多次测试平均的结果大约是每秒8500。
而A模型的性能和缓存队列的大小有关，当缓存大小取500时，和B模型性能相当。取1000，测试的平均结果大约是每秒9500。取100则降低为6500左右


猜测原因：linux的pthread_mutex_t既然是非暂停点的实现，那么它的性能一定很好，远好于条件锁、信号灯等。pthread_cond_t则是暂停点的实现，可能把线程推向睡眠。增大缓存大小，可以有效减少对pthread_cond_t的系统调用。

另根据对各种模型的测试，accept的处理速度非常非常的块，简单的业务处理时间也要比accept的处理低一个数量级。因此单一线程处理accept，可以尽快建立三次握手，进入缓存队列等待。

因此猜测 如果业务为复杂逻辑（实际测试加了4个循环相加，一句打印的log）的话，模型B的性能将进一步下降。增大业务处理复杂度后的结果果然如此，模型B的处理降低为6500左右，而模型A在1000的缓存下，每秒的处理能力还是9500左右。

顶 不错
内存申请针对线程内还是跨线程 决定是否采用加锁策略，为了差异化这种处理，在内存池上进行进一步的封装 不错！

@陈子文
：）
转载请著名下 多多交流！

上面的语句外面都是foreach(ch in str){}。
hash表的数量 应该不是影响hash的因素吧 想不出来原因。貌似一般都把hash表的桶数量设置的很大，是实际使用到的3倍多。

java里的hash是乘以31的：hash=hash<<5-hash+ch。
据说就英文而言，乘以33的是最优的：hash=hash<<5＋hash+ch，这个也是apache stl等一大堆著名项目或库的hash方式。
特定应用而言，还是要根据特定的数据，设计最优的hash函数。

空间有毒！！！！大家小心
@浪迹天涯
如果是什么计数器卡着了，也请修改正常。

非常不错！这6个原则概括的还真是精辟！

非常不错！这6个原则概括的还真是精辟！

晕倒..........................

问题的关键不在UserAlloc，而是details::PODptr<size_type> 。除非你想在内存池之上实现这个内存池的UserAlloc（到底是先有鸡还是先有蛋......），即便这样，当前的object_pool析构最少也要付出o(n)的代价。

@eXile
：）
“从收到一个包，到对这个包的处理完毕，则可视为内存的一个周期。”，这时候析构object_pool不恰当，因为以后还会收到包，内存还可循环被使用，这里还是应该调用destroy，而它的时间复杂度o(n)，导致了真是不太适合使用。析构object_pool更不可取，时间复杂度不说，还有内存的再次申请，背离了内存池的初衷。

@eXile
晕倒 在boost/pool/detail/pool_construct.inc里
只关注hpp去了
可以调用任意的构造函数
多谢指正！正文中现已标明。

另：boost/pool下的6个hpp文件我是挨个读过了。detail下的都很简单，5个hpp，singleton.hpp有效行数就10几行，没看，想当然了下。mutex和guard在读singleton_pool.hpp的时候看了下linux下的mutex，顺便还测试了下，gcd_lcm的两个也很简单，没看，估计大约是2者求最小值的功能。
我一贯认为，明白原理，知道如何使用就好，深入具体细节就是浪费脑细胞，如果你要实现一个当然例外。

本站n多人搞图形啊

@Enoch
呵呵，借用一句流行话：您的回帖是我继续的最大动力。
谢谢

@空明流转
这个现在还是只能停留在美好的展望阶段，不过这一天的到来不远了。

@CornerZhang
呵呵，apache很成功，apr_pool自然不会差。

@eXile
AutoFreeAlloc的发展方向应该就是apr_pool。apr_pool已经把变长的内存池发展到极致，当然这是当前看到的，或许以后有内存池会把变长内存池推到一个新的高度。：）
支持多线程的内存池都是从单线程加锁机制实现的，都提供无锁的实现。apr_pool也是，显式构造allocator后不调用apr_allocator_mutex_set就是无锁的实现。
后面的boost和loki的无锁和有锁的实现区别更是明显。

@空明流转
欢迎光顾本帖。：）
随意起的名字，没啥含义，再下个定义就咬文嚼字了，呵呵。
当然系统的核心是业务。系统设计可以说有技术层面的有业务层面的。
我主要想写点技术层面的东西，分享一下个人的感想。一大堆乱七八糟的东西，想不住什么共性来，就随意起了这个名字。

哈哈 。。。。。。。。。。。。。。。。。

开业大吉啊！！

原来是本blog的开山文章啊
使劲顶啊

有空来我blog看看，多多交流！！

先顶下 慢慢看
以前看astrisk的源码（c语言实现） 觉得它的架构就完美了 所有模块都可以动态加载 卸载，所有接口都可以动态注册 注销。
貌似ace里也有组件配置框架，还没研究过。
文中的poco的支持 很有吸引力啊

为啥就不用内存数据库呢

意义不大
首先 无论是win下还是linux下 都有很出色的内存检测工具。这些工具已经成为测试程序的必须，而不是可选。
其次 不论是内存检测工具 还是文中所述方法 都只能检测严格的内存泄漏，比如base *a=new A(); base *b=new B(); a=b;则对原a的内存控制完全失去，此为内存泄漏。完全的内存检测 还要配合 完善的log机制 交互式查看系统信息等附加功能
最后，小trick，又是转贴，和楼上意见一样，就不要放首页了。