OK, I didn't realize some people feel strongly about this.
IIUC, Undertoe is the web container for JBoss commercial JavaEE server products, so I just assumed that RedHat has vested interest in keeping it strong. Because of that I mentally put it in the same battle-tested level as Jetty (compared to, say, GlassFish, which is sadly "just an RI" nowadays.) And we have lots of RedHat people in this community, but not many Eclipse people.
Originally, I started "java -jar jenkins.war" just as a convenience, but as I discovered in another thread [1], more than 80% of the installation base is running on this container today. So it's worth some effort to get a good one in place.
As we contemplate the UI improvements, we'd like to start taking advantages of newer versions of the servlet. One thing I liked about Undertoe is that it seems to provide servlet 3.1 without requiring Java7.
But above all, I just hate to see Jakub's work wasted. He clearly spent a lot of time and effort into doing this, and it is a good work. As an older guy, I feel like there's a certain moral obligation to make best of what a junior guy came up with (sorry if you aren't, Jakub.)
[1] https://docs.google.com/spreadsheets/d/14YzFgKBB6BvbRU_1OjChC3efECWPs77TEGTU09t3KGw/edit#gid=0
On 06/05/2014 04:14 AM, jieryn wrote:
It's interesting, but ultimately seems to me to be not correct. The goal of the java -jar jenkins.war is just ease of use. It isn't about tuning it to squeeze out a modest 12% improvement in a single scenario. And you still would face Stepen's very real JIT argument. Additionally, these gains are so modest I don't think any changes to the underlying base case of java -jar jenkins.war should be made. Here are more objections which should be addressed: * Jetty works very well already, it has been thoroughly tested for compatibility with the legacy Winston driver. * Jetty itself is very well tested and has lots of active developers and huge amount of community support and knowledge base. * Jetty is the underlying test server for Jenkins plugin development, having a match between default plugin testing and default production should not be understated. * Jetty supports SPDY (HTTP/2.0), enablement by default would dramatically speed up the only scenario you list which was noticeably in favor of Undertow. Undertow does not yet support SPDY. ** Turning on SPDY for sites like a typical Jenkins installation (tons of individual static resources, all from the same single domain, and all having very long cache times) has yielded 50-60% speed improvements even from engineers not paid by Google. * Undertow, or any other application server, can already be easily leveraged by simply deploying it to the application server. I consider each of these arguments to individually be sufficient to keep the status quo for java -jar jenkins.war, let alone what they represent in aggregate. On Wed, Jun 4, 2014 at 10:31 AM, Jakub Bartecek <[email protected]> wrote:Hi, I created new servlet container for Jenkins CI based on Undertow (new web server for WildFly). It replaces the old implementation based on Winstone and Jetty. I aimed to keep backward compatibility with options in the current container. All essential options are supported and no problems with Jenkins was found out. I named this project Undertow4Jenkins and it is on GitHub (all commits since February 2014): https://github.com/jbartece/undertow4jenkins The integration of this container into Jenkins is implemented in these forked repositories: extras-executable-war module: https://github.com/jbartece/extras-executable-war Jenkins CI: https://github.com/jbartece/jenkins Performance tests: During processing performance tests were compared current version and version with new container Jenkins CI. I tested application in 3 scenarios during 8 minutes long tests. Each scenario was run 10 times for both versions of Jenkins. If you are interested in it, I can describe tests with more details. Scenarios: 1, Loading main page using HTTP GET: New implementation was about 12% faster. 2, Loading freestyle job configuration using HTTP GET: New implementation was about 4% faster. 3, Creating freestyle job using HTTP POST: New implementation was about 0.1% slower. I made it as my master's thesis and provide it as an alternative to current version, but I do not force anyone to use it ;). I think that it has potential to be better than current container. Cheers, Jakub -- 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.
-- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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.
