Choosing the right Host-Instance for BizTalk artifact (like a send port) is one of the basics to a successful project. This is one of the points where development and test/prod environment are so different.
Scenario 1:
All BizTalk Host-Instances queues have a table under MsgBobDb with the prefix:<HostName>Q. when the adapter is committing a message into BizTalk MsgBox it means that the message was committed into this queue. afterwards a process of de-queue will be fired. just imagine what will happened if you have two services one is batch process with thousands of messages, and the second is on-line. the first process will flow the queue and the second on-line process will suffer from badly performance (and not like Message queuing like WMQ and MSMQ there's no way to configure priority within BizTalk queuing).
Scenario 2:
If I have two BizTalk Servers with one MsgBox (this usually increase performance), I need to run a Receive Location or Send Port on one of those Servers - the only way is to create separated Host Instances - one on each server and then to configure the port to be hosted within the correct Host Instance.
Scenario 3:
We need to collect files from a directory, then we need to send the content of the files to a web-service. The web-service processing is taking a long time - mach more then collecting the files from a file-system directory. the results of this is that while BizTalk is busy to commit the incoming messages into the MsgBox the Send process is waiting. also, if the incoming messages are very big - the processing is likely to use a lot of the BTSNTSvc process free memory and the sending process will wait to this memory to be freed before processing.
Scenario 4:
The Send Port must run under specific user to grand access permissions.
