Java Magazine, Jan/Feb 2016
NUMBER OF CLIENTS 64 128 256 512 1024 2048 RUN 1 RESPONSE 48328 49263 52100 48524 50431 61675 STDEV 139 331 2601 1055 1557 3735 RUN 2 RESPONSE 49980 49004 49445 50102 54678 57585 STDEV 098 315 387 1984 2685 3503 RUN 3 RESPONSE 46990 49557 48943 48557 54437 65975 STDEV 069 153 679 787 3646 2913 ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2016 46 web apps Performance In a usual chat application all clients are listening for new messages while only a few of the clients are writing chat messages Hence for this application it makes sense to concentrate on what happens if we start increasing the number of clients To test performance I started with 64 clients and steadily increased the number of clients to 2048 while measuring the time it takes them to get a new chat message Table 1 presents the results of this test and Figure 2 shows them graphically It is not essential for our analysis to know the specific time it takes to perform a get operation but it is important to see the trends as the number of clients increases The average response time does not change much with the number of clients until we hit around 1024 clients and stays right around 500 milliseconds the time it takes for our producer thread to produce a new message As the number of clients increases beyond 1024 we see some degradation in performance mainly because it takes time to process posting of the chat message to the clients Another interesting point this test demonstrates is that the average time it takes to consume a message is slightly below the rate at which messages are produced It indicates that Figure 2 Response time as the number of clients increases processing a message and resubscribing does take time and there is a slight chance for the client to miss a new message To enhance this setup to work in an environment where missing messages is not a viable option a client can pass a token to the server indicating the last message it has seen If the client has already received the latest message available the server puts the thread on asynchronous wait for a new message Otherwise the server responds with all messages produced since the last message the client received Conclusion In this article Ive explained what long polling is and demonstrated how simple it is to use With the universal support it enjoys long polling can be used anytime a long lived connection between client and server is needed article Henry Naftulin has been designing Java EE distributed systems for 15 years He is currently leading development of proprietary short side preorder services for one of the largest financial companies in the United States Table 1 Results of three runs sending messages to multiple clients time in ms
You must have JavaScript enabled to view digital editions.