高并发的问题

群雄逐鹿

code review了一下，说太多了，上面的兄弟莫见怪，提最后一个问题，先闪了
这个usleep, 在某些机器上跟busy wait无异，正可起到 ”拖慢event loop, 延迟系统响应" 的神奇功效。

1. 
   
2. while(1)
   
3.             {
   
4.                 evbase->loop(evbase, 0, NULL);
   
5.                 usleep(10);
   
6.             }
   

复制代码

swxlion

原帖由 yulihua49 于 2009-8-11 17:17 发表

更注重的是数据库。语言本身并发性没问题，多处理器，多进程就可以了。
多线程的并发是有条件的，不能太多互斥。

不太同意。
对很多项目来说，数据库绝对不是瓶颈。数据库是很慢很低效，但为什么不写一个，或者一组数据库前端Cache服务器呢？难道我们的Google每搜索一次就查一次数据库？
AMD（add/insert, modify/update, delete/drop）全部通过DFCS（数据库前端cache服务器）走。具体怎样操作数据库，同步还是异步，那就是DFCS的事了。有没有数据库对应用程序完全透明。

原帖由 redor 于 2009-8-17 15:41 发表
高并发跟多线程有毛关系啊， 会设计一个线程也能实现高并发， 不要用自己那点浅薄的知识误导群众！
多线程不过就是给那些不懂怎么时间分片的人取做强制时间分片。。。。。。
土鳖的技术方案只会害人！

同意。高并发和多线程没有必然关系。过多的线程导致上限文频繁切换，反而有可能影响并发性。

原帖由 cwgk 于 2009-8-11 08:54 发表
请版上的高人指教，欢迎大家谈出自己的观点。以下是我的问题：

在进行服务器开发时，强调高并发这个特性，但是在设计中需要考虑那些方面，需要采用什么策略或机制？
平台为Linux/Windows，语言为C、C++。

楼主的这个问题其实是需要具体情况具体分析的。
就像问：穿哪件衣服合适一样，对应不同的人（不同的应用情况），答案是完全不一样的。没有一个普适的策略或机制。

但一般需要考虑的范围还是有的：
IO效率：
至少肯定包含网络IO的调度逻辑。这里不光是IO模型，还涉及到对IO模型的调度操作的逻辑。
此外如果涉及到文件读写，或者内存需求巨大的情况，还涉及到磁盘IO（对于内存需求巨大而无文件读写的情况，实际上是内外存交换导致的磁盘IO，而这个时候，使全部交给OS调度，还是自己介入处理优化，这就是设计人员决定的啦）。

代码逻辑效率：
因为即使IO效率再高，但如果代码处理效率很低，比如将一个20KB的数据搞上1k个副本，处理完后才返回的话，这其实是很没效率的。而这直接导致你返回结果的拖延，从而间接导致并发的下降。所以这里其实有很多性能优化的地方。
最简单的，如果数据足够复杂，千万不要使用STL，即使它再方便在简单也好。最简单的一个原因：
我跟踪过Fedora 4上的map。我压入一个类实例后，先后拷贝构造4次，析构3次，这个insert操作才算完成。如果你的泪足够复杂，而且包含很多不必要的清空操作，比如：
memset（dest, 0, 1024）
之类的，然后比如说面对一个查询系统，2000万条数据，因为数据关联的需要，会有10来层嵌套的map结构。这个时候，你insert一个数据，带来的可能就是相当可怕的累积效应。这也就是为什么我为我的项目专门写了GDST这个字项目的原因。用着虽然比STL麻烦些，但效率保证。
但如果你面对的情况并不是这么麻烦，那STL还是放心大胆地用好了~~~~

lock-free：
如果有很多并行化的操作，尽量做到lock--free，因为这是提高代码效率，减少等待的一个很重要的方法。效率提高了，至少不会拖并发性的后腿。

多线程/多进程的合理设置：
这个取决于硬件系统的设置。进程和线程并不是越多越好，因为频繁的上下文切换，会浪费很多的CPU时间，甚至引发频繁且大量的磁盘IO（虚拟内存内外存交换）。最理想的状态是：一个CPU core上就只运行一个线程，没有上下文切换。当然，这也太理想了~~~~

redor

原帖由 ddkkd 于 2009-8-17 16:29 发表
15楼的兄弟，你这个写网络部分有问题吧？随便浏览了下那个server.c。说下，勿怪。
看到你那个非阻塞connet，就好像不对吧，你看看。
难道以前你用自己这套代码连接的时候没出现问题？不可能吧。呵呵

那个地方只是connect 在conn.c里会对connect是否成功有检查。。。。。

redor

原帖由 群雄逐鹿 于 2009-8-17 22:18 发表



FD_ZERO(&rd_fd_set);
        memcpy(&rd_fd_set, evbase->ev_read_fds, sizeof(fd_set));
        FD_ZERO(&wr_fd_set);
        memcpy(&wr_fd_set, evbase->ev_write_fds, sizeof(fd_set));
     ...

select（） 本来效率就不高， 我不推荐大家使用select， 我的evbase会自动选择最高效的模型， 一般linux下会使用epoll bsd／osx 下会使用kqueue

redor

原帖由 群雄逐鹿 于 2009-8-17 22:29 发表
这个 buffer[fd] 更加诡异了，
内存浪费先不谈，fd的值会限定在CONN_MAX ？

你看的是ev_serv里的代码吧， 这个只是一个测试代码，不是核心代码，当时就是为了方便做demo就直接这么写了，这个只是用来测试evbase的一个代码， 感谢你这么细心挑出来。

redor

原帖由 群雄逐鹿 于 2009-8-17 22:34 发表
还有这里

n = recvfrom(fd, buffer[rfd], EV_BUF_SIZE, 0,
                            (struct sockaddr *)&rsa, &rsa_len)) > 0 )
            {
                buffer[rfd][n] = 0;


n如果正好 ...

buffer[] 是一个 char* 的数组， 每个单元的char *最大长度就是EV_BUF_SIZE n < EV_BUF_SIZE, 怎么可能 =＝ 0 呢？

redor

原帖由 群雄逐鹿 于 2009-8-17 22:29 发表
这个 buffer[fd] 更加诡异了，
内存浪费先不谈，fd的值会限定在CONN_MAX ？

我不知道你是否真的做过这类的开发， CONN_MAX你可以自己设定， 一般人用的系统不会超过20000连接， 因为机器的运算能力是有限的，大了整体的性能会下降，也起不到高并发的作用。
个人觉得你没写过几行程序， 呵呵，要么就是看书远多于写的代码。
看你给我回复了那么多我也不好意思不说明一下，你有兴趣可以看我更多的代码，也多谢各位赐教！

redor

原帖由 群雄逐鹿 于 2009-8-17 23:01 发表
code review了一下，说太多了，上面的兄弟莫见怪，提最后一个问题，先闪了
这个usleep, 在某些机器上跟busy wait无异，正可起到 ”拖慢event loop, 延迟系统响应" 的神奇功效。

while(1)
       ...

我尝试过sleep 不过 sleep的时间对于并发比较高的系统和消息队列的系统来说不适用， 这样会降低总体处理消息的速度， 目前测试来看usleep比sleep好用一些， 但是这个usleep设置太小的话也会让cpu占用过高， 反而不好。

cookis

干吗要用sleep .不是有事件通知机制吗？

群雄逐鹿

原帖由 redor 于 2009-8-18 13:41 发表

个人觉得你没写过几行程序， 呵呵，要么就是看书远多于写的代码。
看你给我回复了那么多我也不好意思不说明一下，你有兴趣可以看我更多的代码，也多谢各位赐教！

还真刺激我呀，呵呵。。很多都是基本功了。别生气，是我多语了，向你道歉。
也希望你能一贯的坚持己见，即使程序当掉