请大家推荐些服务器架构方面的资料。

[yxt...@gmail.com]

网上找到得的资料都是讲socket等程序编码的问题，少有讲服务器架构设计的资料，请大家推荐些这方面资料，有下载地址更好，谢谢。

[ideawu]

仔细看看 http://groups.google.com/group/dev4server

下方有下载链接.

ideawu http://www.ideawu.net/

-------------------------------------------------------------
On 2007-12-13 17:53:37, yxt945<yxt...@gmail.com> wrote
Subject：请大家推荐些服务器架构方面的资料。

[yxt...@gmail.com]

多谢ideawu，我先看看。

On Dec 14, 7:27 am, "ideawu" <ide...@163.com> wrote:
> 仔细看看http://groups.google.com/group/dev4server
>
> 下方有下载链接.
>
> ideawuhttp://www.ideawu.net/

[stephen.nil]

Hi，all

对 apache 等几个基于进程池的服务器进行了一段时间的调研，发现难于把 apache 的进程池部分单独抽出来使用。
因此实现了 SPProcPool 这个框架。这是一个 linux/unix 平台上的进程池服务器框架，使用 c++ 实现。
主要包含了几种不同类型的进程池的实现：一个基于 Leader/Follower 模式的服务器端进程池（类似 apache 的 prefork 模型），一个基于文件句柄传递的服务器端进程池，一个用于非服务器端的进程池。

http://code.google.com/p/spprocpool/

对 Leader/Follower 和文件句柄传递两种类型的服务器框架进行了对比测试：
采用的测试模型是《Unix网络编程（第二版）》第27章的模型。对书上提到的 client 测试工具做了一下修改，加上了 client 端的时间测量。
测试的时候，两种框架都预先启动 10 个进程，并且 client 端也只跑 10 个进程，每个进程顺序发起 100 个请求，每次请求 512 字节。
针对每种框架，连续运行 client 10 次。每个 client 进程结束的时候，都输出它的总运行时间。最后要对比的就是进程的平均运行时间。

结果：
Leader/Follower 2635 / 100 = 26.35 (毫秒)
Descriptor Passing 3644 / 100 = 36.44 (毫秒)

简单来说，就是在 Leader/Follower 框架下，一个进程处理 100 个请求需要耗时 26 毫秒，而在另外一个框架下，需要 36 毫秒。

使用多进程的一些好处：

预先派生模型有一些优点，例如健壮性以及可靠性。如果子进程异常退出，那么服务器就会丢失一个连接，而且仅仅丢失一个连接。服务器的其余部分还将继续运行，并且可以为请求提供服务。唯一可以注意到问题出现的用户就是不幸地进行了导致问题地请求的用户。
类似 apache 的 MaxRequestsPerChild 选项，可以防止(偶然的)内存泄漏无限进行，从而耗尽内存。

Best Regards，

Stephen Liu

[zhongqing zhang]

不错。定

在07-12-23，stephen.nil <steph...@gmail.com> 写道：

[huzhang...@gmail.com]

可以看看我的博客
http://www.libing.net.cn

[xMan]

服务器的类型海了去了,谁也无法知道你想要什么类型的服务器资料(MMO?休闲?P2P?FTP?HTTP?.....)