Performance comparison between Devart/CoreLab/Mysql drivers

[ElChe]

Hi.

We recently upgraded from using CoreLab.MySql 4.50.27.0 to DevArt 6.70.302.0 for .NET.

After this change was done, we noticed a big impact on our production servers, where response times on the webservers in most cases tripled(!).
In order to investigate why this happened, we did a performance test on a local database where we timed devart, corelab and mysql drivers doing to exact same thing.
We measured a query (SELECT * FROM FOO WHERE FOO_PK = 1) 1000 times for each of the driver and added each timing to a total millisec.
The measure per query included:
- Opening connection
- Sending query with ExecuteReader() but not doing anything about the result
- Closing connection

Here is a random result from the program:

Code: Select all

Query tested: SELECT * FROM FOO WHERE FOO_ID = 1
Total time taken with DevArt: 2587ms
Total time taken with CoreLab: 840ms
Total time taken with MySql: 1880ms 

Pooling was set to true during the tests. When pooling was set to false, it looks something like this:

Code: Select all

Total time taken with DevArt: 9404ms
Total time taken with CoreLab: 2968ms
Total time taken with MySql: 8802ms 

The server version of MySql is 5.1.

Are we missing something here? Is there some settings on MySqlConnection that we've forgotten? Why can it be such a huge change?
Even measuring *just* the connection.open() renders the same difference between the drivers, devart being three times as slow to perform an opening of a connection.

I've tried searching for answers to this, so far to no avail. I hope someone can help us with this.

Kind regards

[Shalex]

We have answered you by e-mail. We are investigating the issue.

[Shalex]

We have run the tests basing on your description and obtained the following results:

Code: Select all

Pooling = true
Total time taken with Devart 00:00:00.3459238
Total time taken with CoreLab 00:00:00.1828351
Total time taken with Connector\MySQL 00:00:00.4060032
Pooling = false
Total time taken with Devart 00:00:05.1393918
Total time taken with CoreLab 00:00:00.7820994
Total time taken with Connector\MySQL 00:00:03.1055604

So the biggest performance loss with Devart is the "Pooling=false" case. The reason is that each time we open a new physical connection in the parallel thread (implementation of the connection timeout). Setting "Connection Timeout=0;" with "Pooling = false;" using Devart will improve the result greatly:

Code: Select all

Pooling = false;Connection Timeout=0;
Total time taken with Devart 00:00:01.0170334

[ElChe]

We have run the tests basing on your description and obtained the following results:

Code: Select all

Pooling = true
Total time taken with Devart 00:00:00.3459238
Total time taken with CoreLab 00:00:00.1828351
Total time taken with Connector\MySQL 00:00:00.4060032
Pooling = false
Total time taken with Devart 00:00:05.1393918
Total time taken with CoreLab 00:00:00.7820994
Total time taken with Connector\MySQL 00:00:03.1055604

So the biggest performance loss with Devart is the "Pooling=false" case. The reason is that each time we open a new physical connection in the parallel thread (implementation of the connection timeout). Setting "Connection Timeout=0;" with "Pooling = false;" using Devart will improve the result greatly:

Code: Select all

Pooling = false;Connection Timeout=0;
Total time taken with Devart 00:00:01.0170334

Hi again
Still, the pooling=false option isn't really something we'd use in a production environment. The issue still stands that with pooling on, devart's performance has doubled and your answer doesn't help in that case.

Kind regards,
ElChe

[Shalex]

The issue still stands that with pooling on, devart's performance has doubled

This is so because there were some changes in the behaviour since the 4.50 version of dotConnect for MySQL (the current one is 7.0): the possibility for managing charset was implemented, different bug fixes basing on customers requests changed internal logic that caused performance losses.

[ElChe]

The issue still stands that with pooling on, devart's performance has doubled

This is so because there were some changes in the behaviour since the 4.50 version of dotConnect for MySQL (the current one is 7.0): the possibility for managing charset was implemented, different bug fixes basing on customers requests changed internal logic that caused performance losses.

Okay, so to sum up there won't be any performance increase in the near future?
Kind regards

[Shalex]

This is correct: there won't be any performance increase in the near future.