|
Home > Archive > BizTalk Server Orchestration > April 2004 > BTS 2004 - Orchestration Scalability
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BTS 2004 - Orchestration Scalability
|
|
| Andrew 2004-04-16, 5:41 am |
| Is there a way to limit the number of Orchestration Instances that can
execute concurrently?
I have a service that starts an orchestration. Requests to the service from
clients tend to come all at once, meaning that I will have no orchestrations
running for hours then have hundreds starting up all at once. I don't need
to be able to run all of them concurrently to give a split-second response.
I want to be able to set an upper bound on the number of orchestration
instances that can run concurrently. If I exceed this limit the others will
queued until a slot becomes available. In BizTalk 2002 you could do this
with Schedule Pooling.
This must be a common scenario. How will BizTalk cope with hundreds of
orchestrations being started concurrently, other than having unlimited
hardware resources - surely it will grind to a halt?
Any comments or clarification would be appreciated.
Andrew
| |
| Christof 2004-04-18, 10:53 am |
| hi andrew,
this is a common problem... and mainly shows up when you do synchronous
things within an orchestration instance. (Like calling .NET components
etc...) If you only use the default asynchronous messaging features of
BizTalk (the adapter framework), the problem is much less severe.
By default, BizTalk Server 2004 does not offer a mechanismn to do
throttling, like you could in 2002... Unfortunately. However, here is what
is done in some cases that really really need this:
- create a custom pipeline component that
- takes the message
- changes the context with a property called "resource number"
- fills in that property with a value between 1 and the maximum number
of concurrent orchestration instances
- you may choose to give that number at random, or do it round robin
- create a pipeline that includes that component
- create a "proxy dispatch orchestration"
- that receives messages in an endless convoy with its correlation set,
set to "resource number" (that property will always be present because your
pipeline makes sure its in there!)
- that sends the message to your real orchestration
Doing this, the maximum number of concurrent "proxy orchestration" instances
is being limited by the convoy. All messages that arrive while the convoy
is still processing your real orchestration are just being queued.
Hope this makes sense to you.
Kindest regards!!
Christof
"Andrew" <biztalkq@mail9.com> wrote in message
news:407fa3de$0$95313$65c69314@mercury.nildram.net...
> Is there a way to limit the number of Orchestration Instances that can
> execute concurrently?
>
> I have a service that starts an orchestration. Requests to the service
from
> clients tend to come all at once, meaning that I will have no
orchestrations
> running for hours then have hundreds starting up all at once. I don't need
> to be able to run all of them concurrently to give a split-second
response.
> I want to be able to set an upper bound on the number of orchestration
> instances that can run concurrently. If I exceed this limit the others
will
> queued until a slot becomes available. In BizTalk 2002 you could do this
> with Schedule Pooling.
>
> This must be a common scenario. How will BizTalk cope with hundreds of
> orchestrations being started concurrently, other than having unlimited
> hardware resources - surely it will grind to a halt?
>
> Any comments or clarification would be appreciated.
>
> Andrew
>
>
|
|
|
|
|