|
Home > Archive > BizTalk Server General > June 2005 > BizTalk 2004 :: HTTP req-resp :: loopback checkbox with slow performance
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 |
BizTalk 2004 :: HTTP req-resp :: loopback checkbox with slow performance
|
|
|
|
Hi All,
I'm having trouble with the loopback feature of an HTTP
request-response operation.
My orchestration is super simple... recv HTTP xml message and dump it
in a database table. I want to accept the message and immediately
release the user.
My assumption is that the lookback checkbox (where you configure the
port) would provide an instant response. Its not, on average its
taking 1.2 - 1.8 seconds, which to my client is an eternity for such
functionality.
Am I missing the purpose of the loopback? Why is it so slow in
response? I am getting the impression maybe its waiting for the
orchestration to finish and then "loopback", so "loopback" then sort of
means "wait until I'm dont and I will send back the original message"
-- is that what is really happening?
Thanks,
BA
| |
| Scott Colestock 2005-06-21, 5:50 pm |
| The Loopback option allows you do execute maps/pipelines and get a response
with no send port or orchestration subscription present - it isn't related
to performance.
Have you considered a one-way receive port? It sounds like you only need
the http 202 (message accepted.)
Scott Colestock
www.traceofthought.net
"BA" <biztalk.architect@gmail.com> wrote in message
news:1119361486.974193.66180@g44g2000cwa.googlegroups.com...
>
> Hi All,
>
> I'm having trouble with the loopback feature of an HTTP
> request-response operation.
>
> My orchestration is super simple... recv HTTP xml message and dump it
> in a database table. I want to accept the message and immediately
> release the user.
>
> My assumption is that the lookback checkbox (where you configure the
> port) would provide an instant response. Its not, on average its
> taking 1.2 - 1.8 seconds, which to my client is an eternity for such
> functionality.
>
> Am I missing the purpose of the loopback? Why is it so slow in
> response? I am getting the impression maybe its waiting for the
> orchestration to finish and then "loopback", so "loopback" then sort of
> means "wait until I'm dont and I will send back the original message"
> -- is that what is really happening?
>
>
> Thanks,
>
> BA
>
| |
|
|
Scott,
I think I understand what you mean, but I dont see the configuration
for it. I have already setup a receive (only), and I dont see any
option for getting the 202.
What do you have to do to achieve what you mean?
Thanks,
BA
Scott Colestock wrote:[vbcol=seagreen]
> The Loopback option allows you do execute maps/pipelines and get a response
> with no send port or orchestration subscription present - it isn't related
> to performance.
>
> Have you considered a one-way receive port? It sounds like you only need
> the http 202 (message accepted.)
>
> Scott Colestock
> www.traceofthought.net
>
> "BA" <biztalk.architect@gmail.com> wrote in message
> news:1119361486.974193.66180@g44g2000cwa.googlegroups.com...
| |
| Scott Colestock 2005-06-22, 2:49 am |
| When you initially create a receive port, you can choose a static one-way
port.
HTTP receive locations will implement this by returning an HTTP 202 (message
accepted) if the message makes it to the messagebox.
Scott Colestock
"BA" <biztalk.architect@gmail.com> wrote in message
news:1119371910.846017.197620@g47g2000cwa.googlegroups.com...
>
> Scott,
>
> I think I understand what you mean, but I dont see the configuration
> for it. I have already setup a receive (only), and I dont see any
> option for getting the 202.
>
> What do you have to do to achieve what you mean?
>
> Thanks,
>
> BA
>
>
>
> Scott Colestock wrote:
>
| |
|
|
Hi Scott,
So, basically, I just need to remove the loopback checkbox and it
should work ok.
I'll try that and see.
Thanks,
BA
Scott Colestock wrote:[vbcol=seagreen]
> When you initially create a receive port, you can choose a static one-way
> port.
> HTTP receive locations will implement this by returning an HTTP 202 (message
> accepted) if the message makes it to the messagebox.
>
> Scott Colestock
>
> "BA" <biztalk.architect@gmail.com> wrote in message
> news:1119371910.846017.197620@g47g2000cwa.googlegroups.com...
| |
|
|
Hey Scott,
I removed the checkbox on the loopback, which now gives a 202 response
as you mentioned in your post.
Unfortunately I still have a performance problem, the service still
takes 1.5 seconds to give a 202 response.
I had the network admin check the IIS config and he reports it as fine.
Do you, or anyone, have any idea what might be causing this long delay
in responding?
Thanks,
BA
BA wrote:[vbcol=seagreen]
> Hi Scott,
>
> So, basically, I just need to remove the loopback checkbox and it
> should work ok.
>
> I'll try that and see.
>
> Thanks,
>
> BA
>
>
> Scott Colestock wrote:
| |
|
| Update:
I've tried the app on a second, faster computer, with no noticable
improvement in speed
BA
"BA" <biztalk.architect@gmail.com> wrote in message
news:1119532059.899748.249260@g14g2000cwa.googlegroups.com...
>
> Hey Scott,
>
> I removed the checkbox on the loopback, which now gives a 202 response
> as you mentioned in your post.
>
> Unfortunately I still have a performance problem, the service still
> takes 1.5 seconds to give a 202 response.
>
> I had the network admin check the IIS config and he reports it as fine.
>
> Do you, or anyone, have any idea what might be causing this long delay
> in responding?
>
> Thanks,
> BA
>
>
>
> BA wrote:
>
|
|
|
|
|