线程性能到达瓶颈，并发还是并行？

chenxing2

回复 10# heguangwu

这样看就是 pcapThread 抓包的速度跟不上了。

LibPcap这玩意记得在资源不足以再容纳下一段数据时，会丢弃数据。

建个线程池，在loop的时候，拿到数据直接扔到线程池然后再后面的处理，每次也多收些包


   

heguangwu

我们的问题其实已经解决了，通过调整pcap的参数和进程优先级再加上之前的由互斥锁修改为条件变量、锁的同步范围等方法，现在已经丢包很少了

回复 11# chenxing2


   

文峰聊书斋

e_zpoll的方式呢？

流氓无产者

这个有点儿困难吧，需要实际操作先找到瓶颈，再对症下药

奇怪的蜀黍

“ 最初是一个单线程程序性能到达瓶颈后，通过将整个作业切成一个个小任务，每一个任务执行一个线程，运行结果发现居然和之前差不多”
采用多线程，很多时候是为了防止在某个部分响应时间过长，影响其它的操作。
如果你的程序性能达到了瓶颈，仅仅想依靠多个线程分担来提升性能。这样的想法是不可行的。

yulihua49

heguangwu 发表于 2015-12-04 14:50
首先，跟大家分享个陈年趣事:
几年前，我去某软公司应聘，电话面试中与面试官有如下一番对话。 面试官：你 ...

我不知道你说的并发还是并行。从另一个角度说：

你这是想搞并发算法。每种业务不同，设计专门的算法，一是很费力，二是达不到充分运用核，三是不通用，没有普适价值。
现在更多的做法，算法是串行的。把数据分成多组，分发到多台服务器，由多个线程并行处理。
系统由任务分发器（数据分组，负载均衡）------>  多台应用服务器（每台多线程）<------> 数据库（ORACLE+RAC）
这是一个可伸缩结构。如果计算密集型，把应用服务器多配些。如果IO密集型，把数据库配强大些。
如果是网络密集型（数据传输量特大），我们在分发--->服务环节采用压缩/解压缩，把网络瓶颈转化为计算瓶颈，多核多线程并行处理化解之。
对于服务器里的线程来说，所有的线程做所有的事，就是对称多处理，这样负载很容易均衡的。

总结下：
算法串行，处理分段并行，系统可伸缩（每个段的资源可伸缩）。

这本来是很成熟的技术，使用交易中间件进行任务分发，完成map-reduce功能。

demilich

回复 5# heguangwu


    一般来讲使用多线程要依赖于做的操作室计算密集型还是I/O密集型。根据描述，pcapThread似乎是有读写操作，而TcpProcThread/MysqlProcThread其实都是编解码，不牵涉阻塞操作，如果是这样为什么不把他们两个线程合并到一起呢？还是说，每个线程已经绑定到某个cpu核上了？

demilich

抛砖引玉一下，尤其如何使用多线程，什么时候用，怎么用，还希望高手指教。

1. 阐述一下你设计过的最满意的并发/并行软件架构。
线程池+多个FIFO队列，这种类型应用范围最广

2. 详细描述一下在多线程/进程/协程方式下遇到过的最难解决的问题以及如何解决的
看似很莫名其妙的问题，最后解决的时候，会发现一般不外乎函数线程不安全/死锁/锁的太大导致性能差

3. 详细讲述一下曾经使用过的最好的并发/并行组件
尝试过TBB和openMP，谈不上更多的经验

4. 对并行/并发的某一个理论进行详细的说明
我的理解：是否要用并发，最简单还是要看应用类型，如果仅仅是单核环境的无阻塞计算密集型的任务，无需并发多线程，光是计算就可以把CPU全部占满;如果CPU是多核，此时是要用多线程的，这样可以调动更多的CPU参与运算。再有就是有阻塞的任务，此时才是并发的用武之地，无论单核多核，多线程都可以提高程序的效率，把CPU充分利用上，因此如何识别阻塞就比较重要了：常见的就是I/O和UI操作 ...

hellioncu

就你那案例，我觉得线程分太多了，TcpProc和MysqlProc都是些内存运算，应该合到一起。我不知道“rdkafka库”，如果其内部有队列机制，可以异步，那么也不需要这个单独的发送线程。