Медленное открытие соединения SQLite в приложении C# с использованием System.Data.SQLite

Изменить 3:

Я думаю, что моя проблема решена на данный момент... Я изменил и мое сервисное и тестовое приложение, чтобы работать как SYSTEM учетная запись вместо NetworkService учетная запись. Еще неизвестно, сохранятся ли выгоды от изменения учетной записи пользователя, или это будет только временно.

Оригинальный вопрос:

Я заметил, что моя маленькая 224kB база данных SQLite очень медленно открывается в моем приложении C#, занимая где-то от небольшого количества мс до 1,5 секунд или более. Ниже мой код со всеми дополнительными операторами отладки, которые я добавил сегодня днем. Я сузил это до вызова cnn.Open(); как показано в журналах здесь:

2014-03-27 15:05:39,864 DEBUG - Creating SQLiteConnection...
2014-03-27 15:05:39,927 DEBUG - SQLiteConnection Created!
2014-03-27 15:05:39,927 DEBUG - SQLiteConnection Opening...
2014-03-27 15:05:41,627 DEBUG - SQLiteConnection Opened!
2014-03-27 15:05:41,627 DEBUG - SQLiteCommand Creating...
2014-03-27 15:05:41,627 DEBUG - SQLiteCommand Created!
2014-03-27 15:05:41,627 DEBUG - SQLiteCommand executing reader...
2014-03-27 15:05:41,658 DEBUG - SQLiteCommand executed reader!
2014-03-27 15:05:41,658 DEBUG - DataTable Loading...
2014-03-27 15:05:41,767 DEBUG - DataTable Loaded!

Как видите, в этом случае для открытия соединения потребовалось 1,7 секунды. Я пытался повторить это, и не могу предсказать, будут ли последующие подключения открываться почти сразу или будут задерживаться, как это.

Я подумал об использовании какой-либо формы пула соединений, но стоит ли это использовать для однопотокового приложения с одним экземпляром? Прямо сейчас я создаю экземпляр своего класса SQLiteDatabase и вызываю функцию ниже для каждого из моих запросов.

public DataTable GetDataTable(string sql)
{
    DataTable dt = new DataTable();
    try
    {
        Logging.LogDebug("Creating SQLiteConnection...");
        using (SQLiteConnection cnn = new SQLiteConnection(dbConnection))
        {
            Logging.LogDebug("SQLiteConnection Created!");
            Logging.LogDebug("SQLiteConnection Opening...");
            cnn.Open();
            Logging.LogDebug("SQLiteConnection Opened!");
            Logging.LogDebug("SQLiteCommand Creating...");
            using (SQLiteCommand mycommand = new SQLiteCommand(cnn))
            {
                Logging.LogDebug("SQLiteCommand Created!");
                mycommand.CommandText = sql;
                Logging.LogDebug("SQLiteCommand executing reader...");
                using (SQLiteDataReader reader = mycommand.ExecuteReader())
                {
                    Logging.LogDebug("SQLiteCommand executed reader!");
                    Logging.LogDebug("DataTable Loading...");
                    dt.Load(reader);
                    Logging.LogDebug("DataTable Loaded!");
                    reader.Close();
                }
            }
            cnn.Close();
        }
    }
    catch (Exception e)
    {
        throw new Exception(e.Message);
    }
    return dt;
}

Редактировать:

Конечно, dbConnection это строка подключения, установленная следующей функцией. inputFile это просто строка пути к открываемому имени файла.

public SqLiteDatabase(String inputFile)
{
    dbConnection = String.Format("Data Source={0}", inputFile);
}

И на данный момент, я думаю, sql не имеет значения, так как он не доходит до того момента, когда cnn.Open() останавливается.

Изменить 2:

Хорошо, я сделал еще несколько испытаний. Выполняя тестирование локально, он завершает цикл 1000 итераций за ~5 секунд, около 5 мс на вызов cnn.Open(), Выполнение теста из того же установщика Windows, что и на моем локальном ПК, завершается за ~25 минут, в среднем 1468 мс на вызов cnn.Open(),

Я сделал небольшую тестовую программу, которая вызывает только TestOpenConn() функция из служебной программы (тот же самый код, который выполняется в службе Windows), работающая с копией файла, расположенного в тестовой директории. Выполнение этого на сервере или на моем локальном ПК приводит к приемлемой производительности (1,95 мс на вызов на сервере, 4 мс на вызов на моем локальном ПК):

namespace EGC_Timing_Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Logging.Init("log4net.xml", "test.log");
            var db = new SqLiteDatabase("config.sqlite");
            db.TestOpenConn();
        }
    }
}

Вот тестовая функция:

public void TestOpenConn()
{
    // TODO: Remove this after testing loop of opening / closing SQLite DB repeatedly:
    const int iterations = 1000;
    Logging.LogDebug(String.Format("Running TestOpenConn for {0} opens...", iterations));
    var startTime = DateTime.Now;
    for (var i = 0; i < iterations; i++)
    {
        using (SQLiteConnection cnn = new SQLiteConnection(dbConnection))
        {
            Logging.LogDebug(String.Format("SQLiteConnection Opening, iteration {0} of {1}...", i, iterations));
            var startTimeInner = DateTime.Now;
            cnn.Open();
            var endTimeInner = DateTime.Now;
            var diffTimeInner = endTimeInner - startTimeInner;
            Logging.LogDebug(String.Format("SQLiteConnection Opened in {0}ms!", diffTimeInner.TotalMilliseconds));
            cnn.Close();
        }
    }
    var endTime = DateTime.Now;
    var diffTime = endTime - startTime;
    Logging.LogDebug(String.Format("Done running TestOpenConn for {0} opens!", iterations));
    Logging.LogInfo(String.Format("{0} iterations total:\t{1}", iterations, diffTime));
    Logging.LogInfo(String.Format("{0} iterations average:\t{1}ms", iterations, diffTime.TotalMilliseconds/iterations));
}

4 ответа

Решение

Я думаю, что моя проблема решена на данный момент... Я изменил и мое сервисное и тестовое приложение, чтобы работать как SYSTEM учетная запись вместо NetworkService учетная запись. Еще неизвестно, сохранятся ли выгоды от изменения учетной записи пользователя, или это будет только временно.

Я предполагаю, что вы используете открытый исходный код System.Data.SQLite библиотека.

Если это так, то через Профилировщик производительности Visual Studio легко увидеть, что Open метод SQLiteConnection класс имеет некоторые серьезные проблемы с производительностью. Кроме того, ознакомьтесь с исходным кодом для этого класса здесь: https://system.data.sqlite.org/index.html/artifact/97648754af51ffd6

Для чтения конфигурации XML и переменных среды Windows требуется очень много доступа к диску.

Мое предложение состоит в том, чтобы попытаться позвонить Open() как можно реже, и попробуйте сохранить ссылку на этот открытый SQLiteConnection объект вокруг в памяти.

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

Каждый раз, когда служба открывала соединение, это занимало более 1,5 секунд, но в остальном работало правильно (в конечном итоге она могла получить доступ к файлу). Автономная программа, работающая от имени обычного пользователя, может за несколько миллисекунд открыть соединение с тем же файлом в том же месте.

Анализ трассы procmon показал, что в случае службы мы получали несколько журналов ACCESS DENIED для файла в течение примерно 1,5 секунд, которых не было в трассировке при работе от имени обычного пользователя.

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

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

Вы можете добавить разрешения "Изменить" соответствующего пользователя в папку с вашей базой данных. Щелкните правой кнопкой мыши папку> Свойства> Безопасность> Изменить> Добавить (я добавил IIS_Users) > Установите флажок "Изменить"> ОК

Другие вопросы по тегам