Поиск

Про производительность процессинга

07.10.2010 от Andrew

Разные компании проводят стресс-тестирование на топовых платформах и поражают мир заверением, что их процессинговая система способна выдержать тысячи транзакций в секунду – только налетай и покупай и далее не парься по поводу роста бизнеса. А что ж на деле?

Дабы избежать возможных претензий, а также не раскрывать источники интимных данных не буду называть вещи своими именами – обойдемся пвсевдонимами и намеками. Кто понимаент – догадается. Кто не понимает – тому и не нужно.

Имеем крупнейший банк, который использует в своей процессинговой инфраструктуре два решения:

  • решение S, для управления устройствами и маршрутизации транзакций (свич)
  • решение W, в качестве авторизующего карточного бэк-офиса (авторизация с продуктовой логикой и бухучетом)

в пиковые моменты, под Новый год, на системе S фиксирует чуть больше 300 авторизацией в секунду (TPS), а на системе W всего порядка 130 и как раз эта система регулярно затыкается!!!

Много это или мало? Может на железе экономят?

Мои источники в банке утверждают, что используют под систему W самый большой Superdom, который только смогла создать компания HP и “больше просто нет, а компания HP сейчас разрабатывает для нас новый супер-мощный процессор”. А вот вендор системы W, утверждает в своих презентациях, что его система переваривает “3,000 бизнес-тразакций в секунду!”.

Между 3,000 и 130 разница таки на порядок с лишим! У меня она в мозгу не укладывается. Все-таки крупнейший банк страны на жмота не похож и если надо – купит любое железо.

Общался по случаю с представительницей вендора W и получил следующее разъяснение “официальные тесты опубликованы на сайте”, на вопрос “что такое бизнес-транзакции” был получен ответ “бизнес-транзакция это любая клиентская транзакция, в частности снятие наличных, со всеми проверками, включая криптографию, лимиты и урегулированию по счету”. На вопрос “а почему же в крупнейшем банке топовое железо едва справляется с объемами в 10 раз меньше” был получен сакраментальный ответ “надо верить официальным тестам на сайте, а про банк ничего сказать не могу -, наверное, наговаривают люди”, одновременно удалось узнать, что “вообще-то 3000 TPS, это в режиме свича, а врежиме авторизатора только 1100 TPS”. Но 1100 и 130 это все равно различие на порядок!

“Есть ложь, наглая ложь и советская статистика”, ой “маркетинговая информация”… как-то так видимо получается. Вообщем, не обманешь – не продашь…

Рубрики: Банковские карты | 3 комментария »»»

3 комментария

  1. Gor пишет:

    Архитектура системы W изначально несет проблемы производительности для организаций с большей эмиссией, так для авторизаций и операционной деятельности, фин. учета и т.д используется одна база данных.Что приводит к смешанным нагрузкам. Очень трудно (читай невозможно) оптимизировать систему под различные типы нагрузок одновременно. Это не так критично для не большой эмиссии и становиться проблемой при увеличении объемов эмиссии. В данном конкретном случаи даже ОЧЕНЬ большой сервер не решит проблем, так как процессорная мощность не является узким местом.

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

  2. AndreiP пишет:

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

    Большинство производителей систем не могут себе позволить мега-конфигурации, которые могу иметь некоторые Сбе^H^H^Hбанки…

  3. Crew cut пишет:

    Большая маркетинговая фикция все эти TPS, это тестируется ВНОВЬ созданная ОС, ВНОВЬ созданная База Данных и чистое приложение.
    Если говорить про ХОСТОВОЙ приклад то это стандартно настроенные какие-то лимиты, алгоритмы…
    В реальной эксплуатации через год ОС уже не так работает когда была чистой, так как накачено много обновлений, не так работает База Данных(табличное пространство не структурировано и БД давно уже не администрировалось), в приложение уже навешали кучу всяких лимитов, алгоритмов, отчетов возможно весь этот винегрет и зоопарк не оптимально написан.
    Естественно объединять ХОСТ и бэк-офис нельзя потому как одна транзакционная система, а другая батчевая система, не один разработчик не сможет нивелировать этот процесс, т.к. это архитектурное ограничение СУБД Oracle, грамотный администратор Баз Данных подтвердит.

Вставить свои 5 копеек:

Заметьте: Включена проверка комментариев. Нет смысла повторно отправлять комментарий.