tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomas Klockar <tom...@omicron.se>
Subject Re: Rephrased: Maximum number of simultaneous HTTP connections
Date Tue, 04 Apr 2006 09:12:14 GMT
It is always possible to build an applet. It should be able to do the 
networking the right way, and I just tested a small program that just 
forks n threads in java. the thread sleeps for 10s then print something. 
3000 of these threads took 655 MB on  freeBSD box, and only little cpu.

regards,

/Tomas

Rajeev Jha wrote:
> I think everybody on the list here agrees that http is not the right 
> sort of thing for a chat  application. And most  of the IM/chat  
> applications  do not  run on  http  anyway. opening the sockets 
> directly for such an application is better/easier any day.
> <rant>
> However,  people do demand  an  HTTP  end point to  existing 
> applications. The big attraction is avoiding any client software, you 
> just need a browser.
> so finally it is about the availability of an end point in most cases.
> </rant>
>
> Thanks
>
> Darryl L. Miles wrote:
>
>> Tp wrote:
>>
>>>
>>> Well, that's a good question. The outcome of this thread might be 
>>> just that. But it would have been nice to use existing software 
>>> infrastructure.
>>
>> Maybe look at the IRC protocol ?   Has existing infrastructure, 
>> heritage and eco-system.
>>
>> http://www.irchelp.org/irchelp/rfc/
>> http://www.irchelp.org/irchelp/ircd/
>>
>> The outline of the protocol is one persistent connection per client, 
>> there are a handful of server implementations to choose from which 
>> have been optimized to handle in the region of ~10000 socket 
>> connections per server generally using few threads (certainly not one 
>> thread per connection).  You can scale the system with hooking up 
>> servers (daisy chain).  The protocol has been around a bit longer 
>> than HTTP and serves a completely different purpose more fitting with 
>> your requirements.  The only bad point is no real high-availability 
>> plan from the clients perspective (you may loose a fragment of a 
>> conversation during server migration), but the server implementations 
>> have stood the test of time and are on the whole quite stable.
>>
>> Maybe you are trying to use a jumbo jet to fly to the moon with HTTP.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message