Bankir.Ru
20 января, пятница 04:45

Объявление

Свернуть

Конференция «Банки и МСБ. Перезагрузка отношений»

Показать больше
Показать меньше

Сравнение Web и Java технологий. Производительность..

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

  • Сравнение Web и Java технологий. Производительность..

    web-технологии: в системе нет, как таковой, закачки логики ни для рублей, ни для валюты. На одной дискете клиента находятся как средства защиты, так и загрузочное меню в ActiveX (опционально). Из банка закачиваются только html-формы каждого документа. На один документ приходится примерно 20 Kb суммарного трафика клиента с банком (BS-Client).

    java-технологии (iBank): закачка рублевого апплета чуть более 100 Кb + весь цикл на одну платежку примерно 7Кb. Вот тут-то и окрывается еще один из принципиальных недостатков java-технологии. Говоря о размере апплета, загружаемого к клиенту, Компания ╚Бифит╩ сознательно не касается валютной части, а ведь это немаловажно. На самом же деле, минимально необходимая среднему клиенту конфигурация содержит в себе, как минимум, 4 валютных документа, один свободный и один рублевый (не говоря уже о возможной необходимости ее расширения за счет внутренних требований банка по расширению номенклатуры услуг клиенту). А это значит, что, чтобы набрать всего 6 документов за один сеанс (такое часто случается), клиенту надо выкачать в общей сложности 2 апплета суммарного объема под 300 Кb. При этом сервис в интерфейсах заполнения валютных документов практически отсутствует, что вполне объяснимо требованиями к сокращению объема валютного java-апплета.

    Комментарий: Опять подтверждение ╚толстого╩ банк-клиента √ чем больше логики в коде √ тем больше сам код. Попытка его дробления только упрощает процесс закачки, но не уменьшает его. Что же касается производительности, то, можно посчитать, сколько надо ввести документов по 20Kb, чтобы покрыть разницу в 7Кb и загрузочный объем в 300Кb. Получается 300/(20-7) = 23 документа. Клиент, вводящий за один сеанс 23 документа является несомненно крупным и скорее всего имеет выделенную линию в интернет, поэтому, для него вопрос трафика не принципиален. Клиенту же мелкому и среднему использование iBank в плане трафика явно не выгодно. Также очевидна тупиковость реализации в java-технологии специальных форм банковских документов, то есть, расширения номенклатуры услуг клиенту. В силу опять-таки требований к снижению объема java-апплета невозможно увеличение логики и повышения сервиса в интерфесах √ чем проще интерфейс √ тем меньше объем java-апплета.

    С Уважением,
    Барсуков Дмитрий,
    начальник отдела продаж
    Компании "Банк'с Софт Системс".

  • #2
    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Барсуков Дмитрий
    web-технологии: в системе нет, как таковой, закачки логики ни для рублей, ни для валюты.[/quote]

    Посмотрев html-странички убеждаемся, что в них полным полно кода на JavaScript'е - это ли не закачка логики к клиенту?

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>На одной дискете клиента находятся как средства защиты, так и загрузочное меню в ActiveX (опционально). Из банка закачиваются только html-формы каждого документа.[/quote]

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

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>На один документ приходится примерно 20 Kb суммарного трафика клиента с банком (BS-Client).[/quote]

    Правильнее сказать "на каждый документ" по 20 Кбайт. И это очень оптимистично, когда 20Кбайт. А если клиент начинает листать справочник получателей? А если справочник назначения платежа? А справочник банков? А если неправильно указал реквизиты, и сервер откинул клиента назад? Еще одни 20Кбайт получается?

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

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>java-технологии (iBank): закачка рублевого апплета чуть более 100 Кb + весь цикл на одну платежку примерно 7Кb.[/quote]

    Есть два варианта √ загружать апплет каждый раз в начале работы или использовать SoftUpdate. Тогда закачивается только стартовая html-страничка, а CAB(JAR)-архив с апплетом берется из специального кэша Web-браузера. При этом JVM проверяет корректность ЭЦП разработчика под апплетом, и если была модернизация архива (например злоумышленником), апплет обновляется с сайта.

    В iBank▓е на самом деле весь цикл на создание платежки может быть еще меньше. Вплоть до 2 Кбайт.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Вот тут-то и окрывается еще один из принципиальных недостатков java-технологии. Говоря о размере апплета, загружаемого к клиенту, Компания ╚Бифит╩ сознательно не касается валютной части, а ведь это немаловажно. На самом же деле, минимально необходимая среднему клиенту конфигурация содержит в себе, как минимум, 4 валютных документа, один свободный и один рублевый (не говоря уже о возможной необходимости ее расширения за счет внутренних требований банка по расширению номенклатуры услуг клиенту). А это значит, что, чтобы набрать всего 6 документов за один сеанс (такое часто случается), клиенту надо выкачать в общей сложности 2 апплета суммарного объема под 300 Кb.[/quote]

    Очередное лукавство. Размер валютного апплета в районе 106 Кбайт. 109+106 никак не 300.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>То, что эти апплеты различны, суть просто попытка разработчика iBank-а ввести пользователя в заблуждение при покупке √ ведь от перемены мест слагаемых сумма-то не меняется.[/quote]

    Валюта и рубли в разных апплетах по одной простой причине √ развитие продукта. Если засунуть в валютный апплет платежку √ размер увеличится максимум на 10Кбайт. Но смысла делать это уже нет √ уже завершается iBank 2.

    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Комментарий: Опять подтверждение ╚толстого╩ банк-клиента √ чем больше логики в коде √ тем больше сам код. Попытка его дробления только упрощает процесс закачки, но не уменьшает его. Что же касается производительности, то, можно посчитать, сколько надо ввести документов по 20Kb, чтобы покрыть разницу в 7Кb и загрузочный объем в 300Кb. Получается 300/(20-7) = 23 документа. Клиент, вводящий за один сеанс 23 документа является несомненно крупным и скорее всего имеет выделенную линию в интернет, поэтому, для него вопрос трафика не принципиален. Клиенту же мелкому и среднему использование iBank в плане трафика явно не выгодно. Также очевидна тупиковость реализации в java-технологии специальных форм банковских документов, то есть, расширения номенклатуры услуг клиенту. В силу опять-таки требований к снижению объема java-апплета невозможно увеличение логики и повышения сервиса в интерфесах √ чем проще интерфейс √ тем меньше объем java-апплета.[/quote]

    Ну что можно ответить на такие ⌠теоретические расчеты■. По статистике в обычных банках из 100% документов 90% рубли и 10% валюта. Я не беру в расчет специализированные банки, где соотношение 50 на 50 (встречали и такие). Загрузка апплета в 100 Кбайт √ минута. Дальше √ идет обычная удобная работа. Так вот для пользователя лучше минуту подождать (или не ждать вообще при использовании SoftUpdate), и потом УДОБНО и ПРИВЫЧНО работать, чем ощущать себя тормозом, ожидая реакции системы на действия пользователя (загрузки очередной HTML-страницы в 10..15 Кбайт). Мы это уже прошли. БСС же пытается этот факт размазать цифрами. Вот и вся арифметика.

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

    С уважением, Репан Димитрий
    Компания "БИФИТ"
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

    Комментарий


    • #3
      Димитрий, а чем Вам, собственно, не нравится мой расчет. Это, в отличие от Ваших абстрактных высказываний, конкретный "язык цифр". Он как раз и показывает точку, где Ваше решение становится лучше нашего BS-Client (по суммарному трафику пользователя). Из него ясно видно, насколько близко к допустимой лежит область, где суммарно трафик BS-Client меньше.
      Кстати, только сейчас скачал с Вашего сайта рублевый (220 К) и Валютный (196К) апплеты. Получилось вообще более 400К.
      М.б., подскажете, как надо скачивать, чтобы получалось, как Вы говорите, 200К с небольшим.

      А из расчета (не буду повторяться и приводить его) следует, что, чтобы покрыть Ваш трафик при закачке апплетов и начать выигрывать по объему суммарного трафика на N документов у БСС, это число N должно равняться 23. Клиент, вводящий за один сеанс 23 документа является несомненно крупным и скорее всего имеет выделенную линию в интернет, поэтому, для него вопрос трафика не принципиален.
      Я сознательно говорю о суммарном трафике, в конечном счете пользователю важно - СКОЛЬКО времени (СУММАРНО) он потратил на ввод 23 документов в той или иной системе.

      Так что и с итоговой производительностью в iBank не все так гладко, как хотелось бы его разработчику.

      Что касается банка, тестирующего iBank, что ж, допускаю такой случай, как допускаю и обратный. Однако, цыплят по осени считают, как внедрит банк iBank, так и расскажете об этом.

      С Уважением,
      Барсуков Дмитрий,
      начальник отдела продаж
      Компании "Банк'с Софт Системс"


      Комментарий


      • #4
        BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Кстати, только сейчас скачал с Вашего сайта рублевый (220 К) и Валютный (196К) апплеты. Получилось вообще более 400К.[/quote]

        Для полноты картины, Барсуков Дмитрий, всё-таки стоило упомянуть, что Вы использовали Netscape Communicator. И уж если Вы большой специалист по безопасности и очень хорошо знакомы с технологией Java-апплетов, то должны знать, что размер JAR-архивов, в которых содержаться Java-апплеты, а именно они загружается в Netscape Communicator, всегда больше CAB-архивов.

        На самом деле на стенде лежат аплеты с отладочной информацией. Если Вы посмотрите дистрибутивы, то увидите, что размер файлов от версии 1.8 следующие:

        client.cab - 109375 байт (для MS IE)
        currency.cab - 103392 байта (для MS IE)
        client.jar - 213695 байт (для Netscape)
        currency.jar - 186528 байт (для Netscape)

        Хотите расчетов? Приведу свои расчеты.

        Типовой клиент, на предоставление услуг которому и ориентирован iBank - является мелкой или средней компанией, работющий на внутреннем российском рынке, официально не ведущей внешнеторговую деятельность и не имеющей валютных счетов. Таких клиентов в среднестатистическом банке около 75..80%. Документооборот таких клиентов как правило небольшой - до 10 платежек в день.

        При работе по iBank'у, при использовании MS IE и механизма SoftUpdate на создание, и подпись 10 платежек входящий трафик будет 74 Кбайта:
        стартовая html-страница client_su.html ~4Кбайт + создание и подпись 10 платежек ~70Кбайт.

        В случае с решением от БСС входящий трафик будет существенно выше, как минимум в два с половиной раза (10платежек * 20Кбайт). И даже при неиспользовании клиентов iBank'а механизма SoftUpdate, даже в этом случае iBank выигрывает. Но не в этом кроется производительность.

        Все цифры БСС и мною приведенные - условны, и совершенно никак не характеризуют производительность решения. Они характеризуют - удобство работы. Оно же заключается в скорости реакции интерфейса пользователя на действия клиента. Так вот, в случае iBank'а - прикладной запрос редко когда превышает 2 Кбайта, в основном ~1 Кбайта. И время его обработки 1..3 секунды. Выглядит и работает это на практике действительно быстро и комфортно.

        В случае же с Web-решением, при действии пользователя начинается перезагрузка очередной новой html-старницы, размер которой в случае БСС редко когда меньше 10Кбайт. На диалапе в реальных условиях это уже 8..12 секунд. Вроде как мелочь. Но попробуйте поработать. Попробуйте создать 15 платежек в обеих системах и все вопросы об удобстве будут полностью сняты. И не в пользу BS-Client'а.

        Я же предлагаю обсудить в этом топике именно производительность решений. Обсудить, как и предлагал Барсуков Дмитрий, масштабируемость и многоплатформенность серверной компоненты. Обсудить надежность и управляемость обеих решений. Рассказать о методах повышения производительности решений.

        В понедельник этим и постараюсь заняться

        С уважением, Репан Димитрий
        Компания "БИФИТ"
        С уважением, Репан Димитрий
        Компания "БИФИТ" - www.bifit.com

        Комментарий


        • #5
          Subj - а производительность чего ???

          А как же сравнение с учетом конфигурации клиентской машины ? К сожалению, я не тестировал iBank, но может проведете анализ скорости работы аплета на P133/32 ? Насколько комфортно будет работать, если запущен еще тот же ворд? насколько я знаю, java всегда отличалась прожорливостью, и softupdate под 95 тоже не работает. Да, в средних и мелких компаниях стоят именно такие машины.

          ------------------
          С уважением,
          Родион Вареников

          Комментарий


          • #6
            Уважаемый Родион Вареников!

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

            Если Вы возьмете Apache, то на хорошем PC он сможет обрабатывать пару сотен простых http-запросов, то есть отдавать в секунду до 200 статических html-страничек.

            Если Вы запустите под Apache'ем Web-приложение, реализованное например на CGI-скриптах (Perl), и будет предполагаться хоть какая-то более менее серьезная бизнес-логика с обращениями к Серверу БД, то производительность (количество обработанных http-запросов) уже существенно уменьшиться.

            Когда же Вы для защиты информации вместо протокола HTTP начнете использовать HTTP поверх SSL (https://...), то количество обрабатываемых запросов в секунду упадет еще в несколько раз.

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

            Именно криптография, интенсивно используемая в криптографических протоколах (таких как SSL), а если быть конкретно - процедура вычисления модульной экспоненты, на которой основана практически вся асимметричная криптография, съедает 95% процессорных ресурсов.

            Теперь обратим наш взор на Интернет-Банкинг, особенно для юрлиц. Условия к производительности и масштабируемости серверной части оказываются достаточно жесткими. Статистический анализ логов Серверов Приложений, которые работают в реальных банках и обслуживают реальных клиентов юрлиц, показывает, что 90% транзакций (запросов от клиента к серверу) приходится на промежуток от 11.00 до 14.00. То есть имеем три часа или ~11 тыс. секунд.

            Если говорить конкретно об iBank'е, то на одну платежку в среднем приходится чуть менее 8-ми транзакций. Сервер в конфигурации P-III 800Мгц + 256 Мб обрабатывает около 9 транзакций в секунду. Закладываясь, что среднестатистическая нагрузка на сервер не должна превышать 40% (чтобы оставался запас производительности для обслуживания пиков активности), получаем, что за указанный сервер сможет обработать около 4,5 тыс. платежек. Но на практике на этом сервер еще ставят и Сервер БД, и вспомогательный Web-сервер, который отдает стартовую страницу и Java-апплет через SSL, да и никто не доводит ситуацию и до 40% средней загруженности. Так что цифры получаются немного поменьше.

            Естественно, 4..5 тыс. документов в день не так много для серьезного банка. Соответственно есть и направления для повышения производительности сервеной части - установка более мощного железа (многопроцессорные ксеоны), установка криптографических ускорителей, переход на более производительную платформу (например SUN/Solaris), установка нескольких Серверов Приложения и использование в iBank'е механизма распределения нагрузки между серверами. Все эти методы позволяют постепенно наращивать общую производительность решения.

            Что касается производительности Java-апплетов под P133/32. Если у пользователя не открыто бубернадцать приложений, и ОС постоянно не свапует память, то и Java-апплет будет очень достойно работать, без каких-либо тормозов. На P133/32 будет только небольшая пауза при первичной инициализации Java-апплета в 7..10 секунд. На целероне 466 первичная инициализация апплета уже практически незаметна.

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

            С уважением, Репан Димитрий
            Компания "БИФИТ" - www.bifit.com
            С уважением, Репан Димитрий
            Компания "БИФИТ" - www.bifit.com

            Комментарий

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

            Свернуть

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

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