The performance differences can be rather different based on configuration.
Internally, its the same jetty server, same jetty classes, we use nothing
special for embedded vs standalone.
The jetty distribution (what we call your 'standalone') has plenty of
configuration when it comes to connectors / thread pools / acceptors (to
name a few things) that can affect performance.
Looking at your snippet of the embedded version, one thing I noticed is
that you are not unpacking the war file.
So you will have some (slight?) performance hits with serving content from
a compressed war file.
The distribution's configuration is setup to unpack the war file before
deploying it into jetty server.
Also, note, that just dropping the war into the webapps directory is the
simple approach to deployment and give you little ability to control things.
Would recommend a context based deployment instead, that way you can also
control the context, security, and where things are unpacked.
For now, if you are just testing things out, create a ${jetty.home}/work
directory for jetty to use for the unpacked wars. (by default it uses
java.io.tmpdir which can cause problems on unix systems that periodically
clear out the /tmp dir)You could probably adapt this example context xml to suit your hudson needs ... https://gist.github.com/1935108 - Joakim On Tue, Feb 28, 2012 at 1:46 PM, Winston Prakash <[email protected]>wrote: > Let me clarify, what I meant by "bundled" (I think the correct word is > embedded) and "standalone". You can use the hudson.war two ways > > Just run the war as a regular executable jar using java -jar hudson.war. > In this case it uses the jetty jars bundled with in the war and starts an > embedded jetty which in turn uses the hudson.war itself > > Server server = new Server(); > URL warUrl = protectionDomain.**getCodeSource().getLocation(); > WebAppContext context = new WebAppContext(); > context.setWar(warUrl.**toExternalForm()); > .. > server.start(); > > Other way (which Matt is doing now), drop the war file in a "webapps" > folder of a normal Jetty distribution. > > Wondering if there is any performance difference between the above two. > > - Winston > > > On 2/28/12 12:16 PM, Jesse McConnell wrote: > >> not sure what is meant by 'bundled' vs 'standalone' really >> >> maybe osgi vs normal distribution? or embedded vs normal distribution? >> >> in those cases there shouldn't be any real default difference, osgi >> has its natural bit of classloader muckity muck muck but in terms of >> processing of a request from start to finish...not that I know of. >> >> more info on what is meant by 'bundled' vs 'standalone' would help >> clarify that though >> >> cheers, >> jesse >> >> -- >> jesse mcconnell >> [email protected] >> >> >> >> On Tue, Feb 28, 2012 at 14:08, Winston Prakash >> <[email protected]> wrote: >> >>> >>> On 2/28/12 11:42 AM, Webmaster(Matt Ward) wrote: >>> >>>> Hi Folks, >>>> >>>> I know it's short notice but as it's quiet for Hudson this week I'm >>>> going >>>> to move us off the Winstone servlet and onto Jetty. I've got everything >>>> ready to go so at 4pm I'll shut Hudson down and then startup the Jetty >>>> instance. I expect we'll be offline for about 10 minutes. >>>> >>> >>> Nice. Good news is, for Hudson 3.0.0 we don't have to do this, because we >>> replaced Winstone with Jetty as a bundled server. >>> >>> I'm interested to know, from Jetty folks, if there is a difference >>> between >>> Jetty bundled server and Standlone server in terms of performance. >>> >>> - Winston >>> >>> -Matt. >>>> >>>> >>>> ______________________________**_________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@**eclipse.org<[email protected]> >>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>> >> ______________________________**_________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@**eclipse.org<[email protected]> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> > ______________________________**_________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@**eclipse.org<[email protected]> > https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
