Отправка больших байтовых массивов между доменами приложений в одном процессе - PullRequest
9 голосов
/ 04 мая 2009

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

  1. Считать полезную нагрузку из сокета в байтовый массив и упорядочить его.
  2. Маршал сетевой поток (наследуется от MarshalByRef) в домен приложений.
  3. Прочитайте полезную нагрузку. Расшифруйте это в объекты. Маршал декодированных объектов.
  4. Используйте именованные каналы для передачи байтового массива.
  5. Используйте петлевые розетки.
  6. Может быть, есть способ упорядочить фактическое сокетное соединение?

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

Метод должен отдавать предпочтение меньшему объему памяти, чем меньшему количеству ЦП.

WCF не вариант.

Ответы [ 4 ]

1 голос
/ 12 мая 2009

6. Может быть, есть способ упорядочить фактическое соединение сокета?

6-й - ИМО лучший вариант. Сокет с точки зрения процесса - это просто ручка. Домены приложений находятся в одном процессе. Это означает, что домены приложений могут обмениваться дескрипторами сокетов.

Если сортировка сокетов не работает, вы можете попробовать воссоздать сокет в другом домене приложения. Вы можете использовать DuplicateAndClose для этого.

Если это не сработает, вам следует провести тестирование производительности, чтобы выбрать лучший метод передачи данных. (Я бы выбрал именованные каналы или файлы, отображенные в memomry)

1 голос
/ 04 мая 2009

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

На самом деле Cassini был заменен Webhost, который является встроенным веб-сервером, который теперь поставляется с Visual Studio. Взгляните на этот пост в блоге Фила Хаака, чтобы узнать больше.

1 голос
/ 04 мая 2009

Очень хороший вопрос. Если бы я столкнулся с этой проблемой, я бы, вероятно, использовал бы Buffered Stream / Memory Stream и перенаправил поток в AppDomain, который потребляет объект, чтобы уменьшить маршалинг или сериализацию многих графов объектов, которые были созданы в другом AppDomain.

Но, опять же, похоже, что вы почти полностью дублируете функциональность IIS, так что я бы заглянул / отразил в пространство имен System.Web.Hosting и увидел, как они справляются с этим, их WorkerThreadPool и т. Д. ...

1 голос
/ 04 мая 2009

Двоичное удаленное TCP-соединение, безусловно, быстро, я не знаю, насколько оно быстрее, чем raw-сокеты, что, вероятно, самая быстрая, но королевская PIA.

Я выполнил 1500 - 2000 запросов в секунду в производственном процессе, используя двоичное HTTP-удаленное взаимодействие между двумя блоками. В той же коробке вы должны иметь высокую производительность при использовании TCP или канала именных каналов, в зависимости от циклов ЦП, необходимых для обработки данных.

...