Я рассматриваю предложения о том, как решить эту проблему и использую ли я подходящий инструмент для работы. Я работаю в основном над BizTalk, и в настоящее время мы используем BizTalk 2013 R2 с SQL 2014.
Проблема:
Мы будем получать позиционные плоские файлы каждый день (около 50) от различных партнеров, и теоретическое общее количество полученных записей будет более миллиона записей. Каждая запись содержит некоторую идентифицирующую информацию, которую нужно будет отправить в веб-службу, которая вернется, по существу, с ДА или НЕТ, в зависимости от того, что входящий файл будет разделен на два файла.
Первоначально объем ежедневных ожидаемых записей составлял 10 тыс., Который позже увеличился до 100 тыс. И теперь составляет миллион записей.
Попытка 1: паттерн Scatter-Gather
Я дебатирую записи в настраиваемом конвейере с помощью дизассемблера файлов, добавляя пару настраиваемых свойств порта для части разброса (следуя предложению Ричарда Серотера о реализации циклического присваивания), где я контролирую количество запускаемых мной оркестровок разброса / рабочих вверх, чтобы вызвать веб-службу и пометить записи для отправки в «Агентство A» или «Агентство B» и, наконец, отправить управляющее сообщение, которое запускает оркестровку Gather / Aggregator, которая собирает все сообщения, которые обрабатываются от рабочих, в messagebox через корреляцию и создает два файла, которые направляются в агентство A и агентство B.
Таким образом, каждый удаляемый файл будет иметь собственный набор рабочих процессов и агрегатор, который будет обрабатывать файл.
Это хорошо работает для файлов с меньшим количеством записей, но если файл содержит более 100 тыс. Записей, я вижу, что происходит регулирование, и файл занимает много времени для обработки и создания двух файлов.
Я поместил порт приема / рабочего и агрегатора / отправки на отдельные хосты. Похоже, что сборщик, кажется, обезвоживается и на самом деле не агрегирует записи, обрабатываемые рабочими, пока все они не будут обработаны, и я думаю, поскольку соотношение опубликованных и обработанных сообщений очень велико, оно дросселируется.
Подход 2:
Предполагая, что узким местом является оркестровка агрегатора, вместо того, чтобы накапливать их в оркестровке, я отправил обработанные записи в базу данных SQL и `` разделил '' записи на два файла XML (в основном конкатенация сообщений, идущих в агентство A / B и это в объявлении XML и с использованием правильного типа сообщения, основанного на записи некоторых свойств контекста в таблицу SQL вместе с записью). Эти агрегированные XML-записи опрашиваются и направляются в нужные агентства.
Кажется, это нормально работает с 100 тыс. Записей и выполняется за приемлемое время. Теперь, когда цель / требование снова изменились в отношении ожидаемого объема, я пытаюсь понять, является ли BizTalk еще более целесообразным выбором.
Я указал, что BT не является подходящим инструментом для выполнения такой задачи, но клиент предлагает нам добавить больше серверов, чтобы заставить его работать. Я смотрю на SSIS.
Между тем, пока мы проводим некоторое тестирование, некоторые наблюдения:
- Увеличение количества воркеров улучшило обработку (да): похоже, если каждый воркер обработал меньшее количество записей в своей очереди / подписке, они быстро завершили свою очередь. При тестировании этого файла с записью 100 КБ с использованием 100 рабочих процессов, завершенных менее чем за 3 часа. Это при минимальной активности на сервере со стороны других приложений. Я пытаюсь заставить команду хостинга веб-сервисов дать мне теоретический максимум одновременного подключения, которое они могут обработать. Я склоняюсь к тому, чтобы попросить их посмотреть, смогут ли они обработать 1000 вызовов, и, возможно, существующее решение будет масштабироваться с моими наблюдениями.
Я скорректировал несколько настроек хоста в отношении количества сообщений и порога физической памяти, чтобы он не отказывался от объема, но я все еще не уверен. Раньше мне не приходилось возиться с этими настройками, и я могу воспользоваться советами для отслеживания каких-либо конкретных счетчиков.
Сообщение немного длинное, но я надеюсь, что он дает представление о том, что я делал до сих пор. Любая помощь / понимание приветствуются в решении этой проблемы. Если вы предлагаете альтернативы, я ограничен инструментами / фреймворками на основе .NET или MS, но хотел бы услышать и о других вариантах.
Я постараюсь ответить или дать более подробную информацию, если вы хотите уточнить или понять то, что я не разъяснил.
