我在通訊底層使用了一個(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%。
1
0
0
認(rèn)證高級(jí)PHP講師
簡單說下我的觀點(diǎn)，僅供你參考哈：
1：先考慮你的請(qǐng)求是IO密集還是CPU密集？我說的IO密集是指需要read和write收發(fā)消息的網(wǎng)絡(luò)IO，也就是通信；CPU密集例如需要經(jīng)過運(yùn)算才能出結(jié)果，且時(shí)間較長。
2：如果是第一種IO密集型的，那我覺得你沒必要把所有的請(qǐng)求都交給線程池去處理。如果沒有讀寫文件等磁盤IO耗時(shí)的操作,甚至都不一定使用線程池。這種方式下 One loop per thread模型無疑是最高效的了，說白了就是在單個(gè)EPOLL中完成所有的讀寫（網(wǎng)絡(luò)數(shù)據(jù)的讀寫，而不是讀文件）和定時(shí)事件。
3：如果是CPU密集型的，那用thread_pool沒有問題，就看你的配置的線程數(shù)和代碼有沒有問題了。
這個(gè)問題沒有實(shí)際環(huán)境也不好回答，我全當(dāng)拋磚引玉，不對(duì)的地方望指出。
