BizTalk中的每個應用程序是否都有自己的主機實例/主機實例?應該每個應用程序都有自己的主機實例/主機實例嗎?
我讀過各種博客文章和書籍,對於不同的任務有不同的主機實例是很好的做法,例如一個用於接收,一個用於發送,一個用於編排,另一個用於跟蹤。
但是,每個應用程序都應該獲得自己的接收,發送,編排和跟蹤主機?還是僅僅是所有應用程序中的一個?
BizTalk中的每個應用程序是否都有自己的主機實例/主機實例?應該每個應用程序都有自己的主機實例/主機實例嗎?
我讀過各種博客文章和書籍,對於不同的任務有不同的主機實例是很好的做法,例如一個用於接收,一個用於發送,一個用於編排,另一個用於跟蹤。
但是,每個應用程序都應該獲得自己的接收,發送,編排和跟蹤主機?還是僅僅是所有應用程序中的一個?
簡短回答,除非該應用程序的某個方面導致其他應用程序的性能問題,否則可能不會。如果是這種情況,您只會爲造成問題的特定部分創建主機。例如如果它是接收適配器,您將爲在該適配器下運行的接收位置創建主機。如果它是該應用程序的Orchestrations,則爲該應用程序創建一個處理主機,以便該應用程序的Orchestrations在其下運行。
朗答案從微軟 High Availability for BizTalk Hosts
缺點額外的主機
雖然有創建額外的主機實例的利益,也有潛在的缺陷,如果創建太多主機實例。每個主機實例都是一個Windows服務(BTSNTSvc.exe或BTSNTSvc64.exe),它會針對MessageBox數據庫產生額外的負載並消耗計算機資源,如CPU,內存和線程。除了這些,您有以下原因沒有配置太多額外的主機實例:
幾個性能計數器每個主機報道了太多的粒度。這會影響需要遍歷大量數據的管理員的可用性。這對管理員的整體視圖有負面影響。
每個主機都會消耗相當數量的內存,這可能會導致節流和性能下降。
如果主機接收到連續執行輪詢的適配器,則每個主機都會以很短的間隔輪詢數據庫,從而導致性能下降。
正如你所讀,沒有明確的規則。
應該每個應用程序都有一個專用主機/實例嗎?當然,如果你有相對較少的硬件應用程序。
如果某個應用程序存在問題,還需要考慮這一點。
應該每個應用程序有不同的Receive,Send或Orch主機嗎?不,不開始。如果你觀察到一個特殊的操作需要消耗大量的資源,那麼就把它分開。
有一個有趣的博客文章對100個主機的影響... http://blogical.se/blogs/johan/archive/2013/12/06/can-i-have-100-的BizTalk服務器宿主instances.aspx?CommentPosted =真#commentmessage – SteveC