SPServer： 一个基于线程池（包括HAHS和LF）的开源服务器框架

iceviewer

  学习中，谢谢啦

iunknown

原帖由 zsniper 于 2007-12-18 09:32 发表
请问LZ，你的SP框架的服务器，是那种客户机请求，服务器相应的模式，那假如服务器主动广播，该如何使用你的这个框架呢~？

是不是再本地建立一个连接，好像GM一样 ， 向在线的所有人广播？


还是直接创建 ...

SPServer 目前已经实现的广播功能是针对聊天室这种功能，在同一个聊天室中的各个 client 之间广播消息。
如果要实现服务器主动广播，目前来说只能使用你提到的“在本地建立一个连接，好像GM一样 ， 向在线的所有人广播”。
采用这种方法，这个本地连接发送一个特殊的数据包过去，在 SP_Handler::handle 中识别出这个特殊数据包，从而触发广播事件。

zsniper

恩。。。谢谢LZ，我想了一下也只有这种方式。。。

zsniper

再次请问LZ，HAHS和LF，感觉都是那种高并发的服务器 ，感觉他的相应不是很快？

iunknown

原帖由 zsniper 于 2007-12-28 10:31 发表
再次请问LZ，HAHS和LF，感觉都是那种高并发的服务器 ，感觉他的相应不是很快？

之前曾经用 spserver 实现过一个类似 memcached 的 spcached ，测试结果如下
# 500000 sets: 229266ms     2173 次每秒
# 500000 gets: 284856ms     1754 次每秒
采用的是长连接。
具体的测试数据可以参考：http://iunknown.javaeye.com/blog/80095

刚刚又测试了短连接的情况，采用了测试 spprocpool 的方法。

spprocpool的测试结果：http://bbs.chinaunix.net/thread-1026543-1-4.html
Leader/Follower       2635 / 100 = 26.35 (毫秒)
Descriptor Passing   3644 / 100 = 36.44 (毫秒)

spserver的测试结果：
Leader/Follower 10 个线程：5220 / 100 = 52.2 （毫秒）
HAHS 10 个线程：  10126 / 100  = 101.26 （毫秒）

测试结果比进程池差，因为在进行这个测试的过程中，使用 spserver 实现的时候，多了一些队列管理和内存的 copy 。
这些多出来的队列管理和内存 copy 主要的目前就是为了提高并发度。

如果不使用 spserver ，直接使用一个连接一个线程的线程池方式，估计和进程池应该差不多。
但是这种 Thread Per Connection 的方式，在并发度上就不如 spserver 了。

[ 本帖最后由 iunknown 于 2007-12-28 23:34 编辑 ]

zsniper

请问LZ，有没有计划写一个UDP的框架呢？

我觉得那样的话，session manager就必须根据client的IP和Port构造hash表了，

iochannel中只能调用多次sendto了

希望LZ能重构一下UDP框架哦

[ 本帖最后由 zsniper 于 2008-4-21 13:12 编辑 ]

iunknown

原帖由 zsniper 于 2008-4-21 13:09 发表
请问LZ，有没有计划写一个UDP的框架呢？

我觉得那样的话，session manager就必须根据client的IP和Port构造hash表了，

iochannel中只能调用多次sendto了

希望LZ能重构一下UDP框架哦

能不能说明一下具体的应用场景呢？

SPServer 设想的应用场景主要是两类：
1. 类似 http ，request/response ，业务处理过程中，可能需要一些耗时的 IO 操作，比如访问数据库，本地文件
2. 类似 IM ，大并发长连接，业务处理过程中，可能需要一些耗时的 IO 操作，比如访问数据库，本地文件

这里提到的 UDP 服务器，设想的应用场景是怎么样的呢？

[ 本帖最后由 iunknown 于 2008-4-21 13:32 编辑 ]

zsniper

P2P的打洞服务

vivid333

对于spserver-0.9.5的testecho进行压力测试时（测试的client端不断的进行connect, send,recv操作，但不会进行close socket, 即模拟长连接）遇到了如下1个问题。


问题一： sp_session.cpp中的allocKey 返回0， 导致assert直接将程序exit.
                    testecho: speventcb.cpp:116: static void SP_EventCallback:nAccept(int, short int, void*): Assertion `sid.mKey > 0' failed.
                    已放弃



在基于spserver的HA－HS架构，进行上层应用（接口实际就是类似testecho.cpp), 遇到如下2问题
问题1：  evbuffer_free () 引起程序core, (应该是double free, 但上层也没创建msg类型，仅是起了个spserver)
        #0  0xb7fe2430 in __kernel_vsyscall ()
        #1  0xb7b29651 in raise () from /lib/tls/i686/cmov/libc.so.6
        #2  0xb7b2ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
        #3  0xb7b6049d in ?? () from /lib/tls/i686/cmov/libc.so.6
        #4  0xb7b6a591 in ?? () from /lib/tls/i686/cmov/libc.so.6
        #5  0xb7b6bde8 in ?? () from /lib/tls/i686/cmov/libc.so.6
        #6  0xb7b6eecd in free () from /lib/tls/i686/cmov/libc.so.6
        #7  0xb7f94111 in evbuffer_free () from /usr/lib/libevent-1.4.so.2
        #8  0xb7fb7ed9 in ~SP_Buffer (this=0xb5c006f0, __in_chrg=<value optimized out> at spbuffer.cpp:41
        #9  0xb7fb7635 in ~SP_Message (this=0xb5c006b0, __in_chrg=<value optimized out> at spresponse.cpp:95
        #10 0xb7fb2666 in SP_DefaultCompletionHandler::completionMessage (this=0x8067c30, msg=0xb5c006b0) at sphandler.cpp:37
        #11 0xb7fb6b78 in SP_Server:utputCompleted (arg=0x806a84 at spserver.cpp:145
        #12 0xb7fb29c3 in SP_SimpleTask::run (this=0x806a700) at spexecutor.cpp:37
        #13 0xb7fb30c8 in SP_Executor::worker (arg=0x806a700) at spexecutor.cpp:132
        #14 0xb7fb3053 in SP_Executor::eventLoop (arg=0xbffff5a4) at spexecutor.cpp:116
        #15 0xb7fc796e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
        #16 0xb7bcca4e in clone () from /lib/tls/i686/cmov/libc.so.6

问题2: 报错，不知道什么原因
      session(1027.0) busy, process session error later









有遇到此问题的大侠吗？请求指点迷冿，小弟在此十分感激！

yulihua49

多谢！你这样说，我很大压力啊。。。。。

关于 HSHA ， LF 线程池，还有 reactor ，proactor 这些 ...
不知这里有没有人做过类似的框架？或者有没有人希望使用这样的框架？希望能获得大家的建议，继续完善。

iunknown 发表于 2007-07-05 13:20

做过，用着呢。
不过是基于C/S/S模型，不是http的。

开始也是epoll_wait由一个线程做，然后提交到队列，后边是个线程池进行应用处理。
后改为线程池直接在epoll_wait竞争，效率提高了一些。
没有采用ssl，自己处理压缩加密，性能更高一些。
做了个专用的proxy，16核服务器，TCP长连接服务，G网，达到并发10000连接，
后台LVS，8个16核RS，每秒转发62200个交易。