Re: Designing a server for Java applet

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 24 May 2008 22:07:17 -0400

Message-ID:

<4838c9d4$0$90266$14726298@news.sunsite.dk>

petersprc wrote:

My point was, realistically, the performance cost of polling is
negligible in the poster's scenario. Say you had 100 concurrent
instances polling at 2 second intervals. That's 50 lookups per second
with some waking involved. The total overhead might not even reach
0.0001% of a single CPU on commodity hardware. So, there shouldn't be
any concern about doing this on a shared host, which is why I said his
solution is fine. There's no need to rewrite his code and potentially
introduce race conditions or deadlocks. A robust, buffering, message
queue that supports multiple listeners who can possibly drop and
reconnect requires slightly more implementation...

????

50 request/second = 0.0001% CPU means that one CPU can handle
50 million requests per second.

I am pretty sure that Google would love to get a few of those
"single CPU on commodity hardware".

The main bottleneck is the number of simultaneous connections, which
you would run out of way before polling becomes an issue.

I very much doubt that.

A plain
socket app would be a bigger win as the overhead of each connection is
much lower than a full HTTP session and you can use select directly on
the sockets, thus avoiding any polling entirely.

Sockets avoid polling because the server can push. Select has nothing to
do with that.

Arne