Embarcadero has just released a performance patch for the RAD Studio 10.2.3 version of RAD Server, our REST-based web service hosting architecture.
Getting The RAD Server Optimization Patch
This patch is available at http://cc.embarcadero.com/item/30838 and it includes a new set of binary files, for the different types of servers (both development and deployment). The patch includes a number of optimizations: better configuration of the memory manager for heavy multi-threading, optimized processing, optimized license checking, and much more. The patch includes also an additional feature, a KeepAlive option for the Dev server you can adding a setting to the EMS.INI configuration files (as described in the readme).
Testing the Optimization Patch
I've personally tested the patch against the development version of RAD Server in the following scenario: I run the server without debugging, disabled logging, and used Apache Benchmark client (ab) from a different machine on the same network. I used different calls, but eventually settled on these:
ab -n 1000 -c 10 -k http://192.168.1.111:8080/xyz
ab -n 1000 -c 10 -k http://192.168.1.111:8080/data
The two endpoints were different. The first is a hello world type of call, returning the same string and the time in a JSON string, with a document length of 17 bytes:
// Code for [ResourceName('xyz')]
procedure TXyzResource.Get(const AContext: TEndpointContext;
const ARequest: TEndpointRequest; const AResponse: TEndpointResponse);
begin
AResponse.building.SetValue(TJSONString.Create('xyz ' + TimeToStr(Now)), True)
end
The second endpoint executes a FireDAC query returning a database table in a stream, based on the internal FireDAC JSON format, and with a document length of 13,909 bytes.
// Code for [ResourceName('data')]
procedure TDataResource1.Get(const AContext: TEndpointContext;
const ARequest: TEndpointRequest; const AResponse: TEndpointResponse);
var
AStream: TStream;
begin
EmployeeConnection.Connected := True;
FDQuery1.Open;
AStream := TMemoryStream.Create;
FDQuery1.SaveToStream(AStream, sfJSON);
AResponse.building.SetStream(AStream, 'application/json', True);
end
The components have a very simple configuration, with a connection to the sample InterBase database, and the query 'select * from employee'.
The Data from the Test
I've tested the same scenario, same machines, same code with 10.2.3 (before applying the patch) with the patch, and with some additional fine tuning in the configuration. The table below has the information from ab for the 2 endpoints:
data
xyz
10.2.3 plain
Requests per second: 49.70
Time per request: 20.121 ms
Requests per second: 111.93
Time per request: 8.934 ms
10.2.3 with performance patch
Requests per second: 402.67
Time per request: 2.483 ms
Requests per second: 3336.61
Time per request: 0.300 ms
10.2.3 with performance patch
with thread pooling and keep alive
Requests per second: 426.59
Time per request: 2.344 ms
Requests per second: 3954.74
Time per request: 0.253 ms
You can see that the difference is very significant: for the complex call, from 46 to 426 requests per second, is almost a 10x increase, for the simple code from just above 100 to almost 4,000 is just short of a 40x increase in throughput.
Summary
For Embarcadero and the RAD Studio team, the RAD Server technology is a key piece of the plans and the future. Focusing on its performance was important, and more is coming in terms of Delphi RTL optimizations in the future. We have also added better support for JavaScript clients (including Ext JS) in the 10.2.x updates, and also made available a free deployment license with the Enterprise license. RAD Server is a key technology and a great way to bring your client/server applications towards the future, with a service oriented and more distributed architecture, ready for mobile and cloud deployment. Stay tuned for more.
