ОБНОВЛЕНИЕ 30 июня Этот вопрос сделал более точный бенчмаркинг, и Mythz обнаружил проблему и решил ее: Тест ServiceStack продолжился: почему сохранение простого (сложного) в JSON замедляет SELECT?
ПИСЬМЕННО / ЧИТАТЬ СКОРОСТИ РАЗУМНО?
Я в своих испытаниях с OrmLite, я собираюсь проверить, чтобы преобразовать все наши текущие данные / объектыиз нашей собственной реализации для сохранения в базе данных и переключения на OrmLite.
Однако я провел простое тестирование / тестирование скорости, где сравнил нашу текущую сериализацию и запись в db, а также чтение из db и десериализацию.
Я обнаружил, что ServiceStack намного медленнее, чем то, как мы это делаем в настоящее время (в настоящее время мы просто сериализуем объект с помощью FastSerializer и записываем данные byte [] в поле BLOB, поэтому его можно быстро записывать и читать, но, конечно, очевидные недостатки).
Тест, который я провел, использовал класс Customer, который имеет несколько свойств (используемых в нашем продукте.это класс, который используется каждый день в наших текущих версиях).
Если я создаю 10 000 таких объектов, то измерим, сколько времени потребуется, чтобы сохранить их в базе данных MySql (сериализация + запись в db), результаты:
ОБНОВЛЕНИЕ
Поскольку «текущая реализация» обманывает (это просто BLOBing []] в базу данных), я реализовалпростой RelationDbHandler, который сохраняет 10 000 объектов обычным способом с помощью простого запроса SQL.Результаты добавляются ниже.
ЗАПИСЬ 10 000 объектов:
Текущая реализация: 33 секунды
OrmLite (с использованием .Save): 94 секунды
Реляционный подход: 24,7 секунды
ЧИТАТЬ 10 000 объектов:
Текущая реализация: 1,5 секунды
OrmLite (с помощью Select <>): 28 секунд Реляционный подход: 16 секунд
IЯ запускаю его локально, на диске SSD, без какой-либо другой нагрузки на процессор или диск.Я ожидал, что наша текущая реализация будет быстрее, но не намного быстрее.
Я прочитал некоторые тесты на веб-странице ServiceStack (https://github.com/ServiceStack/ServiceStack/wiki/Real-world-performance),, но большинство ссылок области мертвые. Некоторые просто читают 25000 строк занимает 245 мс, но я понятия не имею, как выглядит строка.
Вопрос 1: Есть ли какие-либо тесты, о которых я могу прочитать больше?
Вопрос 2: Объект Customer указан ниже.Миф считает, что приведенное выше время записи / чтения является разумным?
TEST CASE: Это объекты Customer, как они выглядят в базе данных после того, как OrmLite создал таблицу. Я заполняю только 5 свойств, одно из которых "сложное" (поэтомутолько одно поле имеет представление сериализации JSON в строке), но поскольку все поля записаны, я не думаю, что это имеет большое значение?
Код длясохранить с помощью OrmLite:
public void MyTestMethod<T>(T coreObject) where T : CoreObject
{
long id = 0;
using (var _db = _dbFactory.Open())
{
id = _db.Insert<T>(coreObject, selectIdentity: true);
}
}
Код для чтения всех из таблицы:
internal List<T> FetchAll<T>()
{
using (var _db = _dbFactory.Open())
{
List<T> list = _db.Select<T>();
return list;
}
}