.NET WebService IPC - должно ли это быть сделано, чтобы минимизировать некоторые дорогостоящие операции? - PullRequest
0 голосов
/ 10 мая 2010

Я смотрю на несколько разных подходов к проблеме: клиентские запросы работают, некоторые вещи выполняются, и возвращается результат (ok / error).

Веб-сервис .NET определенно выглядит как путь, моя единственная проблема в том, что «материал» будет включать в себя создание и отключение сессии для каждого запроса. Является ли абстракция «материала» приложению (которое будет поддерживать активную отдельную сессию и обрабатывает запрос от веб-службы) как правильный путь? (и если да, то какой способ связи)

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

Является ли здесь какая-либо форма IPC или сокетной связи возможным решением?

Мысли / комментарии / опыт очень ценятся.

Edit: После небольшого исследования кажется, что размещение службы WCF в службе Windows, вероятно, является лучшим способом ...

1 Ответ

1 голос
/ 10 мая 2010

ну вот и мы:

  • Не устанавливайте новый канал связи для каждого запроса. На стороне клиента / на стороне сервера используются реализации WCF и убедитесь, что клиент не получает новый прокси-сервер для каждого вызова;) Особенно с настройкой канала HTTPS стоит дорого.

  • Не звоните в сервис;) Просто: сделайте как можно меньше звонков. Имейте грубый интерфейс, оптимизированный для того, чтобы не делать много звонков. Разрешить группирование результатов. Например, «GetInvoice» может быть «GetDocuments» - возвращать не только счет, а брать несколько идентификаторов, возвращать несколько документов. Список из 30 счетов-фактур превращается из 30 вызовов в 1. В противном случае может работать подход с использованием шины обмена сообщениями - я использую один такой и транспортирую до 1024 сообщений за вызов.

  • Старайтесь не использовать веб-сервис, если у вас тонна нагрузки. Используйте привязку WCF и NetTcp (которая является двоичной и не использует HTTP, поэтому она не является веб-службой). Затраты HTTP огромны - посмотрите в Google, кто-то сделал тест, и мы говорим, что net tcp иногда работает примерно в 900 раз быстрее. Особенно, если вы мало работаете и потеряли пользователей, это может увеличить масштабируемость. Отрицательный - вы только WCF-совместимый на стороне клиента, больше не «веб-службы».

Это почти все, что вы можете сделать. С разными потерями, но это как повысить производительность;) Если вы говорите о чисто IPC, рассмотрите возможность использования именованных каналов, даже net.tcp - именованные каналы не очень эффективны (используют общую память между процессами), но ограничены тем же машина в реализации .NET.

...