23 ноября 2011 г.

Как сделать так, что бы ваше приложение загружалось гораздо быстрее?


Конфигурационные файлы


Мы все очень любим делать наше программное обеспечение (ПО) настраиваемым. И в истории ПО-писания есть множество примеров того, как именно это делалось.

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

В какой-то момент мы начинаем замечать, что загрузка нашей программы длится все дольше и дольше, а если наше ПО используется для обслуживания подключений онлайн-пользователей, например, и количество
подключений перерастает некоторый порог, то загрузка конфигурации может отнимать существенное время.




Что делать, если это явилось проблемой?


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

Понятно, что и количество транзакция было не столь велико, но, с другой стороны, и количество центров обработки было очень мало, что, в общем приводило к тому, что плотность транзакция, если можно так сказать, на один центр обработки была достаточно велика.

Вспомним, например MVS или ее наследницу z/OS и иерархическую СУБД IMS. Современные реализации IMS позволяют обслуживать до 40 тысяч подключений в секунду, обрабатывая каждое подключение в отдельном адресном пространстве (аналог процессов в Windows). И загрузка конфигурации может представлять определенную проблему.

Задача решена достаточно, на мой взгляд, элегантно.

Конфигурационные файлы IMS, в их исходном виде представляют собой, как и многие другие конфигурационные файлы в MVS или z/OS, текст написанный на языке ассемблера, а точнее сказать с использованием макрокоманд ассемблера. После редактирования файл транслируется макроассеблером и использованием макробиблиотек ПО и, далее IMS во время загрузки использует готовый загрузочный модуль.

Собственно, в каких-то проектах, особенно, если вы используете не слишком мощное железо, есть смысл использовать аналогичный подход с применением вашего любимого компилятора.

Напишите процедуру, которая будет возвращать заполненную структуру конфигурации в ваше ПО, поместите ее в dll, например, и линкуйте, можно даже статически, с вашим ПО.

Экономия очевидна: а) на загрузку кода парсинга конфигурационных файлов, б) на сами конфигурационные файлы.

Dixi.

23 комментария:

  1. ))) Руслан, этот подход на мейфрейме использует не только IMS. Вся настройка ADABAS+Natural идет через ассемблерные файлы, которые выглядят как вызов простых и понятных макросов. Так же и в самой zOS и zVM настраивается большинство компонент.
    На ПЭВМ такой подход использовался на ранних промышленных продуктах в среде DOS. Сейчас, наверное, под Win таких продуктов уже не найдешь.

    ОтветитьУдалить
  2. Я IMS привел в качестве примера ))

    У меня, волею судеб, размер конфигурационного файла достиг 3-х мегабайт ))

    ОтветитьУдалить
  3. кто о чём, а Костырко об Адабазе и VM ;)
    ZPARN (конфигурация DB2/Z) тоже, между прочим...
    Точно так же.
    Так что большинство, пожалуй.
    Есть, правда, исключение WebSphere Application Server for z/OS, будучи приложением, в котором все конфиги лежат в файловой системе ZFS в USS. Ну тут ясно с вэбсферным сервером приложений - плохая наследственность, родовая травма...
    Остальные приложения USS тоже, скорее всего, по модному текстовыми файлами конфигурируются.
    А труёвые z/OS приложения - по старинке.

    ОтветитьУдалить
  4. пардон, очепятка - ZPARM, конечно.
    хм, редактирование запрещено, что ли, опубликованных комментариев?
    Это что, я вот сейчас разбираюсь с администрированием IMS, в частности, конфигурации, ещё более в частности, выполнению Stage 1, Installation verification Program.
    Это нечто, ну нельзя же так... надо бы и документацию чуток полнее... На мой взгляд, неоправданно усложнено.

    ОтветитьУдалить
  5. О!!! щас знаете, чо скажу?)))
    нашел свои программы на REXX, года эдак 92-94. так там конфигурационный файл в виде строк типа "PARM='value';" то есть инструкции самого REXX. Далее в процессе выполнения программы на этот файл запускается команда INTERPRET, и нужные значения оказываются в требуемых переменных. Это практически предложенный подход. И таким образом у нас писались почти все крупные REXX-проекты, это не я сам придумал.
    Так что умные мысли - того. В воздухе!

    ОтветитьУдалить
  6. Ну я, в общем, не вижу большого смысла в "исправляемых-на-лету" конфигах.
    Как правило это говорит о недостаточной проработке архитектуры

    ОтветитьУдалить
  7. Ну, на лету, тоже имеет место на жить, чуточку.
    К примеру, та же база, любая.
    На большую часть дня - одна конфигурация, для оперативной обработки, потом - на технологическое окно ночное - меняем конфигурацию на пакетную нагрузку, отчёты там, административные или какие другие работы, потом по окончанию окна - опять меняем, в оперативную.
    Имеет место быть, почему нет.
    При загрузке - первоначальная конфигурация, смена конфиграций - через соответствующий API, значения переменных там поменять, участки всякие в памяти переаллокейтить...

    ОтветитьУдалить
  8. эээ
    ==============
    Ну я, в общем, не вижу большого смысла в "исправляемых-на-лету" конфигах.
    Как правило это говорит о недостаточной проработке архитектуры...
    ==============
    я тоже не вижу. а у кого конфигурация меняется "на лету"?

    ОтветитьУдалить
  9. Это я вапще, а не про ваше замечательно приложение на рексе ))

    ОтветитьУдалить
  10. так и я воопще. мне просто интересно... это на мейнфрейме на лету подменяется где-то? я вот по-старинке перестартовываю задания и сервисы.

    ОтветитьУдалить
  11. у баз данных.
    может меняться.
    при необходимости.
    модно - конфигурационные параметры, меняемые динамически.
    ты не базовик, тебе не понять :)
    Если бы парил мозги себе с OpenLDAP, а потом вдруг тебе дали бы IBM Tivoli Directory Server, ты бы пришёл в восторг от того, что перезапуск сервера требуется при смене только одного параметра (алгоритм шифрования пароля).
    Давно, правда, было, лет 10 назад...

    ОтветитьУдалить
  12. Не, я про то, что если есть необходимость на лету менять конфигурацию, то что-то не то в датском королевстве.
    Как правильно написал Григорий, должно быть api, при помощи которого можно осуществить необходимые редкие и единичные действия по смене конфигурации.

    ОтветитьУдалить
  13. а ты посоветуй Bank of America или Visa Inc. - чего они мудрят, пусть тоже сервисы перестартовывают :)
    Делов то :)
    А лучше - всю ОС, а чего? Винду ведь народ перестартовывает, ничего :)

    ОтветитьУдалить
  14. Да чего пояснять?
    Загрузка неравномерна с течением времени.
    Вплоть до того, что на больших машинах с любимой всякими виртуализацией, иногда могут менятся даже аппаратные конфигурации - у одной ОС в связи со входом в цикл снижения нагрузки могут забирать аппаратные ресурсы динамически, в другую ОС могут их добавлять.
    И что - DB2, к примеру, каждый раз перестартовать, когда в её ОС памяти в три раза увеличили, и надо бы буферные пулы увеличить?
    Нет, делается динамически.
    Участки памяти для сортировки, и прочие - там полно мест, которые можно перераспределять в связи с цикличностью нагрузки.

    ОтветитьУдалить
  15. =============
    а ты посоветуй Bank of America или Visa Inc. - чего они мудрят, пусть тоже сервисы перестартовывают :)
    =============
    не, ты не прав. в zOS ты можешь поменять параметры динамически, но они не сохраняются, они на сеанс работы, до перезагрузки. а вот то, что в наборах данных - это перестартовывай.
    щас же на мейнфреймах динамически меняется даже конфигурация ввода-вывода. только как? не штатным путем, а динамически - сбоку, через другой API. а по прямому - только статика!

    ОтветитьУдалить
  16. да, на сеанс. Ну, допустим, у нас сеанс работы один год. Большой такой. А потом перстарт, а нагрузка пука на другом узле Параллельного Сисплекса будет. Вот в течении этого "сеанса" нагрузка будет очень циклично-неравномерна. И конфигурация будет меняться динамически.
    И не надо тут ничего сохранять "статически", после перезапуска подгрузится выбранный администратором (осуществляющим перезагрузку) модуль конфигурации из множества доступных, соответствующей рабочей нагрузке сразу после перестарта. А дальше - опять целый год динамически.
    Ну и где неправ?
    "Штатный" и "нештатный" путь уже пора убирать из лексикона :)
    Вон в IMS тоже сперва DRD прикрутили (dynamic resource definition), а ведь до этого, чтобы к примеру, новую иерархию (базу) создать, надо было подсистему перестартовать после прогона DBDGEN сотоварищи. Теперича вообще ввели System Catalog :)
    Ну и что теперь "штатно" и "нештатно" ? :)

    ОтветитьУдалить
  17. да, мир становится динамичным. даже за счет большего потребления ресурсов. теперь даже приходится рассказывать, что такое статические параметры - выросли мальчики, которые уже без динамики не живут. и даже разработку ведут, сволочи, сразу в целевой системе, без отладки.

    ОтветитьУдалить
  18. а вот это уже неправильно.
    Ты знаешь почему "научный коммунизм" это неправильное выражение?
    Потому, что если бы он был "научный", то учёные сперва на мышах бы проверили :)
    Так что не надо в целевой системе без отладки :)
    Не всё что было, было хорошо, но ведь и не всё плохо :)

    ОтветитьУдалить
  19. Да и не вижу я тут динамичности за счёт большего потребления ресурсов.
    Вот с самого начала - небыло ничего, и не надо было.
    Небыло компьютеров, и знаменитое "я оцениваю рынок компьютеров 5 штук в год".
    Потому, что даже не предугадали, как это использовать можно.
    Так и с конфигурационными вещами.
    Создали продукт.
    С нуля.
    Ну небыло раньше ничего подобного!
    Это вам не 1001 редактор для линукса - это же мэйнфреймы, многие вещи делались вообще впервые.
    Сделали конфигурирование продукта статистическим - под то использование, которое предполагали.
    А жизнь во как повернулась, все глянули - а продукт то удобный! И давай его пользовать вдоль и впоперёк, как создатели и не предполагали.
    Возникла потребность динамического добавления баз в IMS. Добавили DRD. А пользователи - на радостях - опять, как ухватились, как начали... Снова изменения - системный каталог добавили.
    Но хоть убей не пойму, где в динамическом изменении байта данных в памяти чрезмерное потребление ресурсов? Ну да, раньше считывали этот байт из конфигурационного модуля. Теперь - прикрутили API, которое позволяет его сменить без перестарта самого приклада. Что - такое дорогое действие?

    ОтветитьУдалить
  20. ===========
    Но хоть убей не пойму, где в динамическом изменении байта данных в памяти чрезмерное потребление ресурсов?
    ===========
    в том, что для динамики 1) добавили дополнительный код 2) сделали человекопонятный гибких синтаксис 3) сделали сложные проверки человекопонятного синтаксиса 4) сделали процедуры восстановления, если динамический код оказался кривой
    а для статики это не делали - там до перестартовывания пространства (или в момент инициализации) проверка идет, и синтаксис там ОБЫЧНО попроще.

    ОтветитьУдалить
  21. Ну, в принципе, да.
    Но я бы сказал, что это допустимая плата. Системы какое-то время должны усложняться в своём развитии. Потом фазовый переход. И будут новые системы :) На других принципах.
    Но по поводу человекопонятного синтаксиса - это не везде :)

    ОтветитьУдалить
  22. Дискуссия развивается))

    Хотя моя цель была, всего лишь ускорить загрузку приложения, которое вызывается достаточно часто )) что бы загрузка и парсинг многомегабайтного конфига стало проблемой.

    Я не в коем случае не исключаю необходимости и возможности динамического реконфигурирования приложения, но считаю, что начальная конфигурация, т.е. конфигурация запуска в большинстве своем должна быть встроена в код. ОСОБЕННО если приложение запускается часто. Или, например, катастрофически долго.

    Причем многомегабайтный конфиг большую часть информации имел именно для "человекочтения".

    ОтветитьУдалить
  23. Ну так, оно как бы очевидно.
    Во всяком случае тем, кто знаком с принципом конфигурации в Z.
    А в исходнике макросов ассемблера можно добавить сколько надо комментариев, для читабельности.
    Да мы и не дискутируем, мы согласовываем позиции :)

    ОтветитьУдалить