Reduce the speed of entering the BizTalk login file
We have a BizTalk 2010 receiving location that will receive a 70MB file and then use an incoming card (at the receiving location) and an outgoing card (at the sending port) to create a 1GB file.
SQL Server consumes a lot of disk I / O during the above process. Another performance issue with the processing of received locations is highly dependent.
We tried to reduce the maximum disk I / O flows in the host instance of this receiving location, but it still consumes a lot of disk I / O resources in SQL Server.
In fact, this process priority is very low. Is there a way to reduce the disk I / O usage of this process so that the performance of other processes is normal?
source to share
This issue is not related to the speed of file input, but as you noted in the comment, to the load that is placed in the message box when trying to save the 1gb map output to the MessageBox. You have several options to try to minimize the impact this will have on other processes:
- Adjust the throttling settings on the newly created host to something very low. It may or may not work the way you want it to.
- Install a service window in the location you receive for these files so that they only work outside of business hours. This would be ideal if you don't have 24/7 demand for the MessageBox and can afford slow response times in the middle of the night (say 2-3 a.m.).
- If your requirements can handle this, don't map the file on the receive port, but forward it to the Orchestration component and / or a custom pipeline that breaks it down into smaller chunks and then displays smaller chunks. This should at least give you finer grained control of the speed at which they are processed (in the form of a loop delay that processes the chunks). There might be problems when you join them together, but it shouldn't be as bad as your current process.
It might also be worth taking a look at your map. If there are a lot of slow / heavy heavy calls you can reorganize it.
source to share
Ideally, you should undo the file. Apply the business logic including the map on each individual shard and then load them into sql one at a time. Later, you can use a pipeline or some other .NET component to retrieve data from SQL and return data. Processing large xml (10x the size of a flat file) in a BizTalk blog post is not good practice. If, however, it was a pure messaging scenario, you can stream the file and redirect it to its destination.
source to share