Accelerating Java technology with LRWP

Brief introduction

Multithreaded applications can meet today's growing business needs while also reducing the number of systems required. However, the scalability of multithreaded applications is limited by code that cannot be executed concurrently; These serial components restrict scalability, see Adam Law and I/O issues. Our previous article horizontal scaling on a Vertical System using Solaris Zones describes how to use the partition (Zone) extension Xitami/nexsrs, which runs a copy in each partition. Running a copy in each partition can improve performance by one step, but this is still not a solution for Xitami scalability issues. Some solutions either migrate the Long Running Web Process (LRWP) protocol to Sun Web Server or let Nexsrs use the Netscape Server API (NSAPI). We decided to adopt a completely different approach: Implement the LRWP protocol in Java and run it in the Web container. GlassFish is an open source project available today, so we choose to use GlassFish to achieve our ideas. We expect the performance of this approach to be close to Xitami/nexsrs performance on a small system, and it can be extended well into larger systems.

Implementation is faster than Xitami/nexsrs--xitami is a very small Web server written in C, and is ranked among the top ten Web servers. Our implementations can be better scaled to larger CMT systems, but using Java to implement LRWP has a 23% performance advantage in a single core system and a 78% performance advantage in 4 nuclear systems, showing its scalability from a single core system to a multi-core system, and the Xitami implementation extends to Only about 15K CPM can be reached on the 4 nuclear system. As shown in Figure 1.

Comparison of scalability of graphs 1:xitami/c and Glassfish/java

Long Running Web Process (LRWP)

The Xitami WEB server communicates with its counterpart (peer) using the LRWP protocol. A peer is a process that communicates with a WEB client. A WEB client can be a browser or other type of client that uses HTTP traffic. LRWP is similar to a Cgi:web client request call to Cgi-bin/context, Cgi-bin/context allows the Web container to invoke the Cgi-bin executable and pass input from the Web client to the executable program, and then returns the output to the W EB client. In Lrwp, a TCP connection is established between the LRWP peer and the LRWP agent. The LRWP proxy can be a Web container or a process running in a Web container, and the LRWP peer can be any process running on the network. When connected, the LRWP peer registers an interesting Web context. The WEB context can be any context, such as/OSP,/tep, or/cgi-bin itself. When a request is initiated against that context, the agent passes the input to the LRWP peer and sends the output returned by the peer to the Web client. The LRWP agent can also support multiple peers at the same time. A peer can be a number of different threads in a process, or multiple processes. Each peer will establish the context of the connection and registration sense.

Using Java to implement LRWP

To implement this protocol using Java, we need a WEB container to handle HTTP. Since ISVs prefer open source Web containers, we choose to use GlassFish. GlassFish is a Java Platform Enterprise Edition (Java EE) application server built on top of the Apache Tomcat Web container. It uses Servlets to listen for HTTP requests and to pass requests to LRWP agents running in the container. The LRWP agent then passes the request to the correct LRWP peer and returns the answer to the servlet. The LRWP Proxy Server registers the context in which the peer is interested and waits for requests for those contexts. If a request matches a context, the servlet thread enters the context-locked hibernation state, and the agent passes the request to the LRWP peer, waits for the peer to reply, and then wakes the servlet thread and passes the answer to it. Finally, the servlet thread returns the answer to the WEB client.

Using Java to implement LRWP

We have implemented the LRWP proxy, which listens to the "/*" context through a WEB application, so that all requests are passed into the application. If the requested object is a context registered by the LRWP peer, the request is passed to the LRWP peer for next processing, and if the requested object is a context that is not registered by the LRWP proxy, the request is sent to the default servlet using ServletContext Dispatcher object for next processing. Service Provider (LRWP counterpart applications) wishing to provide LRWP services must register themselves through the LRWP proxy using the LRWP protocol. After the initial information exchange (according to the LRWP protocol), a connection is established between the LRWP agent and the peer through the LRWP RequestHandler. Each peer application will create a LRWP RequestHandler instance. The peer application registers a related URL context, and requests for that context are forwarded to the peer application. The LRWP peer can establish multiple connections with the LRWP agent to achieve load balancing by registering the same context. The LRWP peer application can also register multiple URL contexts.