|
Home > Archive > BizTalk Server General > May 2004 > Developer edition 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 |
Developer edition performance
|
|
| Rastko 2004-05-20, 5:42 pm |
| 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 parallel.
Is is limited in the number of worker threads?
Thanks.
| |
| Gilles [MSFT] 2004-05-20, 5:42 pm |
| 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.
>Is is limited in the number of worker threads?
This page: http://www.microsoft.com/biztalk/howtobuy/pricing.asp indicates that:
"BizTalk Server 2004 Developer Edition is limited solely to designing, developing, 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, processors, 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 HTTP?
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 reduce BizTalk's performances since BizTalk needs memory as well.
Thanks.
-Gilles.
| |
| Rastko 2004-05-21, 2:52 am |
| 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 edition.
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 adapter).
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 version was limited in power (which I would understand)?
Thanks for your help.
| |
| Gilles [MSFT] 2004-05-21, 5:55 pm |
| 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. However, 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 going 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 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.
>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.
| |
| Matt Milner 2004-05-21, 5:55 pm |
| 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.
>
|
|
|
|
|