Hi Gaurav
I've mentioned in my reply on my blog to let us know what is the receiver adapter type for these scenarios. Is it some file based adapter, i.e. File, FTP, SFTP?
From the description of your issue, I don't think the problem is with the IDoc sender side. ICO processing are completely done on the sender adapter's worker thread side so it might have given a false impression that the issue is at the sender.
If the bottleneck is at the IDoc sender, the messages would not even be in your PI system yet, there would instead be a backlog on the source ABAP system (backlog can be seen in t-code SM58).
Since the messages are already in PI's messaging system, the backlog in scheduled status indicates that it is due to bottleneck on the receiver side. It is a case of sender system sending volume of messages that is more than the receiver system is capable of handling. Read up the whole of section 6.2 of the performance check document.
In general I think there is not much you can do since this is a one-off activity. Unless there is a way for the receiving system to increase the speed at which it processes the messages PI sends to it.
Regarding the maxReceiver settings, note that this will not help the throughput of these 10 IDoc interfaces, i.e. changing it will not speed up processing of these interfaces since the limitation is due to the receiver system. What maxReceiver does it to prevent slow processing of any one interface from blocking all other interfaces that are running in PI that uses IDoc sender adapter.
Rgds
Eng Swee
PS: Hope this helps. I'll be away so won't be able to answer any further queries on this.