You are right that Jetty has longer history, but the SPDY support is
coming soon in Undertow and can be easily added to this container.
On 06/05/2014 01:14 PM, 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.
--
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.
