I am mainly commenting on how it behaves today. I'm not familiar enough with SSE to be able to predict how It would behave server side if it was implemented, last time I used SSE it was brand new and we used a specialized app server designed to handle thousands of users, so I don't know how tomcat/jetty has implemented it. It was the "long running connection to the server" expression that prompted me to express my concern. Just don't hog my precious HTTP workers! ;)
/B 2014-06-02 19:04 GMT+02:00 Tom Fennelly <[email protected]>: > Are we talking abut the same thing though? If I read your email > correctly I think you're talking about the current mechanism of periodic > polling requests (coming form 100s of users), right? What the guys were > talking about was something different i.e. SSE, where the 100s of clients > open long running connection to the server, over which notifications are > pushed. As I see it, this is different in that it's ot constantly creating > and destroying connections from the client to the server + it's not > constantly processing ajax requests, most of which are probably returning > the same data as last time. > > > On 02/06/2014 17:03, Sandell, Robert wrote: > > 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] <[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]> > 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]. > For more options, visit https://groups.google.com/d/optout. > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [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. > -- 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.
