Let me attempt to prove you wrong, We are running a slight fork of Jenkins where we have removed the queue widget and the ajax call from the buildhistory so it doesn’t list queued builds on job pages. When we did that the UI responsiveness got improved a lot, I don’t know exactly how many simultaneous human users we have I think they are in the hundreds, but many of them have several tabs open (luckily chrome seems to pause javascript on on none visible tabs). But we saw that all our http threads in tomcat were occupied with serving and filtering the queue and these just kept piling up, dialing up the number of http threads in tomcat only delayed the inevitable. This was due to a synchronization block in the queue and things has been done in core to mitigate this in newer versions, but we still remove it since one less http request per user per second still provides better responsiveness.
Also all users are not “human users”, we had to redesign some of our tool integrations that uses the Jenkins HTTP API when we started to use Jenkins with lazy loading of builds, because again, http requests that was waiting for all builds to load for a job occupied all the http threads during peak hours and none was left to serve the humans. So my personal experience is to not have long running http calls for big Jenkins installs, even if the user base is “in the hundreds”. Someone told me that fronting Jenkins/tomcat with ngix would solve these problems. I haven’t tried it yet, does anyone have any experience with it? Robert Sandell Software Tools Engineer - SW Environment and Product Configuration Sony Mobile Communications From: [email protected] [mailto:[email protected]] On Behalf Of Tom Fennelly Sent: den 29 maj 2014 10:27 To: [email protected] Subject: Re: Refreshing the Jenkins UI On 29/05/2014 09:01, Michael Neale wrote: On Thu, May 29, 2014 at 5:26 PM, Tom Fennelly <[email protected]<mailto:[email protected]>> wrote: AFAIK... any proxy/gateway between the websocket client and server needs to be pretty much websocket aware. SSE would seem like a perfect fit for Jenkins since the client is listening only (not sending back to the server - could implement that on top anyway if needed). As far as I know SSE is a fancy long poll/comet style protocol and so would require the same considerations re number of concurrent users. -- Happy to be proven wrong but I expect that even for the heaviest users of jenkins (masters) - the number of concurrent users couldn't be more than in the hundreds - mostly that will work without any web framework contortions (happy to be proven wrong). I'd say you're spot on. The biggest risk for websocket, as I see it, is the temptation to built in a real time chat client, and perhaps webrtc video conferencing (you broke the build - someone can instantly berate you via webrtc video feed). Terrible idea forget I said it ;) Sounds like a great idea to me ;) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
