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:*jenkinsci-dev@googlegroups.com
[mailto:jenkinsci-dev@googlegroups.com] *On Behalf Of *Tom Fennelly
*Sent:* den 29 maj 2014 10:27
*To:* jenkinsci-dev@googlegroups.com
*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
<tom.fenne...@gmail.com <mailto:tom.fenne...@gmail.com>> 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 jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
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
jenkinsci-dev+unsubscr...@googlegroups.com
<mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
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 jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
