問(wèn)題描述

我在通訊底層使用了一個(gè)epoll模型，然后epoll在處理請(qǐng)求時(shí)會(huì)將請(qǐng)求交給一個(gè)線程池去處理，線程池中的線程則是調(diào)用上層服務(wù)，上層服務(wù)因?yàn)樯婕暗骄W(wǎng)絡(luò)通訊，所以大致處理一個(gè)請(qǐng)求不到10ms

就這樣一個(gè)模型在流量增大時(shí)會(huì)導(dǎo)致CPU急劇飆升嗎？

背景：我的CPU使用率大概在75%左右（流量：20～22Mbps）；當(dāng)流量增大到25Mbps的時(shí)候，CPU直接打滿了。。這個(gè)不是很符合預(yù)期，因?yàn)榱髁吭黾硬坏?5%，但是CPU飆升25%。

問(wèn)題解答

簡(jiǎn)單說(shuō)下我的觀點(diǎn)，僅供你參考哈：1：先考慮你的請(qǐng)求是IO密集還是CPU密集？我說(shuō)的IO密集是指需要read和write收發(fā)消息的網(wǎng)絡(luò)IO，也就是通信；CPU密集例如需要經(jīng)過(guò)運(yùn)算才能出結(jié)果，且時(shí)間較長(zhǎng)。2：如果是第一種IO密集型的，那我覺(jué)得你沒(méi)必要把所有的請(qǐng)求都交給線程池去處理。如果沒(méi)有讀寫文件等磁盤IO耗時(shí)的操作,甚至都不一定使用線程池。這種方式下 One loop per thread模型無(wú)疑是最高效的了，說(shuō)白了就是在單個(gè)EPOLL中完成所有的讀寫（網(wǎng)絡(luò)數(shù)據(jù)的讀寫，而不是讀文件）和定時(shí)事件。3：如果是CPU密集型的，那用thread_pool沒(méi)有問(wèn)題，就看你的配置的線程數(shù)和代碼有沒(méi)有問(wèn)題了。

這個(gè)問(wèn)題沒(méi)有實(shí)際環(huán)境也不好回答，我全當(dāng)拋磚引玉，不對(duì)的地方望指出。