Bankir.Ru
9 декабря, пятница 14:45

Объявление

Свернуть
Пока нет объявлений.

Давайте сравним системы Интернет-банкига по производительности

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Давайте сравним системы Интернет-банкига по производительности

    На форуме много обсуждались функциональные возможности систем Интернет-банкинга.
    Давайте попробуем вместе (с производителями сравнить различные системы с точки зрения производительности.
    Такая оценка становится все более важной по мере роста числа пользователей систем И-Б. Представим себе Сбербанк - какая система смогла-бы потянуть такое количество физиков?

    В качестве критериев можно пердложить следующие параметры

    - максимальное число клиентов;
    - максимальное число одновременно обслуживаемых клиентов;
    - максимальное время отклика на запрос при одновременном запросе всех пользователей;
    (естественно необходимо указывать конфигурацию тестовой системы)

  • #2
    С точки зрения клиента производительность банковской компоненты измеряется в скорости реакции решения на действия пользователя.

    Действия пользователя - заходит в то или иное меню, заказывает выписку за период, открывает справочник, ищет в справочнике SWIFT-а реквизиты банка бенефициара и т.д. Главное - быстрая реакция системы (интерфейса) на производимые действия.

    Скорость реакции прямо пропорциональна производительности сервера и обратно пропорциональна объему трафика, передаваемого клиенту при каждом действии клиента.

    Если у Вас супер-пупер производительный сервер, но при этом на каждый чих пользователя сервер генерирует 15..30 Кбайт данных, загружаемых клиенту, а клиент - самый обычный физик, работающий через диалап на 21600, то такая система НИЗКОПРОИЗВОДИТЕЛЬНАЯ ДЛЯ КЛИЕНТА. Ибо время реакции интерфейса на действие пользователя будет от 10 секунд и более. И после 10 минут такой "работы" начинаешь себя чувствовать тормозом.

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

    Если система спроектирована правильно и на создание одной платежки тратится 2..4 Кбайта трафика между клиентом и банком (а не 20..40 Кбайт как в отдельных случаях), тогда с точки зрения клиента необходимое условие для высокой скорости реакции соблюдено, и можно спокойно переходить к определению критериев производительности для банковской (серверной) компоненты.

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

    Как правило, обмен данными между банком и клиентом осуществляется через защищенное соединение. Для этого применяют различные криптопротоколы - SSL, TLS, свои наработки.

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

    Далее. Криптопротоколы привносят избыточность трафика. От этого никуда не деться. Стандартные криптопротоколы - TLS, SSL - универсальны, имеют много различных реализаций на разных языках. Главный НЕДОСТАТОК стандартных криптопротоколов - ЧРЕЗМЕРНАЯ ИЗБЫТОЧНОСТЬ СЛУЖЕБНОГО ТРАФИКА - является законной платой за универсальность.

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

    Достаточно лишь согласовать сеансовые ключи, при необходимости провести аутентификацию сторон, и проконтролировать уникальность сессии.

    Недостаток самостоятельно спроектированных и реализованных криптопротоколов - отсутствие в публичном доступе подробных описаний, отсутствие независимых (а лучше академических) исследований на предмет стойкости к тем или иным атакам.

    Ну кто и что, например, знает о криптопротоколе, используемом в BS-Defender'е российской компании "Банк'с Софт Системс"? Общие слова Дмитрия Барсукова, сказанные более года назад в этом форуме, не внесли совершенно никакой ясности

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

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

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

    В качестве критериев можно пердложить следующие параметры

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

    Подобная организация взаимодействия (постоянная TCP-сессия на всё время работы клиента с банком) акутальна только при необходимости иметь push-канал для доставки клиенту информации по мере ее появления. Область применения Push-каналов - интернет-трейдинг, когда серверная компонента "выталкивает" информацию по мере ее поступления с биржи и в соответствии с профилем трейдера.

    Недостаток такого взаимодействия - существенные затраты и низкоэффективное использование серверных ресурсов. Решения для Интернет-Банкинга совершенно не требуют постоянного подключения клиента к банку, ибо взаимодействие между банком и клиентом возникает на короткие моменты в процессе действий пользователя (и то не на каждый чих, ибо часто на клиенте используюся механизмы интелектуального кеширования прикладных запросов а также организация временного хранилища уже полученной информации).

    Взаимодействие между клиентом и сервером для Интернет-Банкинга правильнее строить на основе транзакций. Появилась необходимость получить данные - клиент установил TCP-сессию - поверх нее открыл защищенное соединение (SecureSocket). Далее отослал прикладной запрос, получил прикладной ответ, завершил защищенное соединение, закрыл TCP-сессию. Именно так работают решения на основе протокола HTTPS (HTTP поверх SSL). Именно так работает клиент и в iBank 2.

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

    Время одной транзакции для хороших систем в районе двух..пяти секунд - в зависимости от объема данных, передаваемых клиенту а также от канала клиента. Скважность подобных запросов для правильно организованных систем - не менее 10 (один запрос в 20..50 секунд). При производительности сервера 20 транзакций в секунду, на одном сервере можно одновременно обслуживать 400..1000 клиентов.

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

    По последним исследованиям реальных логов серверов приложений на одну платежку приходится в среднем 9..11 транзакций (прикладных запросов). Хотя саму платежку можно создать, сохранить и подписать за 4 запроса, клиенты любят еще полазить в выписках, порыться в справочниках, сохранить а потом отредактировать платежку, использовать отложеную подпись платежки. В итоге в среднем как раз и набирается 9..11 транзакций на одну платежку.

    При производительности 10 транзакций в секунду сервер может тянуть до 3500 исходящих от клиентов документов в час. Юрлица, в основном в массе своей работающих с Интернет-Банкингом, "имеют привычку" создавать пик нагрузки в период с 11 до 15 часов. В некоторых банках, в зависимости от режима принятия документов - до 16..17 часов. Хотя при анализе логов встречались "маньяки" (а может очень удаленные клиенты-юрлица) работающие (создающие и подписывающие платежки) и в 3 часа ночи

    Но все-таки основной пик - с 11 до 15. Именно на это время, когда создается и подписывается 85% платежек, и надо ориентироваться. Соответственно за четыре часа в идеале сервер готов обработать около 14 тыс. документов от юриков. Но с учетом запаса по производительности в 50% наша цифра снижается до 7 тыс. документов в пиковый период дня.

    Что же касается решения для Сбербанка... такие проекты из ряда эксклюзивных.

    В одних банках достаточно благоприятно воспринимают идею поставить пяток дуальных ксеонов с двумя гигами памяти каждый стоимостью по 4k$ и запустить на них сервера приложений.

    В других банках ценят временные затраты сотрудников на сопровождение большого кол-ва серверов и предпочитаю ставить один восьмипроцессорный Sun или даже бубернадцатипроцессорный RS/6000. Да, техника получается на порядок дороже, но в итоге надежнее и проще в администрировании чем десяток писюков

    Хотя если руки растут из правильного места, ничто не мешает и на писюке сконфигурировать Solaris. Благо, если один из писюков-серверов приложений грохнется, ничего страшного не произойдет и система не встанет - вся нагрузка от клиентов распределиться между оставшимися работающими серверами приложений. Уязвимым (менее надежным) местом может оказаться именно сервер БД И-Б. Но и здесь под Сервер БД И-Б ничто не мешает поставить Sun Fire 480R с 4-мя SPARC III, с RAM 32Gb и внешним RAID-массовом, взграмоздить на него Oracle, настроить бэкап баз... и спать спокойно
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

    Комментарий


    • #3
      Дмитрий спасибо за развернутый ответ, надеюсь что и другие производители примут участие в обсуждении.

      Но все-таки основной пик - с 11 до 15. Именно на это время, когда создается и подписывается 85% платежек, и надо ориентироваться. Соответственно за четыре часа в идеале сервер готов обработать около 14 тыс. документов от юриков. Но с учетом запаса по производительности в 50% наша цифра снижается до 7 тыс. документов в пиковый период дня.

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

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

      Если у нас все будет двигаться в том-же направлении, что и на западе, то в скором времени при открытии счета/карточки банки будут сразу подключать пользователя к системе И-Б.

      Например опыт скандинавских товарищей
      Nordea has now passed the 3 million mark in the number of e-customers.
      "Currently, the number of log-ons is almost 9 million and
      the number of invoices paid over 10 million each month, more than anywhere else
      in the world. We estimate that Nordea's customers will pay 120 million invoices
      via the Internet this year and the number of log-ons will exceed 100 million."

      По моим расчетам выходит, что в день через систему идет порядка 300.000 документов - не мало (из расчета 10-и часового рабочего дня 30.000 док в час),
      но если взглянуть с другой стороны в среднем всего по 3-4 документа на клиента в месяц.

      Комментарий


      • #4
        Если можно опишите по подробнее конфигурацию системы, дающей такую производительность.
        В одном из известных российских банков под старый добрый iBank 1.8.3 выделено два Sun'а - двухпроцессорный Sun с RAID-массивом исключительно под Сервер БД iBank'а (используется Oracle), и ЧЕТЫРЕХпроцессорный Sun под Сервер Приложения iBank. Вот там запас производительности действительно высок - там спокойно и 5 тыс. документов документов в день (в пиковый период) будет обслуживаться, и 10 тысяч, и даже 20 тысяч
        С уважением, Репан Димитрий
        Компания "БИФИТ" - www.bifit.com

        Комментарий


        • #5
          GeC
          но если взглянуть с другой стороны в среднем всего по 3-4 документа на клиента в месяц.
          Как-то значительно расти количество документов на одного клиента не будет, а вот кол-во клиентов - ради бога. Вот тут и может появиться та самая отдельная серьезная тема - масштабирование Сервера БД. Об этом надо задумываться еще на стадии проработки проекта.

          Комментарий

          Пользователи, просматривающие эту тему

          Свернуть

          Присутствует 1. Участников: 0, гостей: 1.

          Обработка...
          X