Zero-copy proxying is a unique feature of the AdroitLogic UltraESB which allows extremely efficient proxying of service calls through the UltraESB with least overhead. Coupled with the support for Non-Blocking IO operations, a single UltraESB node can manage hundreds or thousands of concurrent clients using a few threads, and limited resources.

Zero Copy proxying with Non-Blocking IO

Note: Zero-Copy Proxying with NIO is a unique feature of the UltraESB which allows it extreme levels of capabilities when running under extreme load while offering best performance. This feature should only be used in use cases where extreme performance levels are required - which is rare. The default UltraESB is well tested and tuned to run very efficiently and much better than most other ESBs - if not all - even on standard hardware, virtualized systems, and Amazon EC2 etc.

The UltraESB allows extremely efficient proxying of messages with least possible overhead - including Zero-Copy proxying with Direct Memory Access [DMA] on supported Hardware. This feature is best used on a Linux operating system with a current Kernel version such as version 2.6 using the 'sendfile' system call of the Operating system, which allows the transfer of a message received over the network buffer to be efficiently transferred out again without making a copy of the data in the heap memory. In addition to preventing the use of user space heap memory, the use of the 'sendfile' system call reduces the number of context switches as well, as the message is passed through Kernel memory alone. The UltraESB uses a cache of memory mapped files that reside in kernel memory as opposed to the traditional buffers or programming language objects that reside in user space memory. Thus the transfer of a message through the UltraESB takes place with a minimum number of context switching and better utilization of the CPU.

Utilizing the Network card offloading capabilities

For real 'Zero-Copy' forwarding, the network card used must support gather operations, and the UltraESB should be deployed over the bare metal hardware without using a layer of virtualization. This allows the network card to efficiently create the TCP packets by combining from different memory areas, without having to create the complete message into a buffer at first. It is highly recommended that network card offloading capabilities are used only with good hardware and drivers after comprehensive testing, as there could be certain issues with the Operating System and versions, Drivers and the Hardware which may cause problems.

Checking if the network card supports offloading

Checking the output of the command "ethtool -k eth0" on a Linux system will show the offloading capabilities and configuration of the network device chosen. In the above example, it will print the settings for 'eth0'.  Please refer to [http://www.aldeby.org/blog/ethernet-network-offloading.html] and standard Linux documentation on how to enable the offloading capabilities of your adapter - at a minimum scatter-gather support should be enabled. TCP offloading will only benefit a wired network adapter, correctly configured for its maximum performance (i.e. ensure that gigabit support where available is enabled and functioning correctly)

The following excellent articles explain the advantages of Zerop-Copy proxying extremely well.

1. Zero Copy I : User-Mode Perspective - Dragan Stancevic [http://www.linuxjournal.com/article/6345]
2. Efficient data transfer through zero copy : Zero copy, zero overhead - Sathish K. Palaniappan [http://www.ibm.com/developerworks/library/j-zerocopy/]

Using Non-Blocking IO [NIO] for HTTP/S

The traditional Java Servlet model processes each request on a separate thread. Since an ESB typically forwards a request it receives to another service, keeping a thread blocked for the response to arrive would be an extreme waste of resources. In addition, as soon as the total threads being used increases to over hundred on a typical system, the thread context switching overhead will cause a degradation of performance, in addition to limiting the number of open connections (i.e. sockets) to the number of possible threads.

The UltraESB uses the Non-Blocking IO [NIO] Support of the Java VM, and supports SSL connections over NIO as well using the Apache HttpComponents/HttpCore NIO library. This allows the UltraESB to keep thousands of open sockets, and service requests with a few threads - most typically less than a hundred. As a 1:1 socket to thread pairing is not maintained, the thread of execution is immidiately released back into the thread pool, whenever processing requires a wait on an external service. Once the response is received, a new thread is connected back to process the response.