BLOGS

BENCHMARKS

warning: file_get_contents(http://www.telize.com/geoip/54.158.212.93) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /var/www/www.4d.com/docs/includes/common.inc(1762) : eval()'d code on line 4.

Sequential sorting under 64-bit

The 64-bit environment and its benefits for sequential sorting

To demonstrate scalability's effect on performance, we compared the time it takes to perform a sequential sort using the 32- and then the 64-bit versions of 4D Server v12. A sort needs memory to store the temporary data used in comparisons. 4D Server does not use the cache for this kind of operation; it allocates the memory in the “engine memory” (any part of the virtual memory 4D Server can allocate outside the cache). We set the size of the cache to the same value in both environments.

Queries under 4D Server v12 64-bit

Increasing cache size to speed up queries

Usually, scalability is not about speed. Being able to allocate more memory does not mean that an application will run faster, but that it will support a heavier load. However, there are situations where an operation will run faster just because 4D Server could use more RAM. A typical example is the cache size. The 32-bit version can allocate a maximum 2.3 GB of cache. (The remainder is used for the engine: handling connections, processes, users, code, etc.) There are no limits with the 64-bit version, which means it is now possible to fill the cache with all the data (and indexes).

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.

 

4D Server v11 SQL Scalability test

How many simultaneous, active clients can 4D Server handle? This laboratory scalability test examines the limits of a real application on 4D Server v11 SQL.

 

Since the recent announcements about scalability in 4D v11 SQL Release 3, especially in regards to those helped by improved management of multi-processor operations, many people have had questions about the number of simultaneous clients that can connect to 4D Server.

 

4D v11 SQL in a Real Application

4D v11 SQL performance tests under real-world conditions.

 

Is the whole greater than the sum of its parts?

 

This is the question we had in mind when creating some of the new algorithms in 4D v11 SQL. Although every command has received individual attention, and while we know how to assess their improvements through unit tests, it’s the perception of the user that determines the total improvement in performance.

 

Query by Formula - Standalone

Speed improvements in Query By Formula under 4D v11 SQL.

In 4D 2004, a formula is calculated for each record sequentially.

4D v11 SQL analises formulas beforehand to optimise queries. The syntactic analyzer can identify parts of the formula that can be optimised to reduce the sequential parts of the query.

Our test case involves the georeferencing (location by degree of latitude and degree of longitude) of customers. We’d like to find the customers who are within 10km of a particular point. Say we have a function, "Distance," that returns the number of kilometres (as the crow flies) between two points.

Query by Formula - Client/Server

The speed of Query By Formula execution on the server side under 4D v11 SQL.

In 4D 2004, a Query by Formula is executed on the client end. This means that every record must pass over the network to have a formula applied, and to determine if it will be part of the selection.

When the logic of the request allows it, 4D v11 SQL will perform queries directly on the server to avoid extraneous loads on the network. Only the selection is returned to the client end, as with a classic query.

Let’s go back to the formula for measuring distance used in the test QUERY BY FORMULA (standalone).