Hi Greg, Realistically I couldn't do the unix socket thing, I think it wouldn't be considered secure enough since clear text sensitive data would be easily available via that socket. Although even if that is not true, I think our clients would just not be ok with anything other than encryption all the way to jetty.
I think it is worth doing something that lets jetty use a fast SSL lib. Jetty is frequently going to be used with SSL, and Java's built in SSL lib really kills Jetty's otherwise fantastic performance. -Luke On Mon, Mar 22, 2021 at 12:05 PM Greg Wilkins <gr...@webtide.com> wrote: > Also I note that it appears that netty is wrapping OpenSSL as a SslEngine, > so we could look at either doing the same or even reusing their wrapper > (although it appears to pull in a lot of netty util and handlers). > > > On Fri, 19 Mar 2021 at 12:42, Greg Wilkins <gr...@webtide.com> wrote: > >> So unix sockets an option? >> >> On Fri, 19 Mar 2021, 09:21 Luke B, <lukenbutt...@gmail.com> wrote: >> >>> Hi, >>> >>> From memory the difference in performance is rather large, maybe 10x or >>> 20x. It really does make a difference to how many requests we can handle. >>> Conscrypt takes jetty from being severely limited by the speed at which it >>> can transfer encrypted data, to encryption adding no meaningful overhead to >>> data transfer. >>> >>> -Luke >>> >>> >>> On Tue, Mar 16, 2021 at 1:21 AM Simone Bordet <sbor...@webtide.com> >>> wrote: >>> >>>> Hi, >>>> >>>> On Mon, Mar 15, 2021 at 12:50 AM Luke B <lukenbutt...@gmail.com> wrote: >>>> > >>>> > Hi, >>>> > >>>> > So it seems conscrypt has even more memory leaks: >>>> > https://github.com/google/conscrypt/issues/835 >>>> > https://github.com/google/conscrypt/issues/984 >>>> > >>>> > Conscrypt doesn't appear to be sufficiently reliable to be used in >>>> production. >>>> > >>>> > Setting up jetty to listen only on localhost without SSL and having >>>> an nginx (or other web server) reverse proxy to provide SSL is possible but >>>> unlikely something that is acceptable as encryption is required all the way >>>> to the java process. In this case a tcp dump would reveal passwords. >>>> > >>>> > Jetty, it seems, is trapped behind Java's relatively slow SSL >>>> implementation. >>>> >>>> I guess the keyword here is "relatively". >>>> >>>> Java's SSL is slower no doubt, but perhaps it does the job? >>>> Is the move to Conscrypt due to benchmarks (A is faster than B), but B >>>> can handle the load just nicely? >>>> Is the move to Conscrypt due to saving CPU/memory in the cloud to save >>>> money? >>>> >>>> I'm saying that with the latest Java versions, with native support for >>>> encryption primitives, TLS resumption, etc. maybe Java TLS does the >>>> job for you. >>>> Sure it's not the Ferrari you wanted, but it's a decently fast car >>>> anyway? >>>> >>>> -- >>>> Simone Bordet >>>> ---- >>>> http://cometd.org >>>> http://webtide.com >>>> Developer advice, training, services and support >>>> from the Jetty & CometD experts. >>>> _______________________________________________ >>>> jetty-users mailing list >>>> jetty-users@eclipse.org >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>>> >>> _______________________________________________ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> > > -- > Greg Wilkins <gr...@webtide.com> CTO http://webtide.com > _______________________________________________ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
