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. -- 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.
