v7DBNet + 1Sqlite = ?

[Djelf]

Для предварительного разогрева ведь like не нужен, какой запрос будет наиболее быстрым и эффективным?

Да чорт его знает как Виртш сделал кеширование, декомпилировать и копаться так себе удовольствие...

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

Что по факту делает лайк? Он перебирает все объекты и для каждого проверяет соответствие. Это идет в цикле.
Т.е. у нас есть небольшой лаг связанный с проверкой лайка и позиционированием на следующий элемент.
И вот этот лаг, вроде бы совсем небольшой, микросекундный, может в цикле при сетевой задержке и приводить к тормозам при запросе без прогрева.

Видимо просто select descr from справочник_номенклатура, или не descr, а id, будет эффективным для прогрева.
И! Можно затем проверить любое другое поле справочника на скорость выборки, после прогрева, если кеширование частичное, то будет лаг, если полное, то будет одинаково быстро по каждому полю справочника.

Еще один момент: чорный запрос из 1с может быть более эффективен для прогрева, чем прямой запрос 1sqlite, я это не утверждаю, но это возможно. Это надо проверять.

[Arbuz]

Для предварительного разогрева ведь like не нужен, какой запрос будет наиболее быстрым и эффективным?

что-то типа, но он по определению будет не самым быстрым, а наоборот:

SELECT MAX(rowid) AS cnt FROM Справочник_Номенклатура

[Arbuz]

descr нельзя использовать, т.к. это индексированное поле и wirth кэширует страницами, то нужен полный скан таблиц. И я неправильно понял про скорость — max(rowid) будет самым быстрым полным сканом.

[Djelf]

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

[item]

В общем, парни, результат у меня такой.
Сетка 100Мб, сервер X3440, SSD бюджет, 8 юзеров, номенклатура ~25000.

Протестированы четыре запроса:
#1. "SELECT descr as Наименование, id as [Элемент :Справочник.Номенклатура] ..."
#2. "SELECT id as [Элемент :Справочник.Номенклатура] ..."
#3. "SELECT MAX(rowid) AS cnt FROM [Справочник.Номенклатура]..."
#4. Штатный "ТекущийЭлемент = Справочник.Номенклатура.ТекущийЭлемент| Без итогов"

Результаты первичных запросов практически идентичны, все укладываются по времени в 50-60 сек
(#1 и #2 ~ 55 сек, #3 ~ 50 сек, #4 ~ 60 сек), и все кэшируют таблицу полностью.
Результаты повторных запросов разнятся относительно существеннее:
#1 ~ 0.27 сек, #2 ~ 0.21 сек, #3 ~ 0.18 сек, #4 ~ 4.5 сек.

В общем, нет смысла кэшировать descr, достаточно только id,
а поскольку запрос #3 чуток быстрее, я на нём и остановился.

Респект, друзья, от начинающего 1sqlite-щика.

[Злоп]

Какие вы все умные!

[Djelf]

В общем, парни, результат у меня такой.

Результаты первичных запросов практически идентичны, все укладываются по времени в 50-60 сек
(#1 и #2 ~ 55 сек, #3 ~ 50 сек, #4 ~ 60 сек), и все кэшируют таблицу полностью.
Результаты повторных запросов разнятся относительно существеннее:
#1 ~ 0.27 сек, #2 ~ 0.21 сек, #3 ~ 0.18 сек, #4 ~ 4.5 сек.

Тест отличный!
Результаты в пределах погрешности.
Но 60 секунд на заполнения кэша не очень комфортно...

1. Что выдает по скорости копирование этих файлов по смб?
25000 записей могут быть очень разным по размеру файла.

2. Если есть длинные строки? Науке не известно кеширует ли их Wirth.
Можно проверить на копии, просто грохнуть длинные строки (это предположение, возможно такого кэша нет).
Этот тест надо делать в разделенном режиме, 2-3 пользователя минимум, монопольный режим очень сильно отличается по скорости.

3. Можно включить монопольный режим доступа в sqlite, это сильно ускорит кеширование, но кто-то может отвалится на транзакции.
Но если это ускорит наполнение кэша раз в 10, то это будет довольно эффективно и не будет сильно заметно всем остальным пользователям.

Ну... или вообще забить на это и работать по rdp?

Вроде я все мои идеи на текущий момент описал, не понятно что еще придумать.
Кидайте идеи...