CppExplore

頂下！
先下來慢慢研究，以后用的著，呵呵

@xushiwei
你的測試代碼對apr-pool不公平，首先（1）作為服務器，關心是長期運行后的性能，而不是開始幾個請求的性能，一個服務器可能365天無間斷服務，而只拿系統(tǒng)啟動2分鐘的性能來衡量1年的性能顯然不合適，而apr-pool開始申請內存是直接new，釋放的時候才組織內存池結構。（2）對于集中處理的情況（類似你的測試代碼），內存的申請是從同一個池中申請的，而不是申請一塊內存，就必須先申請一個池。
你的測試代碼，（1）是針對apr-pool性能最差的建池階段 （2）每申請一塊內存，反復的從allocator創(chuàng)建銷毀內存池，和實際的使用不相符
而你的內存池，則沒有建池階段，直接棧中建池，我認為用上面寫過apr-pool測試代碼用來測試，才對apr-pool公平。

其實我覺得對內存池做這種性能對比沒意義，首先這是變長內存池，不需要考慮釋放，性能對比也就只是測試申請階段的性能，而變長內存池都是在已有大內存上的指針滑動，都是常數(shù)步驟內完成。因此和算法之間對比性能不同，完善的內存池之間根本就沒有性能比較的必要。

@創(chuàng)
你的模型是不是和細分類2中（1）的模型類似啊，直接使用線程不更好嘛。如果是用epoll的話，直接單線程在epoll處wait就好。

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

struct, union的sizeof問題這個才是常識性的問題，尤其對于網絡間傳輸?shù)臄?shù)據(jù)結構，這是必須知道的基礎性問題。

@sgsoft
win上實現(xiàn)了socket上真正的AIO，*inx上基本上都沒有針對socket實現(xiàn)真正的AIO。本文主要針對linux平臺，其他平臺不很熟悉，并且沒機會接觸，也無法寫代碼進行測試，因此AIO的模型就沒涉及。
另詳細分類2里的模型（5）模擬了AIO的實現(xiàn)，也就是proactor的模擬。

是啊 有問題就問題本身探討 涉及到人身 甚至去猜測別人的水平 不利于解決問題啊 來來回回凈扯蛋了

不好意思 請關注私人留言！

@飯中淹
牛啊 果然是最好的內存copy實現(xiàn)，竟然還實現(xiàn)了跨平臺
要是加上inline 或者用包裹宏代替函數(shù)就更完美了 哈哈

@Fox
沒看過memcpy strcpy庫函數(shù)實現(xiàn)的，給出按位處理的想法很正常。就像去寫strcpy，檢測空指針、越界、返回結果指針就很好了，一定要求他給出類似庫函數(shù)實現(xiàn)的高效不太現(xiàn)實，也沒啥意義，就象研究茴香豆的茴有幾種寫法一樣。反正實際開發(fā)中不用，就是虛無縹緲的想想。

呵呵
考察memcpy內存地址的字節(jié)對齊問題 對實際的開發(fā)有啥意義嗎？

@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就是無鎖的實現(xiàn)。 ”

@wk
一般backlog是兩個隊列大小的和，比如設置為5就是兩個隊列的長是5，隊列滿了，再有連接到來就拒絕。但是有的系統(tǒng)，你設置為5，實際隊列大小可能是10，你設置為10，隊列實際大小可能是20，就是有的系統(tǒng)有個系數(shù)。

莫非又不了了之了？

不錯！
c語言的程序里經常是遍地的宏 遍地指針的精巧使用

宏還是非常不錯的 類似c語言中的模版機制
內核里的經典數(shù)據(jù)結構及其算法，象SLIST LIST TAILQ之類的都是宏寫的

很簡單 未初始化的變量行為未定義，未定義就是怎么都可以
就象調式環(huán)境是true 并不能保證exe是true
在本機是true 并不能保證另一個機器上也是true

呵呵 我也是因為socket的原因 看的perl 現(xiàn)在服務器的陪測程序 都是用perl寫的。特適合寫陪測腳本。下面是我以前寫的幾個服務器的陪測腳本http://www.shnenglu.com/CppExplore/archive/2007/12/04/37752.html

不錯，如此簡單，
簡單的不適宜放在首頁了 呵呵

@苦味酸
c#的問題建議去博客園問，這邊看樣子知道的不多。另有留言給你。

@鑄鑄平板
為啥在這里發(fā)廣告呢
這里是c++技術blog，沒人買生鐵的。

這個要頂！

沒有模版需求的時候 總也不知道使用它的原因
有需求的時候 自然就知道為何使用它
呵呵 順其自然

“這里，我提出另外一種比較獨特的做法，就是......”
呵呵，兄弟啊，我畢業(yè)答辯的時候，老師就反復的批評我們，“我提出.......”，“我發(fā)明......”之類的東西。
文中就是《unix網絡編程》中的預派生進程阻塞在accept的方式嘛。
并且書中說明這種問題有驚群問題，可以前面加文件鎖或者線程鎖互斥，你文中加的是互斥鎖。現(xiàn)在的linux從2.2.9版本起就不存在驚群問題而不需要加鎖了，更好的是2.6內核的線程庫中線程鎖不陷入互斥狀態(tài)的話就不會陷入內核態(tài)了，加不加性能一樣。而win就沒有這么好的線程鎖。
多進程方式編程簡單，程序健壯性相對比較好，但是切換開銷比較大。現(xiàn)在的更傾向于預派生線程的方式。
另可以，起多個多線程的程序，bind不同port，前端部署lvs提供均衡負載一樣可以達到更好的多進程效果。

php jsp asp asp.net之類的根本不能算是網絡編程，也就是web編程，不需要多少知識深度，競爭也很激烈。
vc做圖形開發(fā)還是非常有前途的，其他的不知道了。
c++ c編程 或者嵌入式都還是轉向linux平臺吧。

@火夜風舞
兄弟真實在。呵呵 ：）

@eXile
呵呵，還沒用庫。
是我最近正在梳理網絡模型。這幾天正在寫各種模型的網絡程序并測試性能。
等搞完這個再看各種庫是如何實現(xiàn)這些模型以及其性能如何。

說錯了 呵呵 三次握手在accept前就完成了 從完成隊列里取而已

第一部分（2）的結論不太對。
主線程偵聽，預派生的線程處理業(yè)務，這個稱為模型A吧.
leader/follow這里稱為B.
我服務器的4核的SMP，linux 2.6內核，測試工具ab，小壓力的測試不說了，都能達到17000左右，測試項如下：
ab -c 4000 -n 40000 http://172.24.252.248:5000/
預派生線程數(shù)量都是4。
壓力測試的結果是：
業(yè)務邏輯簡單的時候（僅僅是讀數(shù)據(jù)，然后resonse200OK）:
B模型多次測試平均的結果大約是每秒8500。
而A模型的性能和緩存隊列的大小有關，當緩存大小取500時，和B模型性能相當。取1000，測試的平均結果大約是每秒9500。取100則降低為6500左右


猜測原因：linux的pthread_mutex_t既然是非暫停點的實現(xiàn)，那么它的性能一定很好，遠好于條件鎖、信號燈等。pthread_cond_t則是暫停點的實現(xiàn)，可能把線程推向睡眠。增大緩存大小，可以有效減少對pthread_cond_t的系統(tǒng)調用。

另根據(jù)對各種模型的測試，accept的處理速度非常非常的塊，簡單的業(yè)務處理時間也要比accept的處理低一個數(shù)量級。因此單一線程處理accept，可以盡快建立三次握手，進入緩存隊列等待。

因此猜測 如果業(yè)務為復雜邏輯（實際測試加了4個循環(huán)相加，一句打印的log）的話，模型B的性能將進一步下降。增大業(yè)務處理復雜度后的結果果然如此，模型B的處理降低為6500左右，而模型A在1000的緩存下，每秒的處理能力還是9500左右。

頂 不錯
內存申請針對線程內還是跨線程 決定是否采用加鎖策略，為了差異化這種處理，在內存池上進行進一步的封裝 不錯！

@陳子文
：）
轉載請著名下 多多交流！

上面的語句外面都是foreach(ch in str){}。
hash表的數(shù)量 應該不是影響hash的因素吧 想不出來原因。貌似一般都把hash表的桶數(shù)量設置的很大，是實際使用到的3倍多。

java里的hash是乘以31的：hash=hash<<5-hash+ch。
據(jù)說就英文而言，乘以33的是最優(yōu)的：hash=hash<<5＋hash+ch，這個也是apache stl等一大堆著名項目或庫的hash方式。
特定應用而言，還是要根據(jù)特定的數(shù)據(jù)，設計最優(yōu)的hash函數(shù)。

空間有毒！！！！大家小心
@浪跡天涯
如果是什么計數(shù)器卡著了，也請修改正常。

非常不錯！這6個原則概括的還真是精辟！

非常不錯！這6個原則概括的還真是精辟！

暈倒..........................

問題的關鍵不在UserAlloc，而是details::PODptr<size_type> 。除非你想在內存池之上實現(xiàn)這個內存池的UserAlloc（到底是先有雞還是先有蛋......），即便這樣，當前的object_pool析構最少也要付出o(n)的代價。

@eXile
：）
“從收到一個包，到對這個包的處理完畢，則可視為內存的一個周期。”，這時候析構object_pool不恰當，因為以后還會收到包，內存還可循環(huán)被使用，這里還是應該調用destroy，而它的時間復雜度o(n)，導致了真是不太適合使用。析構object_pool更不可取，時間復雜度不說，還有內存的再次申請，背離了內存池的初衷。

@eXile
暈倒 在boost/pool/detail/pool_construct.inc里
只關注hpp去了
可以調用任意的構造函數(shù)
多謝指正！正文中現(xiàn)已標明。

另：boost/pool下的6個hpp文件我是挨個讀過了。detail下的都很簡單，5個hpp，singleton.hpp有效行數(shù)就10幾行，沒看，想當然了下。mutex和guard在讀singleton_pool.hpp的時候看了下linux下的mutex，順便還測試了下，gcd_lcm的兩個也很簡單，沒看，估計大約是2者求最小值的功能。
我一貫認為，明白原理，知道如何使用就好，深入具體細節(jié)就是浪費腦細胞，如果你要實現(xiàn)一個當然例外。

本站n多人搞圖形啊

@Enoch
呵呵，借用一句流行話：您的回帖是我繼續(xù)的最大動力。
謝謝

@空明流轉
這個現(xiàn)在還是只能停留在美好的展望階段，不過這一天的到來不遠了。

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

@eXile
AutoFreeAlloc的發(fā)展方向應該就是apr_pool。apr_pool已經把變長的內存池發(fā)展到極致，當然這是當前看到的，或許以后有內存池會把變長內存池推到一個新的高度。：）
支持多線程的內存池都是從單線程加鎖機制實現(xiàn)的，都提供無鎖的實現(xiàn)。apr_pool也是，顯式構造allocator后不調用apr_allocator_mutex_set就是無鎖的實現(xiàn)。
后面的boost和loki的無鎖和有鎖的實現(xiàn)區(qū)別更是明顯。

@空明流轉
歡迎光顧本帖。：）
隨意起的名字，沒啥含義，再下個定義就咬文嚼字了，呵呵。
當然系統(tǒng)的核心是業(yè)務。系統(tǒng)設計可以說有技術層面的有業(yè)務層面的。
我主要想寫點技術層面的東西，分享一下個人的感想。一大堆亂七八糟的東西，想不住什么共性來，就隨意起了這個名字。

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

開業(yè)大吉啊！！

原來是本blog的開山文章啊
使勁頂啊

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

先頂下 慢慢看
以前看astrisk的源碼（c語言實現(xiàn)） 覺得它的架構就完美了 所有模塊都可以動態(tài)加載 卸載，所有接口都可以動態(tài)注冊 注銷。
貌似ace里也有組件配置框架，還沒研究過。
文中的poco的支持 很有吸引力啊

為啥就不用內存數(shù)據(jù)庫呢

意義不大
首先 無論是win下還是linux下 都有很出色的內存檢測工具。這些工具已經成為測試程序的必須，而不是可選。
其次 不論是內存檢測工具 還是文中所述方法 都只能檢測嚴格的內存泄漏，比如base *a=new A(); base *b=new B(); a=b;則對原a的內存控制完全失去，此為內存泄漏。完全的內存檢測 還要配合 完善的log機制 交互式查看系統(tǒng)信息等附加功能
最后，小trick，又是轉貼，和樓上意見一樣，就不要放首頁了。