Webtide

Tag: fastcgi

  • UnixDomain Support in Jetty

    UnixDomain sockets support was added in Jetty 9.4.0, back in 2015, based on the JNR UnixSocket library.

    The support for UnixDomain sockets with JNR was experimental, and has remained so until now.

    In Jetty 10.0.7/11.0.7 we re-implemented support for UnixDomain sockets based on JEP 380, which shipped with Java 16.

    We have kept the source compatibility at Java 11 and used a little bit of Java reflection to access the new APIs introduced by JEP 380, so that Jetty 10/11 can still be built with Java 11.
    However, if you run Jetty 10.0.7/11.0.7 or later with Java 16 or later, then you will be able to use UnixDomain sockets based on JEP 380.

    The UnixDomain implementation from Java 16 is very stable, so we have switched our own website to use it.
    The page that you are reading right now has been requested by your browser and processed on the server by Jetty using Jetty’s HttpClient to send the request via UnixDomain sockets to our local WordPress.

    We have therefore deprecated the old Jetty modules based on JNR in favor of the new Jetty modules based on JEP 380.

    Note that since UnixDomain sockets are an alternative to TCP network sockets, any TCP-based protocol can be carried via UnixDomain sockets: HTTP/1.1, HTTP/2 and FastCGI.

    We have improved the documentation to detail how to use the new APIs introduced to support JEP 380, for the client and for the server.
    If you are configuring Jetty behind a load balancer (or Apache HTTPD or Nginx) you can now use UnixDomain sockets to communicate from the load balancer to Jetty, as explained in this section of the documentation.

    Enjoy!

  • HTTP/2 Support for HttpClient

    Jetty’s HttpClient is a fast, scalable, asynchronous implementation of a HTTP client.
    But it is even more.
    Jetty’s HttpClient provides a high level API with HTTP semantic. This means that your applications will be able to perform HTTP requests and receive HTTP responses with a rich API. For example, you can use HttpClient to perform REST requests from the client or from within your web application to third party REST services.
    Jetty’s HttpClient provides also pluggable transports. This means that the concept of a HTTP request and response is translated by HttpClient to SPDY, FastCGI, HTTP/1.1 or other protocols and transported over the network in SPDY, FastCGI and HTTP/1.1 formats, in a way that is totally transparent for the application, which will only see a high level HTTP request and a response.
    Applications will get improved performance when using more performant transports.
    The new addition in Jetty 9.3 is a HTTP/2 transport for HttpClient, replacing the SPDY transport.
    This means that now HttpClient can talk to a regular HTTP/1.1 server, or to a FastCGI server that serves PHP pages, or to a HTTP/2 server transparently.
    The HTTP/2 specification is in its final phases, so the HTTP/2 protocol is now stable and well supported: Firefox, Chrome, Internet Explorer 11 already supports HTTP/2, and as the time passes they will be enabling HTTP/2 by default (some already have).
    And it’s not only browsers and servers such as Google, Twitter, etc.: also tools and libraries such as curl and nghttp2, among many others.
    The Jetty project implemented HTTP/2 since June 2014 and this very website has been served using Jetty’s HTTP/2 implementation for now over 6 months, helping to finalize the interoperability among different implementations.
    You are probably already reading this blog entry served via HTTP/2, if you are using a recent browser.
    Contact us if you are interested in deploying HTTP/2 in your infrastructure and benefit from the performance improvements that it brings.

  • Jetty 9.1.4 Open Sources FastCGI Proxy

    I wrote in the past about the support that was added to Jetty 9.1 to proxy HTTP requests to a FastCGI server.
    A typical configuration to serve PHP applications such as WordPress or Drupal is to put Apache or Nginx in the front and have them proxy the HTTP requests to, typically, php-fpm (a FastCGI server included in the PHP distribution), which in turn runs the PHP scripts that generate HTML.
    Jetty’s support for FastCGI proxying has been kept private until now.
    With the release of Jetty 9.1.4 it is now part of the main Jetty distribution, released under the same license (Apache License or Eclipse Public License) as Jetty.
    Since we like to eat our own dog food, Jetty is currently serving the pages of this blog (which is WordPress) using Jetty 9.1.4 and the newly released FastCGI module.
    And it is doing so via SPDY, rather than HTTP, allowing you to serve Java EE Web Applications and PHP Web Applications from the same Jetty instance and leveraging the benefits that the SPDY protocol brings to the Web.
    For further information and details on how to use this new module, please check the Jetty FastCGI documentation.
    Enjoy !

  • WordPress & Jetty: perfect fit

    I posted a while back about the capability of Jetty 9.1’s HttpClient to speak HTTP over different transports: by default HTTP, but we also provide a SPDY implementation, where the HTTP requests and responses are carried using the SPDY transport rather than the HTTP transport.
    Another transport that is able to carry HTTP requests and responses is FastCGI.
    The neat feature about FastCGI is that it is the default way to deploy PHP applications: fire up a proxy server (usually Apache or Nginx) in the front and proxy requests/responses to the FastCGI server (usually the PHP FastCGI Process Manager, or php-fpm).
    In this way you can deploy the most used PHP frameworks like WordPress, Drupal and others.
    And you are not limited to PHP: FastCGI allows you to easily deploy other dynamic web languages and frameworks such as Django (Python-based), Rails (Ruby-based) and others.
    We are happy to announce that Jetty 9.1 can now proxy to FastCGI, enabling deployment of PHP frameworks.
    Why this is good, and how different it is from having – say – Apache or Nginx in the front instead of Jetty ?
    The first and foremost reason is that Jetty is the only server that supports SPDY Push.
    SPDY Push is the biggest performance improvement you can make to your website, without a single change to the application being served, be it a Java web application or WordPress.
    Watch our video that shows how the SPDY Push feature that Jetty provides makes a big performance difference.
    The second reason is that SPDY version 2 is being deprecated really fast in favor of SPDY version 3 or greater.
    Browsers will not speak SPDY/2 anymore, basically reverting your website to HTTPS behaviour, losing all the SPDY benefits if your server does not support SPDY 3 or greater.
    As of the time of this writing, only servers like Apache or Jetty implement SPDY version 3 or later of the SPDY protocol, while Nginx only implements SPDY version 2.
    At the Jetty Project we like to eat our own dogfood, so the blog site you are reading is WordPress served via Jetty.
    If you’re using Firefox or Chrome, just open the browser network console, and you will see something like this:
    jetty-wordpress
    As you can see from the response headers, the response is served by Jetty (Server: Jetty(9.1.0.v20131115)) from PHP (X-Powered-By: PHP/5.5.3-1ubuntu2).
    Of course, since both Jetty 9.1’s server and HttpClient are fully asynchronous, you have a very scalable solution for your PHP-enabled website: currently the JVM that runs this very website only uses 25 MiB of heap.
    And of course you get all the SPDY performance improvements over HTTP, along with Jetty’s unique SPDY Push features.
    This is good for cloud vendors too, since they can run Jetty and expose PHP applications with a minimal amount of resources, high scalability, and unique features like SPDY Push.
    FastCGI for Jetty is sponsored by Intalio. If you are interested in knowing more about how Jetty can speed up your website or how to setup your PHP web application in Jetty, contact us or send an email to Jesse McConnell.