Hi,

does anyone know if Biztalk developer edition is limited in power.
We tried load testing it and we can only have 2 messages processed in parall
el.
Is is limited in the number of worker threads?
Thanks.

[ Post a follow-up to this message ]

Hello,



>does anyone know if Biztalk developer edition is limited in power.
>We tried load testing it and we can only have 2 messages processed in parallel.[/vb
col]
[vbcol=seagreen]
>Is is limited in the number of worker threads?

This page: http://www.microsoft.com/biztalk/howtobuy/pricing.asp indicates t
hat:

"BizTalk Server 2004 Developer Edition is limited solely to designing, devel
oping, and testing purposes. You may not use it as a passive failover
server or for disaster recovery."

Strictly speaking, you should be doing stress / performances testing on the 
version of BizTalk that you will use in production:
Standard, Partner or Enterprise.

Unfortunately, you do not describe your configuration (how much memory, proc
essors, operating system version ...) and you
do not also explain how messages are sent to your orchestration, how complex
 your orchestration is, how your application is designed ...
It is going to be hard to suggest possible ways to improve your application'
s throughput.

Are you by any chance testing under Windows XP and sending messages using HT
TP?
As you know, Windows XP has a limitation of 10 simultaneous HTTP connections
 and this might be limiting you.

Are you running SQL Server on the same machine? If so, remember that SQL, by
 default, will try to consume as much memory as possible
on the server to satisfy requests as fast as it can and this will indeed red
uce BizTalk's performances since BizTalk needs memory as well.

Thanks.
-Gilles.

[ Post a follow-up to this message ]

Thank you Gilles for the response.
We were trying to see how many simultaneous messages the server can take and
 I understand that we should do real stress testing on another Biztalk editi
on.
The server is on Windows 2000 service pack 4 with 700MHz CPU and 770 Mb RAM.
SQL is on the same machine, you are right.
We do not use orchestration but rather submit to channels.
Our test was sending 4 threads from a tool running on another machine on XP,
 to the web services we have developed (based on biztalk web services adapte
r).
When we look the performance the problem was not the memory but the CPU that
 was going to 100% when a message was going through.
I understand that we will have to separate SQL and Biztalk and use at least 
the Standard edition of Biztalk however I was wondering if the developer ver
sion was limited in power (which I would understand)?
Thanks for your help.

[ Post a follow-up to this message ]

Hello,

[...]

>The server is on Windows 2000 service pack 4 with 700MHz CPU and 770 Mb RAM. SQL is
 on the same machine, you are right.

Your machine meets and exceeds the official BizTalk minimum requirements. Ho
wever, on real production environments, 1Go of RAM
is strongly suggested.

>When we look the performance the problem was not the memory but the CPU that was go
ing to 100% when a message was going through.


I am sure you already observer the relevant perf counters when your solution
 runs. If anyone here reads this message and wonders what I meant,
I'll outline them quickly. You should observe who is using the CPU, you shou
ld use the perf counters to see the IO disk Queue and the SQL activity.
Paging is also important. On a server paging is death. This should be observ
ed when the message gets through since it seems that this is
when you see the point of contention.

>I understand that we will have to separate SQL and Biztalk and use at least
 the Standard edition of Biztalk however I was wondering if the developer
>version was limited in power (which I would understand)?


To the best of my knowledge, the developper edition does not have hardcoded 
limitations on the number of messages.
It seems that your solution is CPU bound and moving the solution to a faster
 machine would give you better results.
However, without accessing the perf counters on the machine, I can only give
 suggestions.

Thanks a lot.
-Gilles.

[ Post a follow-up to this message ]

Also keep in mind that your client machine, if it is running a .net
application, will be limited to two concurrent connections to your biztalk
server over HTTP.  See the following article for more information on this
and how to fix it:

PRB: Contention, Poor Performance, and Deadlocks When You Make Web Service
Requests from ASP.NET Applications

http://support.microsoft.com/defaul...kb;en-us;821268



At Your Service: Performance Considerations for Making Web Service Calls
from ASPX Pages

http://msdn.microsoft.com/webservic...ice07222003.asp




Matt
"Gilles [MSFT]" <Gilles@online.microsoft.com> wrote in message
news:6RBqON2PEHA.2296@cpmsftngxa10.phx.gbl...
> Hello,
>
> [...]
> 
RAM. SQL is on the same machine, you are right.[vbcol=seagreen]
>
> Your machine meets and exceeds the official BizTalk minimum requirements.
However, on real production environments, 1Go of RAM
> is strongly suggested.
> 
that was going to 100% when a message was going through.[vbcol=seagreen]
>
>
> I am sure you already observer the relevant perf counters when your
solution runs. If anyone here reads this message and wonders what I meant,
> I'll outline them quickly. You should observe who is using the CPU, you
should use the perf counters to see the IO disk Queue and the SQL activity.
> Paging is also important. On a server paging is death. This should be
observed when the message gets through since it seems that this is
> when you see the point of contention.
> 
least the Standard edition of Biztalk however I was wondering if the
developer[vbcol=seagreen] 
>
>
> To the best of my knowledge, the developper edition does not have
hardcoded limitations on the number of messages.
> It seems that your solution is CPU bound and moving the solution to a
faster machine would give you better results.
> However, without accessing the perf counters on the machine, I can only
give suggestions.
>
> Thanks a lot.
> -Gilles.
>

[ Post a follow-up to this message ]