Производительность MySQL connector для .NET, обсудим?

Question

[Anton_habr_2020]

Недавно при переводе проекта с .net core 3.1 на 5.0 решил перейти с Pomelo.EntityFrameworkCore.MySql на официальный MySQL коннектор(MySql.Data.MySqlClient) и наткнулся на резкое падение производительности приложения.

Заинтересовался и провел тесты. Разница в скорости вычитки данных составила 10-30 раз в зависимости от условий теста.
Тесты проводил на локальной базе и на простом запросе, чтобы минимизировать задержки со стороны MySQL сервера. Тестировал на Windows и Ubuntu, на .net core 3.1 и .net core 5 - результаты сравнимы.

Вот код теста, он одинаков для обоих библиотек.

List<uint> ids = new List<uint>();
            using (MySqlConnection connection = new MySqlConnection(str))
            {
                connection.Open();
                DateTime now = DateTime.Now;
                using (MySqlCommand cmd = new MySqlCommand("SELECT * FROM Transactions;", connection))
                using (MySqlDataReader reader = cmd.ExecuteReader())
                    while (reader.Read())
                        ids.Add(reader.GetUInt32("ID"));
                Console.WriteLine("Loaded " + ids.Count + " items. App working time = " + (DateTime.Now - now).TotalSeconds + " sec");
            }

Есть идеи как объяснить эту ситуацию?

Comments

[Даша Циклаури]

а почему datetime , а не stopwatch?

[Владимир Коротенко]

Даша Циклаури, видимо потому что не такие мелкие промежутки.

[Петр]

Если приложению вдруг понадобилось тянуть большие выборки, значит приложение скорее всего плохо спроектированно.
Для отображения пользователям всегда достаточно страницы данных, а это 5-100 строк.
А на таких обьемах данных производительность, что Pomelo, что MySQL коннектор будет отличаться мало.

[Anton_habr_2020]

Петр, не буду спорить, но мое приложение именно таково, что по запросу пользователя тащит десятки тысяч строк и эта ситуация оказалась критична

[Anton_habr_2020]

Даша Циклаури, Это имело бы смысл при небольшой разнице. при десятикратной разнице не важна точность.

[ayazer]

не надо использовать официальный майскл коннектор от оракла. Он медленее и СИЛЬНО баганутей. используйте https://github.com/mysql-net/MySqlConnector

[Даша Циклаури]

Владимир Коротенко, есть просто де факто стандарт как в си шарпе, в веб делать замеры... я понимаю что на секундах это не имеет значения, но тогда можно и проверки на нул не делать и таймауты к запросам убрать

Answer 1

[Владимир Коротенко]

Сравните connection в обоих тестах что они там по умолчанию создают плюс проверяйте только в релизе. Ну и да официальный более тормознутый и меньше фич в области интеграции с EF

Answer 2

[Василий Банников]

Вопрос относится в первую очередь к разработчикам на .net!

Тогда теги надо ставить соответствующие.

Недавно при переводе проекта с .net core 3.1 на 5.0 решил перейти с Pomelo.EntityFrameworkCore.MySql на официальный MySQL коннектор(MySql.Data.MySqlClient) и наткнулся на резкое падение производительности приложения.

Так и есть. Оракловый драйвер ужасен.

PS: бенчмарки лучше проводить при помощи BenchmarkDotnet (а не Stopwatch или DateTime) - он умнее и перед замерами прогревает код, чтобы JIT успел его скомпилировать.

Comments

[Anton_habr_2020]

Смысл городить точные бенчмарки при 10-кратной разнице?

Так и есть. Оракловый драйвер ужасен.

Ну неужели настолько? насколько я вижу в nuget он лидер по использованию.

[Василий Банников]

Anton_habr_2020, это может помочь найти причину. Может оракловый драйвер тормознутый именно из-за большого количества данных? Или может он сам по себе медленный? Или может там так дико код написал, что JIT очень медленно его оптимизирует?
Или может он медленно работает только на синхронных запросах? Или наоборот - только на асинхронных?

Ну и городить бенчмарки не трудно) + на выходе получается прикольная сравнительная таблица и диаграммы.