Файловая база на 2 пользователей

1. Дмитрий Лупанов (maguga) 19 14.03.17 18:26 Сейчас в теме
Добрый день, коллеги.
Запускаю розничную сеть на 100 бутиков, на базе 1с розница(риб). Задача чтоб каждый бутик мог работать без наличия интернета, т.е. автономно(поэтому риб). Интернет в бутиках по сути есть, но решено сделать автономно.
Итак что имеем. 1с Розница 2.2.3.7(естественно переписанная) платформа 1с 8.3.18.50.
Два компьютера в бутике:
1) Касса на котором стоит файловая база. размер базы 3,61 Gb
2) Касса которая цепляется по сети к соседнему компьютеру в расширенную папку

Суть проблемы в жуткой потери быстродействия на 2 кассе. У нас есть бизнес процесс, когда нашего покупателя который забыл свою дисконтную карту мы ищем по телефону(справочник Дисконтных карт полностью типовой). Количество записей физ лиц 250 000, количество записей в контактной информации ~ 1 000 000 записей.
Выполняем запрос в консоли запросов

ВЫБРАТЬ
ФизическиеЛицаКонтактнаяИнформация.Ссылка КАК Ссылка,
ФизическиеЛицаКонтактнаяИнформация.НомерТелефона КАК НомерТелефона
ИЗ
Справочник.ФизическиеЛица.КонтактнаяИнформация КАК ФизическиеЛицаКонтактнаяИнформация
ГДЕ
ФизическиеЛицаКонтактнаяИнформация.НомерТелефона ПОДОБНО &НомерТелефона

Передаем параметр в запрос

НомерТелефона = %9167871777%


Результат выполнения одного и того же запроса на первой кассе и на второй следующий
1 касса - 4 сек(Первое вложение)
2 касса - 7 мин 38 секунды(второе вложение)
Падение производительности на второй кассе 114 раз!!!

Что мы делали:
1) Меняли базы местами, результат приблизительно тот же.(исключали разницу в быстродействии двух машин)
2) Ставили базу на ноуты с ssd дисками, результат примерно тот же(исключали проблему с медленной работой дисков, долгими блокировками и т.д.)
3) Развертывали на одном компьютере две виртуальные машины, результат примерно тот же(исключали проблемы в сетевом оборудовании).
4) Разворачивали базу на других компьютерах и серверах, падение производительности в тех же пределах 100 раз(исключали возможность что у нас кассовое оборудование г***о)
5) Подключали на одном компьютере базу как локальную типа с:\1cbase так и подключали эту же базу по принципу сетевому \\localhost\1cbase. Вот тут результаты у нас были одинаковыми.

Собственно все тесты происходили как на старом, так и на новом оборудовании. Все антивирусы(не установлены) и фаерволы выключены. Замечено, что в момент выполнения запроса идет передача по сети в пределах 30 мб/с. Складывается ощущение, что для выполнения данного запроса 1с сначала полностью копирует всю таблицу на второй компьютер. Уточню что размер базы 3.61 Gb состоит на 95% из физ лиц и 5% номенклатуры(в базу закружены только два справочника из предыдущей системы). Стенды целиком и полностью тестовые. Кроме нас никто на них больше не работает, никакого лишнего софта нет.

Теперь вопрос. Коллеги с этим что то можно сделать?
Стоимость ПО на 1с розницу превысила 2 мл. рублей, предлагают купить мини сервер, но это почти еще столько же. Я про то, что Мини сервер это самый крайний вариант.

Разработчики предлагают решить задачу путем загрузки всей таблицы в память на втором компьютере, но мне не нравится это решение и подобные "костыли".
Грешу на саму платформу.
1) Хочется услышать ответ от разработчиков платформы(если таковые здесь имеются). Что делать?
2) Ответ от системщиков. Возможно есть какие то тюнинги винды, тюнинги 1с(возможно запуски с какими то ключами), сети и т.д. Какие то ключи в реестре, галочки в ie и т.д.

P.S. если в запросе использовать вместо "ПОДОБНО" конструкцию "=", то работает вполне прилично и примерно одинаково, но все равно есть тормоза с открытием журналов документов, открытием форм и т.д. на второй кассе. Поэтому вопрос все равно актуальный.
Прикрепленные файлы:
Ответы
2. Артём Шарипов (borodatii) 1 14.03.17 18:36 Сейчас в теме
Web-сервер (Apache\IIS) + тонкий клиент пробовали?
3. Михаил Сединкин (mms76) 4 14.03.17 22:09 Сейчас в теме
Сеть 100 мбит? Хотя странно вообще, что тонкий клиент тянет всю базу в запросе
4. lefthander lefthander (lefthander) 14.03.17 22:13 Сейчас в теме
(1)Попробуйте риб по рабочему месту. Локально будет на каждой кассе в пределах магазина. Один минус - контроль остатков только информационный.
зЫ такой вопрос - а что телефон по равенству нельзя искать? Зачем подобно, ведь если покупатель называет номер телефона, то он всегда точный. Или нет?
5. Semyon Newman (semyon) 14.03.17 22:57 Сейчас в теме
Насколько помнится, потеря производительности при подключении второго клиента по сети - нормальная ситуация.
Как советовали выше - поставить Apache + тонкий клиент и подключать вторую кассу через него - самый правильный вариант.
Только в этом случае каждое подключение будет требовать отдельной лицензии.
6. Дмитрий Лупанов (maguga) 19 15.03.17 11:47 Сейчас в теме
(3)Сеть и 100 и 1000, загрузка сети ~35%
7. Дмитрий Лупанов (maguga) 19 15.03.17 11:51 Сейчас в теме
По остальным.
РИБ по кассе трудно поддерживать(2 инженера тех поддержки держат 100 бутиков, подключатся к магазину или кассе чтоб пропихнуть обмен даже не думали), поэтому от него отказались.
По веб серверу- Имеется ввиду работа в браузере или подключения клиента через веб? Интересует еще работа торгового оборудования, не пробывали такой вариант, нужно протестировать.
8. Lenochka Semicova (lenochka-semicova) 15.03.17 12:53 Сейчас в теме
(7) подключения клиента через веб - т.е. тонкий клиент 1cv8c.exe обращается к базе не по локальной сети \\ПервыйКомп\ИмяБазы\
а через веб-сервер http://ИмяВебСервера/ИмяБазы/
Суть в том, что веб-сервер, развернутый на первом компе будет общаться с базой, расположенной там же локально на этом компьютере и выдавать второму компу данные по протоколу http (или https - если его настроить - но для локальной сети это не актуально), что существенно повышает быстродействие.

первый же комп может заходить в базу и локально Диск:\ПутьКбазе\...
чтобы не нагружать веб-сервер собой же лишний раз

Это старая проблема файловой 1С - если же клиент (тонкий или толстый - не суть) общается с базой по сети - то он практически всю ее по сети гоняет, периодически кешируя данные, потом сбрасывая этот кэш, снова кэшируя и т.д.
9. Дмитрий Лупанов (maguga) 19 15.03.17 15:08 Сейчас в теме
(8) Я как раз и предположил, что в файловом варианте база и копируется по сети.

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

На данный момент поиграли с запросом, сделали замеры. Перенесли номер телефона из табличной части в реквизит справочника, и вышли на 18 сек. В принципе "терпимо", продолжаем эксперименты.

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




(4)
10. Дмитрий Лупанов (maguga) 19 15.03.17 15:09 Сейчас в теме
(4) По номеру телефона, забыл ответить.
Клиент знает свой телефон, но как он заведен в систему? +7 или 8 или еще как....
11. Spenser (spenser123) 15.03.17 15:15 Сейчас в теме
(10) если по поводу телефона - то 1 раз перезаполните базу и введите правило, чтобы телефон записывался строго форматированной строкой, без 7 и без 8, только 11 цифр которые после них, а потом ищите по равенству.
mms76; alex-l19041; +2 Ответить
12. Spenser (spenser123) 15.03.17 15:21 Сейчас в теме
13. Алекс Кон (alex-l19041) 9 15.03.17 15:23 Сейчас в теме
(9)
Перенесли номер телефона из табличной части в реквизит справочника, и вышли на 18 се
- очень любопытно. Возьму на заметку
14. Spenser (spenser123) 15.03.17 15:47 Сейчас в теме
+ поиск по телефону, 1 - добавьте ограничения поиска по количеству символов, то есть искать только если строка поиска >8 символов, 2 - запрос переделайте на "ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 10", ведь при поиске по номеру большего и не надо, даже если номера не уникальны (что уже странно), среди этих 10 (правильно упорядоченных) точно будет нужный.
15. Lenochka Semicova (lenochka-semicova) 15.03.17 15:48 Сейчас в теме
(9)
при невозможности работать в магазине на 2-х кассах

Собственно - веб сервер - наше все.
На партнерском форуме 1С такая рекомендация в каждом сообщении. большинство франчей давно об этом знает. и активно использует
Дополнительного ПО там - апач или ИИС (кому что нравится) и больше никакого. Опытный внедренец за 15-20 минут разворачивает это дело и не парится вообще. там больше оборудование на новом месте настроить подключить.

Ну и к слову - любой драйвер, любая dll (компонента сканер, фискальника, дисплея покупателя, банковского терминала и т.д.) - это тоже
дополнительный софт и дополнительное звено в отказоустойчивости и зона ответственности программист/админ

Но почему-то никто этого не осознает и особо от этого не страдает, если только случайно не пригорит.
mindcannon; +1 Ответить 1
16. Дмитрий Лупанов (maguga) 19 17.03.17 12:49 Сейчас в теме
(15) Елена, про драйвера оборудования я сознательно промолчал ))))))

В момент тестирования столкнулся еще с одной неприятной ситуацией, это рост базы.
База без физ. лиц 500 мб
База с физ лицами 3.5 Gb
После моделирования параллельной работы бутика на тестовых стендах(без веб сервера), столкнулись с тем, что после закрытия базы на обоих компьютерах размер базы почему то составляет 16 Gb.

Запуск 1с на втором компьютере при повторном соединении происходит медленнее чем было до этого. После тестирования и исправления или использовании chdbfl размер базы сдувается до 3.5 Gb. Почему так распухает база???

Промежуточный вывод(да,я капитан очевидность): На скорость работы базы влияет размер, и количество записей. Так как количество записей уменьшить нельзя(более того они будут расти), проверяем возможность Уменьшения размера 1 записи. Об этом далее...

Переместили базу на sql, там она заняла 7.8GB. Запустили обработку "Анализ размеров таблиц" Премного благодарен автору http://infostart.ru/public/78049/
Смотрим
Справочник Физические лица размер таблиц 2,51GB Размер индексов 2,82 количество записей 247 623
из них
Основная Таблица 1,24 индекс 1,43
ТабличнаяЧасть: КонтактнаяИнформация Таблица 1,12 Индекс 1,34
РегистрацияИзменений Таблица 0,15 Индекс 0,04

Несложными мат. вычислениями получаем что 1 запись основной таблицы Физические лица (без индексов и таблиц) весит 5,24 кб
У нас на каждое физ лицо создан подчиненный справочник Информационные карты где лежат почти тоже количество дисконтных карт(на 3000 штук меньше) и получаем следующее:

Информационные карты Размер таблицы 0,12Gb Размер индекса 0,22Gb Количество записей 244 107
Основная Таблица 0,11 Индекс 0,21
РегистрацияИзменений Таблица 0,01 Индекс 0,01
Получаем что 1 запись основной таблицы весит 0,47 кб, что грубо в 10 раз меньше записи справочника физ лица

Заходим в конфигуратор и смотрим реквизиты таблицы и их типы. Визуально видим что в информационных картах реквизитов больше.(картинка во вложении) .
Пересчитываем видимые реквизиты в байты учитывая что 1 символ занимает 4 байта (в кодировке UTF) Выходим на 384 байта + учитывая служебные реквизиты(код. наименования, пометку на удаления, ссылку на владельца и т.д.) выйдем думаю на 1 кб из 5-ти. На что ушло еще 4 кб

Лезем в скуль, находим таблицы. В нашем случае это
Справочник.ИнформационныеКарты Reference61
Справочник.ИнформационныеКарты.Изменения ReferenceChngR1160
Справочник.ФизическиеЛица Reference135
Справочник.ФизическиеЛица.КонтактнаяИнформация Reference135.VT2454
Справочник.ФизическиеЛица.ДополнительныеРеквизиты Reference135.VT2471
Справочник.ФизическиеЛица.Изменения ReferenceChngR2476

Выполняем запрос в скуле вида sp_spaceused @objname ='[dbo].[_Reference135]'
И видим что основные таблицы(физ лиц и информационных карт) на самом деле в скуле весят разумно.
Инф.карты 217 мб(так же как и показала обработка)
Физ. лица 124 мб(обработка показала 1.2 GB) Пока не понятно где кроется еще 1.1Gb

Копаем дальше и думаем что сделать с архитектурой....
Прикрепленные файлы:
17. Lenochka Semicova (lenochka-semicova) 20.03.17 11:38 Сейчас в теме
(16) Уменьшение размера записи - это антинаучная ерунда. Убьется куча времени, а овчинка выделки не будет стоить. То что база стала с 3.5Гб до 16Гб - это кончено проблема, но связана, скорее всего с отложенной записью или сетевыми проблемами. Кроме того, мы всем клиентам при превышении порога базы в 2Гб сразу рекомендуем переходить на сервер (вне зависимости от количества пользователей). Если не переходят, то проблемы производительности - их проблемы.

В случае с файловой базой - единственный жизнеспособный вариант - это веб-сервер. Технология существует уже много лет, и пытаться изобрести велосипед - переписать конфу, уменьшить размер реквизитов и т.д.- могу только пожелать успехов.
18. Дмитрий Лупанов (maguga) 19 20.03.17 22:16 Сейчас в теме
(17)Я как раз предполагаю влезть в пределы 1-1.5 Gb. В данном случае я представляю заказчика и предложить своей компании заплатить еще 2 000 000 рублей на покупку серверных лицензий, за то что вроде бы должно работать из коробки. Ну мягко скажем резонный вопрос, за что получают зарплату ИТ отдел и я в том числе...

После того, как перепробуем все возможные и часть невозможных :) вариантов, вот тогда буду предлагать сервер.Совесть будет чиста.
Оставьте свое сообщение