Comet, Ajax, web browsers limitations and web apps performance factors
summary
A proof‑of‑concept shows request/response polling hits ~180 ms latency and cannot meet a 200 ms update SLA for 5,000 users; switching to long‑polling drops perceived latency to 55 ms but still wastes HTTP overhead and hits browser same‑origin limits. Running thousands of streaming connections exhausts default Tomcat threads and JVM memory (socket buffers ~64 KB/client causing permgen OOM around 4,000 clients), so move to Tomcat NIO and use libraries like Atmosphere or CometD; consider iframe/XHR streaming, SSE or WebSockets tradeoffs (browser support, text encoding, proxies).
AI-written summary · about
chapters (18)
- 0:00Comet and web app challenges
- 5:20Gaming platform latency needs
- 8:17Request-response failed 200ms test
- 15:08Long-polling reduces signal latency
- 20:09Long-polling pros and cons
- 23:44Bypassing same-origin policy
- 27:17Streaming transports for Comet
- 33:04Iframe streaming risks
- 35:18XHR streaming benefits
- 37:29Server-Sent Events streaming
- 40:27WebSockets HTML5 alternatives
- 41:49Tomcat server bottlenecks
- 45:47JVM memory exhaustion
- 47:11Socket buffer OS costs
- 48:14Switching to NIO
- 49:21Comet libraries
- 50:48Library internals limits
- 52:17Closing remarks
related talks
37mUsing Comet to Build Interactive Interfaces
49mThe Real Time Web with XMPP
01h 01mWeb Performance Deep Dive
01h 24mFastest Servlets in the West?
01h 01mReactive web services
50mWeb Performance APIs You (probably) Didn't Know Existed
31mJS in Extreme Conditions: WebApps for the Refugee Aid Movement
45mPerformance Testing and Tuning of Web Applications