gifts2017

Ускорение для Клиент-Банка

Опубликовал Яков Коган (Yashazz) в раздел Обмен - Обмен с интернет-банком

У вас много платежей и клиент-банк долго их читает? Есть проверенная практикой идея, как это ускорить.

Те версии программ взаимодействия "клиент-банк", которые работают с текстовыми файлами, при больших объёмах думают долго, последовательно обходя файл построчным чтением текста. Что можно сделать:

1. Проанализировать наполнение текстового файла, стабильность разметки, разнообразие специфических символов (особенно в назначениях платежей).

2. С помощью регулярных выражений или простым СтрЗаменить привести текст к виду xml.

3. Исходя из разметки (т.е. тегов), используемых в ваших файлах, сделать xdto-объекты ровно той структуры, которая отвечает разметке. Правильно объявляем типы свойств. Динамически создаём и подгоняем xsd под файл xml.

4. Использовать сериализатор для быстрого чтения и получаем, например, СписокXDTO, каждый объект которого есть платёжная транзакция со своими xdto-свойствами.

5. Выполнить чтение из полученных объектов. От цикла всё равно не уйти, но это в разы быстрее благодаря сериализации п.4

  

UPD: Выкладываю обработку, иллюстрирующую эту технологию. Рассчитана на интерфейсно-пользовательско-клиентское и на  серверное применение. Не является законченным решением, т.к. вся работа доходит до чтения объекта "СписокXDTO" и заполнения таблицы значений - поэтому, коллеги, вы можете сделать собственные обход и обработку результатов чтения.

Ахтунг! Недостаток способа в том, что он чувствителен к наполнению и структуре файла, поэтому при битых, экзотических или изменившихся текстовых входных данных xml-вариант просто не прочитается, и эту уязвимость придётся "лечить" каждый раз очень внимательно. В предлагаемую обработку встроена возможность делать свои замены с помощью регулярных выражений, и эти замены могут сохраняться в настройках чтения.

На моих данных, типовой "Клиент-банк" сперва думал около часа, тогда как мой вариант работал 5-7 минут; а потом и вовсе пришлось заменить, т.к. типовая обработка стала вылетать и виснуть. Надеюсь, вам удастся ускорить работу примерно так же. В принципе, обратная выгрузка может быть сделана аналогично - запись в xml средствами xdto и обратная конвертация в текст с заменой на общепринятую разметку.

Также обработка может пригодиться как пример работы с динамическими xsd.

 

 

Скачать файлы

Наименование Файл Версия Размер
CBReader 10
.epf 24,70Kb
08.05.13
10
.epf 24,70Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Модератор раздела Артур Аюханов (artbear) 10.10.12 07:31
Без готового решения, пусть и не универсального, статья слабовата :(
2. Яков Коган (Yashazz) 10.10.12 13:37
(1) Чем же слабовата? Идея ясна? Ясна. Воплощение - у каждого своё, как наполнение файлов Клиент-банка своё. Имхо, это лучше, чем вывалить свою узкоспециальную обработку и читать потом жалобное "а у меня не фурычит".
3. qwe qwerty (quebracho) 10.10.12 15:30
Более приятно было бы видеть пример в картинках с пояснениями.
4. Maximilian Alekseevich (1cmax) 19.12.12 02:36
Интересно, что это за файл, который обрабатывался клиент-банком 1 час??
5. Яков Коган (Yashazz) 09.05.13 00:12
(3) Теперь пример есть.
(4) Вот такие у нас файлы платежей. Много, из разных банков по всей стране, от физлиц и юрлиц. Крупная компания...
6. Сергей (Che) Коцюра (CheBurator) 11.05.13 12:58
(5) "много" - это ни о чем... Конкретнее, озвучьте, плиз, много это сколько? около тысячи платежей? сотни? десятки тысяч?
и как-то мне сомнительно, что последовательное чтение и независимая обрботка платежей будет медленнее чем все это преобразование в xml и прочие обработки исходного файла...
7. Яков Коган (Yashazz) 23.08.13 17:17
Кстати, обнаружено-таки побочное явление: здорово кушает оперативку на точке выполнения (в моём случае на клиентской машине). Был случай "Недостаточно памяти". Есть подозрение, что текстовые переменные 1С всё же не совсем оптимально гоняет; впрочем, идею это не отменяет. И думаю, что СтрЗаменить ресурсоёмка, надо б везде заюзать внешние RegExp'ы.

(6) Не поверишь, быстрее. А вот недавно поставленный эксперимент по сериализации меня удивил. Решил я померять, как быстрее массив в таблицу значений перегоняется - через сериализацию Array, один вызов СтрЗаменить, конкатенацию и десериализацию уже в ValueTable; или циклом. И что? И оказалось, что банальный цикл по массиву с добавлением строк в ТаблицуЗначений оказался в 1.5 раза быстрее всех этих строково-xmlных игрищ. Так что, замечание в целом верное, есть в работе с xml ситуации проигрыша по скорости, только не в случае вышеприложенной обработки.
8. Сергей (Che) Коцюра (CheBurator) 23.08.13 20:59
Всеравно ни о чем. возьмите файл выписки большой. прогоните его штатно с замеромпроизводительности и через вашу приблуду. насколько быстрее..?
9. doxflow (bonv) 28.08.13 22:17
(7) Какие-то сказки рассказываете про то что некий "клиент-банк" работает медленнее некой вашей обработки.
А где факты?
Что за "клиент-банк"? Что за конфигурация? Какая версия? Какая платформа? Где цифры замеров?

Например, взять "клиент-банк" из БП 3.0. Раньше в качестве "построчного считывания" текстового файла использовался объект ТекстовыйДокумент и его метод ПолучитьСтроку(). Что естественно сказывалось на скорости считывания - ибо на каждую ПолучитьСтроку(N) всегда читались заново все строки до N.

Недавно разработчики устранили эту нелепость - теперь используется объект ЧтениеТекста. Скорость считывания файла выроста на порядки.
10. Яков Коган (Yashazz) 02.09.13 13:24
(9) Батенька, вы тон-то сбавьте. Обычная БП 2.0, обычный встроенный Клиент-банк. И обычный файлик реестра платежей, на котором он уже в первые дни работы компании в 2012 году стал думать час и более, об чём я писал во первых строках публикации, а моя думала минуты, ну 10-20 минут максимум. Точные замеры тогда не делались, а теперь невозможны, ибо штатный Клиент-банк просто виснет. А мой блок - работает. Вот такие факты. ЗАО "Техосмотр", миллионы платежей по РФ в день. Резать файлики и устраивать тесты мне, пардон, теперь недосуг.

Рад за разработчиков 3.0, что они наконец тоже нечто предприняли и воспользовались ЧтениемТекста. Но, см. выше, в 2012 про 3.0 никто не слыхивал, да и сейчас пока на 2.0 почти все сидят.
Впрочем, я красивую идею подкинул, а уж кто воспользуется и кто будет продолжать мучиться - каждый решает сам.

А то, знаете, некоторые и xml-файлы чёткой структуры до сих пор читают объектом ЧтениеXML, поэлементно в цикле.
11. doxflow (bonv) 04.09.13 14:28
(10) Yashazz, ну правильно в БП 2.0 это никто не исправлял и исправлять не будут. Ибо жить БП 2.0 осталось не долго.

> Те версии программ взаимодействия "клиент-банк", которые работают с текстовыми файлами, при больших объёмах думают долго, последовательно обходя файл построчным чтением текста.
Вот это и есть сказки. Я уже объяснил почему в предыдущем сообщении.

> А то, знаете, некоторые и xml-файлы чёткой структуры до сих пор читают объектом ЧтениеXML, поэлементно в цикле.
И возможно правильно делают. Попробуйте прочитать гигабайтный файл XML (наприме файл обмена) с помощью XDTO. Боюсь что вас будет ждать сюрприз)
12. Яков Коган (Yashazz) 04.09.13 17:37
(11) Гигабайтные файлы не читал. Вы намекаете, что где-то не хватит ресурса? Где, какого? Если знаете, расскажите, а то я весь наивный юноша и верю, что 1С с xdto работает экономно да на сервере... Тоже сказка?
(это я не ёрничаю, а правда интересно)
13. doxflow (bonv) 05.09.13 09:11
(12) Проблема в том, что объект XDTO размещается в оперативной памяти. Причем весь объект сразу.
И при этом памяти под объект почему-то требуется больше. Если учесть, что под 32-разрядный процесс выделяется только 4Гб памяти, то с вероятностью почти 100% при чтении гигабайтного XML сервер упадет с ошибкой нехватки памяти.
На 64-разрядном сервере файлы считать можно будет чуть побольше по размеру. А если учесть, что сервер вообще должен еще и другой полезной работой заниматься, а также фрагментировать памяти, то лучше забыть про идею считывать огромные файлы в XDTO.
14. Яков Коган (Yashazz) 06.09.13 18:29
(13) Понятно. Грустная информация, но учту. А я-то верил в некое кэширование...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа