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

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

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

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

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

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

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

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

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

  

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

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

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

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

 

 

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

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

См. также

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

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

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

Недавно разработчики устранили эту нелепость - теперь используется объект ЧтениеТекста. Скорость считывания файла выроста на порядки.
10. Яков Коган (Yashazz) 1987 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) 1987 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) 1987 06.09.13 18:29 Сейчас в теме
(13) Понятно. Грустная информация, но учту. А я-то верил в некое кэширование...