-3

How can a PSGI application be served with many concurrent connections? I have tried event-based and preforking webservers but the number of concurrent connections seems to be limited by the number of worker processes. I've heard that for instance Node.js scales to several thousand parallel connections, can you achieve similar in Perl?

Here is a sample application that keeps connection open infinitely. The point is not to have infinite connections but to keep connections open long enough to hit connection limits:

my $app = sub {
  my $env = shift;
  return sub {
    my $responder = shift;
    my $writer = $responder->(['200', ['Content-Type' => 'text/plain' ]]);
    my $counter=0;
    while (1);   
      $writer->write(++$counter."\n");
      sleep 1; # or non-blocking sleep such as Coro::AnyEvent::sleep
    }
    $writer->close;
  };
};
Jakob
  • 3,570
  • 3
  • 36
  • 49

2 Answers2

1

I don't think you're supposed to have infinite loops inside apps, I think you're supposed to only setup a recurring timer, and in that timer notify/message/write... See Plack::App::WebSocket - WebSocket server as a PSGI application and Re^4: real-time output from Mojolicious WebSockets?

optional
  • 2,061
  • 12
  • 16
  • Sorry, the `sleep` is misleading because it blocks the thread. The limit is the number of open TCP connections. – Jakob May 04 '15 at 10:38
  • Jakob, sleep didn't mislead me, while(1) is an infine loop where you increment counter and write ... you're supposed to setup a timer like in the mojo example I linked. For the most part apps don't control socket creation, but if you use websocket you can have however many your os/hardware support. – optional May 06 '15 at 00:32
0

While I have not yet tried it I came across this question whilst searching for a solution to a problem faced when using a socket server to report on progress etc of long-running jobs. Initially I was thinking of an approach along the lines of ParallelUserAgent except as a server and not a client. Returning to the problem a few days later after realising that Net::WebSocket::Server blocked new connection requests if a long-running block of code within the new connection handler callback. My next approach will be split out the long running functionality to a new spawned shell process and use a DB to track the progress which can then be accessed as required within the server without lengthy blocking.

Thought I'd throw up my approach in case it helps anyone walking a similar path.

Peter Scott
  • 1,318
  • 12
  • 19