Добрый день, коллеги.

Поставлена задача определиться с требованиями под SAP Process Integration систему.
Вводные данные:
"будет генерироваться 2 сообщения в 30 мин, каждое примерно по 350МБ".

Хотел узнать ваше мнение. Достаточным ли будет сервер SAPS = 33000. 2 процессора по 8 ядер каждый и 96Гб ОЗУ?
Будет использоваться 3-х системный ландшафт.
1 сервер = DEV + QAS
2 сервер = PRD

p.s. При выполнении сайзинга через service.sap.com ругнулось на размер пакета в 350Мб. Лимит установлен в 100Мб.

по моему такой конфиграции должно хватить. у нас вроде 9000 сапс и памяти порядка 30гб - по числу ядер сейчас сказать не могу - завтра если надо - в день без напряга 100 000 сообщений.
еще надо с дисками осторожней - каждое сообщение если будет сохранятся - храниться до 9 копий - на каждом шаге трубы

но с большими сообщениями может быть проблема - теоретически должно работать с 2 гб собщения - но при парсинге сообщения для маппинга обычный jdbc ответ увеличивается раза в 3 - при преобразовании в xml. и времени на 50мб тратилось порядка 30сек. бывало что при переборе с размером java падала - пришлось ограничивать принудительно параметрами интеграционной шины.

Спасибо за ответ.
В SAP гайдах пишут, что оптимальный размер сообщений от 1 до 5 мб. Для производительности лучше.
Хотя у нас в требованиях 350Мб, не уверен корректны ли вообще эти требования и можно ли снизить размер до рекомендованных.

Еще вопрос

Трафик от АСКУЭ на 30т.точек равен 1,5Гб в час.
Целевой объем 250т.точек. Получаем 12гб в час.

Реально ли обработать такой объем сервером в 33000 SAPS.

Какой у Вас обрабатываемый объем?

Вообще как рекомендуют в http://scn.sap.com/docs/DOC-3856 для большого объема лучше использовать BO DS. ПО моему разумению хорошо бы подошел бы SAP xMII - но почему то SAP его не продвигает.

текущий трафик у нас небольшой до 5 ГБ в сутки - недавно оптимизировали чтоб спалось спокойней.
А если по существу если данные будет пихаться в ERP через AMI то проще будет без PI. В принципе PI должен справиться.

Сейчас попробую запросы поделать на 50мб в несколько потоков. Напишу чуть позже

Тестирование - почти нагрузочное.
ну вообщем систему которая слала бы много в PI сходу нее придумал.
сценарий был такой: soupUI по XI лез в PI и дельше в JDBC в базу данных за данными и возвращалось все в soupUI - маппинг только входной - выхходного нет т.к. принципиальна была скорость. Работали полчаса в 4-10 потоков. Дали 1.5 ГБ трафика. База отвечала неохотно из которой читали. Все это плюсом к текущей нагрузке.
Конфигурация системы 2 инстрации по 8 ядер и 36гб памяти (примерно) - на каждой инстанции по 2 java ноды. САПсов вроде как на всю систему 12000 - это не точная информация.
ЦПУ поднялось до 50% примерно с 30%. Еще потолок сконфигурирован на JDBC канале в 10 параллелей и таймаут на 1 минуту и общий по системе размер сообщения в 100мб.

А дальше надо думать - если система которая принимает сообщения сможет обрабатывать 12ГБ в час то можно попробовать сконфигурировать PI . Тут зависит еще от того как поступать будет информация и как отдаваться из PI если все по xi каналам это легче для PI если еще каналы на входе и выходе то дополнительная нагрузка и геморой с java.

Можно попробовать - по ощущениям должно пролезть 12ГБ в час много но ...

Ок, спасибо за информацию. Картина более-менее стала ясна.