Workload Driver for Vehicle Location Insertion in WideWorldImporters
This application simulates an insertion workload for vehicle location in the WideWorldImporters sample database.
The main purpose is to compare the performance of data insertion into traditional disk-based tables compared with memory-optimized tables. For a more comprehensive sample demonstrating the performance of In-Memory OLTP see the in-memory/ticket-reservations sample.
Contents
About this sample
Before you begin
Running the sample
Sample details
Disclaimers
Related links
About this sample
- Applies to: SQL Server 2016 (or higher), Azure SQL Database
- Key features: Core database features
- Workload: OLTP
- Programming Language: C#
- Authors: Greg Low, Jos de Bruijn
- Update history: 25 May 2016 - initial revision
Before you begin
To run this sample, you need the following prerequisites.
Software prerequisites:
- SQL Server 2016 (or higher) or Azure SQL Database.
- Visual Studio 2015.
- The WideWorldImporters database (Full version).
Running the sample
-
Open the solution file MultithreadedInMemoryTableInsert.sln in Visual Studio.
-
Build the solution.
-
Connect to the database and run the script VehicleLocation.sql to create the memory-optimized and disk-based tables used for the comparison.
-
Run the app and follow the instructions on-screen. Compare the time taken for On Disk and In Memory insertion.
Sample details
This application is used to compare the insertion of rows into the OnDisk and InMemory tables in Wide World Importers. The required objects must have already been created by following the earlier steps in the demonstration script.
When executed, this application displays the following:
Ensure that the connection string is set appropriately. It is save when the program is edited. If you ever need to set it back to the default value, open the program, clear the string, and exit the program. When you restart the program, the connection string will have been returned to the default value.
You can control the number of threads performing the insert operations. You can choose whether to insert into an on-disk table or an in-memory equivalent of the same table.
The application will periodically (about every second) display the latest execution times for each insert.
If there is no significant performance difference, this could be an indication of a log IO bottleneck, as each insert results in a transaction commit that involves a flush to disk. It is possible to work around using delayed durability in the database:
ALTER DATABASE WideWorldImporters SET DELAYED_DURABILITY=FORCED
Disclaimers
The code included in this sample is not intended to be used for production purposes.