RESOURCES

SCALABILITY IN 4D SERVER V12 64-BIT

Home » Scalability in 4D Server v12 64-bit

 

Scalability in 4D Server v12 64-bit

Scalability: 510 users and the 64-bit version of 4D Server v12

To demonstrate scalability at full load, we compared the two versions of 4D Server 12.1, 32- and 64-bit, connecting 510 clients. Each client executed queries/creations/deletions in two different processes. Statistics were collected during those operations.

 

Protocol

  • There are 268 tables in the structure:
    • The [People] table contains 1,000,000 records
    • Half of the other tables have 500,000 records each
    • The rest of the tables have about 50,000 records each
    • (there are some utility tables that are not part of the test)
  • The data file has a size of 15 GB
  • Cache settings are as follow:
    • 1.5 GB for the 32-bit version. It was not possible to allocate more memory to the cache, because we needed room to handle the 510 clients, with two global processes each (which means about 2000 threads on the server).
    • 10 GB for the 64-bit version
  • When a client starts up, two processes execute code until the end of the test:
    • One global process performs a query on the [People] table and another query on another table. We don’t query on one [People] only because we want to fill the cache as a production application would do.
    • A second global process creates or randomly deletes a record in the [People] table
    • 1/3 of the clients run the code every 5 seconds, 1/3 every 10 seconds and the last 1/3 every 15 seconds. Here is the code of the query method:

 

//BENCH_Query
// ... (declarations) ...
$L_tablePeopleNum:=Table(->[People])
Repeat
  Delay PROCESS($L_currentPNum;<>L_TICKS_FOR_SLEEP)
  // Query another table
  RandomlyQueryOnOtherTable

  // Test
  $T_toFind:=Char(zRandom (65;90))+"@"
  $L_msStart:=Milliseconds
  QUERY([People];[People]LastName=$T_toFind)
  $L_msEnd:=Milliseconds

  // Save stats
  SaveOneStat ("Query_People";$L_msEnd;$L_msStart;0;$L_tablePeopleNum;Records in   selection([People]);$T_toFind)

Until (BENCH_STOP )

// --EOF--

 

  • Data was collected from the start of the server until 510 clients were connected. Once the full load (510 clients, 2 global processes/clients performing queries, creations, deletions) was reached, data was collected for 10 minutes.
  • The test was performed once with 4D Server v12.1 32-bit, then with the 64-bit version.
  • We launched one client every 10 seconds
  • Machines and configurations used for this bench were leased at Amazon. We used the "High Memory Quadruple Extra Large Instance" configuration for the server and the clients (a TSE server every 50 clients): "68.4GB RAM, 8 virtual cores with 3.25 EC2 Compute Unit Each; High I/O performance."

 

Results

During the test time (from the first connected client until 510 clients running their queries for 10 minutes), the 64-bit version could handle many more requests:


Total request count

 

33% more requests were handled by the 64-bit version. This is because we could allocate a larger cache size to the 64-bit version: 10 GB instead of 1.5. 4D Server had to purge its cache less frequently, and when it did it, it could then refill it with more data.

 

Similarly, the request count for every ten clients is higher with the 64-bit version:

 


Request count for every 10 clients

 

With the 64-bit version, the total request is almost always larger, with four exceptions (on 51 values). It is sometimes much larger, often twice as large. For example, between 370 and 400 clients, the 64-bit version could handle 2-3 times more requests.

 

Those results show that by just moving from 32 to 64-bit, 4D Server was able to better handle the huge load generated by 510 concurrent users.
 


 

 

More resources