Load-Test BL Bank Server

(1)

Load-Test BL Bank Server

Business-Logics IT Consulting GmbH

21st February 2006

1 Test envrionment

To get a right view on the messured data here, a detailed description of the testing envrionment follows.

1.1 Hardware

The load test has been carried out by using three computers: the load-generator, application server and database server.

The first computer created the load by using the Load-Generator from Business-Logics. This load generator can create a load on a ISDN connection by simu-lating multiple, parallel ISDN connections.

The second computer, the application server, holds the Bank Server from Business-Logics.

The database server was running on the thrid computer. The figure 1 shows the set-up of the test envrionment.

Figure 1: The used computes The computers have the follwing equipment:

Computer Load-Generator Application Server Database Server

Main Memory 512 MB 1 GB 512 MB

Operating System Linux 2.6.15 Linux 2.6.15 Linux 2.6.11 CPU AMD AthlonTM _Intel°R _Pentium°R _{M Intel}°R _Pentium°R _M

Clock Rate 1145 MHz 1600 MHz 1700 MHz

IP-Adress 192.168.1.52 192.168.1.56 192.168.1.55

(3)

1.2 Software

The software on the different computers has all been installed with default settings. No optimization has been done with respect to performance or other criteria.

Used software:

Load-Generator The Business-Logics Load-Generator together with a JavaTM₂

Runtime Environment, Standard Edition (build 1.5.0-bpcompiled-1138888628). Application Server A JBossTM_{Application Server, version 4.0.3. with}

maxi-mal main memory of 128 MB. The java runtime envrionment JavaTM₂

Runtime Environment, Standard Edition (build 1.5.0-bpcompiled-1138888628) was used.

Database Server We used a MySQLTM_{Server, version Ver 4.1.10a for}

suse-linux on i686 (SUSE MySQL RPM) with default configuration.

1.3 Database

The database of the Bank Server is initially filled with the following entries:

• 10.000 Customers

• 64.489 Users (every Customer has between 3 and 10 User) • 100.000 Accounts (10 Account for each Customer)

• 515.912 Ordertype-Permissions. For each User there are 4 send-permissions

(INI, VPK, PUB, IZV) and 4 fetch-permissions (VPB, PTK, VMK, STA).

• 644.890 Account-Permissions. For each user one permission for each

account of the customer.

• 10.000 random generated IZV files with 5 logical files, each holding 10

payments. Together 50 payments per file. Average size of a file is 15 KB, all files together have approximately 145 MB.

2 Test implementation

Before the test starts, the first three users of each customer have been initialized with a A004-Signature-Key.

(4)

2. User 1 transfers the payment file (IZV, O-File) followed by the transfer of the signature file (IZV, U-File) to the Bank Server.

3. User 1 fetches the protocol file (PTK).

4. User 1 fetches the remittance advice (VMK) from the server. 5. User 1 fetches the statements (STA) from the server.

This sequence is carried out for every customer. The file transfer of the load-generator has been limited to 10-times ISDN transfer rate (640.000 bit/s) for each transfer.

Two runs have been made, initially with 20 connections in parallel and after-wards with 50 connections in parallel. That is equal with the load of 200 and 500 parallel ISDN connections respectiveley (because each connection is using 10-times ISDN transfer rate).

The Bank Server performed the normal tasks for every file transfer (database access, PTK writing, permission checks, etc.) and in addition to that, it created advice (VMK) and statement (STA) information out of each transfered payment file. This enables the customer to fetch VMK and STA files from the Bank Server. In some cases the VMK and STA generation has not been completed, so that when fetching the VMK or STA file, no data was available on the server. In that case the return code 0024 - no data available - was returned.

3 Measurement

On both systems, the application server and the database server, the load is meassured. For this the command vmstat wrote the load every 10 second into a protocol file (see also appendix A).

For each filetransfer the duration of the login, the number of transfered bytes, the start time and the duration of the transfer is logged (see appendix A).

4 Analysis

During both tests there have been 50,000 filetransfers. Once with 50 and once with 20 transfers in parallel. The following table shows some variables of the test:

(5)

Variable First run (20 parallel) Second run (50 parallel) Total filetransfers 50.000 50.000 Return code 00011 _40.975 _42.268 Return code 00242 _9.016 _7.715 Return code 00263 ₅ ₁₂ Errors in Transfer4 ₄ ₅ Login-Time ∅ (s) 2,885 6,807 fastest Login (s) 0,017 0,018 slowest Login (s) 16,797 54,665 Transfer rate ∅ (bps) 816.907 639.275

duration of the test (h:mm:ss) 2:20:00 2:27:50

Totally transferd (MB) 286,2 291,1

4.1 Load

The load of the application server and the database server is shown in figure 2 and 3. In the charts it is cognizable, that during the test the load of the database server increases, meanwhile the load of the application server decreases. This shows, that in this envrionment the database server does not offer enough performance to serve the needs of the application server. The database server is the bottleneck. With increasing entries in the database, the load increases. However, even here the load is not too high, so that a well-configured database server is able to serve the requirements of the application server.

4.2 Transfer times

The graphical chart of the transfer times is shown in figure 4 and 5.

These figures show very nicely that the response time between 20 and 50 parallel connetions does not differ too much. In both cases the desired tranfer rate was reached. A fast response to each request is given in both cases. This shows, that even 500 parallel ISDN connections are suiteable with the choosen hardware envrionment.

A critical factor is the fact, that the application server uses a local filesystem to store the data. If the file system would have been placed on a NFS (Network

1_{Response code 0001 means, that the transfer was completed successfully.}

2_{Return code 0024 shows, that data was requested, but the server could not find any}

(new) data. This happens if directly after the IZV transfer the VMK file is fetched and that file has not yet been generated by the server.

(6)

0 10 20 30 40 50 60 70 80 90 100 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Load / % Time / s 50 parallel 20 parallel

Figure 2: CPU-Usage of database server

File System), the transfer rates could have been slower, depending of the speed of the NFS connection.

4.3 Login times

The login to the system creates the biggest load for the database server. During the login, the system must find the customer and the user in the database and also needs to check the permissions for the user.

Figure 6 and 7 shows, that the most part of the requests have been answered in less than a second. But there are more delays, the more load is generated. In case of 20 parallel connections every login was performed in less than 10 seconds (see figure 7), we have up to 20–30 seconds when there are 50 parallel connections (figure 6).

5 Conclusion

The used standard-hardware in the test envrionment could show the advantages of a modern Bank Server architecture. Even with the used Low-Cost-Database without any optimization, a good overall performance was received.

The constant load of the application server shows, that even when the load is increased by 2.5 times, the Bank Server scales brilliant. All requests have been

(7)

10 20 30 40 50 60 70 80 90 100 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 Load / % Time / s 50 parallel 20 parallel

Figure 3: CPU-Usge of application server

answered without problems from the application server.

With a more powerful hard- and software of the database server, even more optimisation with respect to the response time can be achieved.

A

Result Files

All data has been generated out of log-files written during the test. A list with used log-files with a short description follows:

appserver.orig.vmstat The complete output of the programm vmstat run-ning on the application server.

appserver.vmstat The output of the programm vmstat running on the ap-plication server, filtered for the testing period.

boot.log Logfile of the application server during boot-up.

datenbank.orig.vmstat The complete output of the programm vmstat run-ning on the database server.

(8)

10 100 1000 10000 100000 1e+06 1e+07 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 Transfer Rate / bps Transfers

Figure 4: Transfer rate with 50 parallel connections

java0.log.* The logfiles of the load-generator in java.util.logging-XML format. lasttest.report The complete output of the load-generator.

lasttest The output of the load-generator, prepared to create the images in this report..

(9)

100 1000 10000 100000 1e+06 1e+07 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 Transfer Rate / bps Transfers

Figure 5: Transfer rate with 20 parallel connections

0 5000 10000 15000 20000 25000 -10 0 10 20 30 40 50 60 Number of Logins

(10)

0 5000 10000 15000 20000 25000 -2 0 2 4 6 8 10 12 14 16 18 Number of Logins Login-Time / s

Load-Test BL Bank Server