用iTreads技术写的WebServer好吃内存

hoowa

环境：W2KProfessional
Perl：AcitvePerl5.8
技术：IO::Socket::INET与ithreads技术

发现问题：
慢速侵蚀内存，每次几十K到几百K。如果请求多了比较明显，请求少的时候看不出来。

我间段性非有序请求程序，达到2000次内存已经从刚开始的3.xxxMB升到11.152MB

CPU占用率平均一个请求就达到10%左右。如果请求多了以后会达到85%左右

不知道是我代码的问题还是ithreads的问题，同样代码使用IO::Select技术未出现这些问题

代码如下：
#!/usr/bin/perl
use IO::Socket;
use threads;

#构造SOCKET对象,打开端口
my $socket = IO::Socket::INET->;new( LocalPort =>; '8080',
                                                                        Listen =>; SOMAXCONN,
                                                                        Reuse =>; 1 );
my $CRLF = "\015\012";
my $count = 0;

warn "Server runing.....\n";

my $all_count = 0;

#等待,直到有事情发生
while(my $client = $socket->;accept) {
        $count++;
        threads->;new(\&proc,$client);
}

close $socket;

sub proc
{
        my $handle=shift;
        my $request = <$handle>;;

        $body = qq~Hello World!
                <p>;Server API Countcount
                ~;
        $length = length($body);

        #print the header
        print $handle "HTTP/1.0 200 OK$CRLF";
        print $handle "Content-length: $length$CRLF";
        print $handle "Content-type: text/html\n\n$CRLF";
        print $handle $CRLF;
        print $handle "$body";
        threads->;self->;detach;
        $handle->;close();
}

ocean2000

咳~PERL的threads太不爽了，好像如果用线程超过10个，调用系统命令的话，很快就要死记，但是fork()在 win下还不如不用，select还是不错的

hoowa

我更愿意以我没有正确使用来解释问题。

可能是blocking造成的问题。

如果请求很少的情况下不会出现吃内存。如果请求多了服务器无法响应造成blocking


我的假设

ocean2000

呵呵~当然是我自己学艺不精啦

apile

http://www.perldoc.com/perl5.8.0/pod/perlthrtut.html
看看吧...
Performance considerations
The main thing to bear in mind when comparing ithreads to other threading models is the fact that for each new thread created, a complete copy of all the variables and data of the parent thread has to be taken. Thus thread creation can be quite expensive, both in terms of memory usage and time spent in creation. The ideal way to reduce these costs is to have a relatively short number of long-lived threads, all created fairly early on - before the base thread has accumulated too much data. Of course, this may not always be possible, so compromises have to be made. However, after a thread has been created, its performance and extra memory usage should be little different than ordinary code.

我沒用過這個module...不過你的問題應該跟他說的一樣才對..