1. 程式人生 > >多執行緒情況下慎用localtime_r

多執行緒情況下慎用localtime_r

最近有個需求,需要提升日誌模組的效能。當前日誌模組每秒鐘處理的日誌數量大概在55w左右,於是進行優化,在日誌的IO執行緒中將sprintf剝離,提前將時間、日誌等級等格式化處理。

於是這樣就產生了一個問題,在IO執行緒中頻繁的使用localtime_r來獲取日期時間,在單執行緒中效能影響可能不大,然而我將localtime_r移動到各工作執行緒後,首先在windows下效能還是有55%左右的提升的,大概從56w到87w,而在linux下面,發現日誌處理量居然只有20w左右,反而下降了50%,真是一件非常奇怪的事情。

在每個地方進行瓶頸測試,發現在localtime_r中消耗了大量的時間,造成了工作執行緒丟入IO執行緒的量降低了,其實IO的效率是高了,但是工作執行緒的效率卻降低不少。後來查詢了不少資料,發現在localtime_r中有鎖,而多個工作執行緒同時請求時候,就造成了有些執行緒等待,效能確實會下降不少。

於是改成用gettimeofday來計算時間,日誌的精度只需要到秒而已,這個函式夠用了。唯一需要注意的是它的第二個引數有個時區的域,本機返回的值是-480,就是北京時間相對於格林威治時間提前了480分鐘,所以根據時間戳計算日期時間的時候需要將時間戳偏移的時間加上一起算。