BizTalk Server - Deployment Recommendations

Author

Deployment Recommendations

jss

2004-06-11, 5:43 pm

Hi,

We are looking at creating a new environment to support Biztalk 2004. We will be starting with just one process that will take an xml message (from an MQSeries queue) go into Biztalk and map it to a flat file positional file and send it to an AS/400 syst
em. Conversely, it will map the flat file into an xml file as an acknowledgement. We expect to start with an initial volume of 70,000 messages back and forth with an average size of 5 KB. We do not intend to use orchestrations for this first deploy
ment. Would it be feasible to install the Biztalk components and corresponding databases on one server? From your expriences, what is the minimal system requirements for it to run without a performance degradation. Can the databases be installed on an
other SQL server that currently is being used by several other unrelated databases?

At some point, other processes will most likely be integrated into this platform. So, one thought was to start with one Biztalk server and then break out the databases as needed. Would that work?

Any thoughts from your experiences would be appreciated.

Jeannette

Michael Roze [MSFTF]

2004-06-11, 6:13 pm

A1

Short answer. Yes BizTalk can be setup to run on a single machine with SQL
configured locally.
Long answer. It is highly recommended to install the databases on a dedictd
SQL server.
The reason for this is because the databases are fairly resource intensive.
This can contend with the BizTalk Host Instances [BTSNTSvc
Receiving/Transmitting/Tracking] for CPU.
The databases are also very disk IO intensive and it is highly recommended
to have these configured on high speed RAID arrays.
If possible it is preferable to have them installed on a SAN.
The databases can be installed on another SQL server, however, you need to
be aware of the impact that the BizTalk databases can have on the other
databases.
In the future you can break out the databases to other dedicated servers .
E.g. a good candidate would be the Tracking DTADb database.
If you do not wish to run ConfigFramework again, you can make the changes
to the Management database. However, I am pretty sure this is not a
supported method.
If 1 machine is the only option, I would recommend at a minimal using a
[QUADx2Ghz/4GB RAM/SAN].
Better still, I would recommend a dedicated [QUADx2Ghz/4GB RAM/SAN] for the
SQL databases and for BizTalk a [DUALx2.8Ghz/2GB RAM]

A2
Yes you can have this setup without orchestrations.
You can use Maps on the Receiving and/or Send ports to transform the data.

Q1
What do you mean by "an initial volume of 70,000 messages back and forth"
5K is a fairly small document size.
Within what period of time do you expect this volume of data to be received
and processed? 1 day, 1 hr?

Hope this helps.

Thanks,
MRoze

This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
[vbcol=seagreen]

We are looking at creating a new environment to support Biztalk 2004. We
will be starting with just one process that will take an xml message (from
an MQSeries queue) go into Biztalk and map it to a flat file positional
file and send it to an AS/400 system. Conversely, it will map the flat
file into an xml file as an acknowledgement. We expect to start with an
initial volume of 70,000 messages back and forth with an average size of 5
KB. We do not intend to use orchestrations for this first deployment.
Would it be feasible to install the Biztalk components and corresponding
databases on one server? From your expriences, what is the minimal system
requirements for it to run without a performance degradation. Can the
databases be installed on another SQL server that currently is being used
by several other unrelated databases?

At some point, other processes will most likely be integrated into this
platform. So, one thought was to start with one Biztalk server and then
break out the databases as needed. Would that work?

Any thoughts from your experiences would be appreciated.

Jeannette

[vbcol=seagreen]

jss

2004-06-11, 7:06 pm

Thank you for your insight.

The file size is not that big. The number files going back and forth is over one day. The reason I stated that this is an initial volume is that this is the first process and these are work orders coming back and forth between systems. So, the volume w
ill most likely increase but not signifigantly and the file size should be constant.

As far as the traffic running through this environment, I think the contention will be when other business processes that might have more volume and/or larger file sizes need to be integrated. Also, adding other features such as orchestrations and BAM
in support of added processes concern me in terms of performance and scalability.

I don't see any new processes being integrated for at least 6 months - one year.

Does this change your recommendations at all?

Thanks!

Jeannette

jss

2004-06-20, 11:08 pm

Nick Malik

2004-06-20, 11:08 pm

If this is a production environment, you should plan to make sure you have
the capacity for future needs without actually buying all the capacity right
now. That means setting BTS up for scaling.

Given the number of transactions you want to handle, different BTS and SQL
servers are a must. The SQL machine should be fairly capable. Given what
you said about adding other transactions in the future, you may be adding a
great deal of storage under it, so it would be a good idea to have the
capacity either for an internal RAID array or access to a SAN in your
environment. You don't need to buy all the SCSI drives right now,
especially if it will be a year before you roll more stuff into production.
But have the capacity... it's a royal pain to move this stuff around.

Make sure your BTS server has a great deal of memory and a really fast hard
drive. It doesn't tend to use it's drive for storage... so capacity isn't
the issue... get the fastest you can find (within reason). I haven't seen
performance improve between two and four processor machines, but I haven't
formally studied it either. Be aware, there are licensing implications: you
pay per processor for Biztalk.

It sounds like a good plan for rolling in BTS. Good luck,

--- Nick Malik
Biztalk bum

"jss" <anonymous@discussions.microsoft.com> wrote in message
news:21641F57-C522-4E92-B3C8-6632915FEA48@microsoft.com...
> Thank you for your insight.
>
> The file size is not that big. The number files going back and forth is
over one day. The reason I stated that this is an initial volume is that
this is the first process and these are work orders coming back and forth
between systems. So, the volume will most likely increase but not
signifigantly and the file size should be constant.
>
> As far as the traffic running through this environment, I think the
contention will be when other business processes that might have more volume
and/or larger file sizes need to be integrated. Also, adding other
features such as orchestrations and BAM in support of added processes
concern me in terms of performance and scalability.
>
> I don't see any new processes being integrated for at least 6 months - one
year.
>
> Does this change your recommendations at all?
>
> Thanks!
>
> Jeannette
>

jss

2004-06-20, 11:08 pm

The spec. for our Biztalk server is as follows:

DL380R03 X3.06/533-1M
36GB 10K U320 UNI HDD
36GB 10K U320 UNI HDD
2 GB BASE MEMORY (2X1024)
2GB REG PC2100 2X1GB

Is this reasonable if everything but the databases are on this server?
If the databases are on this server, it would seem that the above config. would not work well.

Thanks,

Jeannette

"Nick Malik" wrote:

> If this is a production environment, you should plan to make sure you have
> the capacity for future needs without actually buying all the capacity right
> now. That means setting BTS up for scaling.
>
> Given the number of transactions you want to handle, different BTS and SQL
> servers are a must. The SQL machine should be fairly capable. Given what
> you said about adding other transactions in the future, you may be adding a
> great deal of storage under it, so it would be a good idea to have the
> capacity either for an internal RAID array or access to a SAN in your
> environment. You don't need to buy all the SCSI drives right now,
> especially if it will be a year before you roll more stuff into production.
> But have the capacity... it's a royal pain to move this stuff around.
>
> Make sure your BTS server has a great deal of memory and a really fast hard
> drive. It doesn't tend to use it's drive for storage... so capacity isn't
> the issue... get the fastest you can find (within reason). I haven't seen
> performance improve between two and four processor machines, but I haven't
> formally studied it either. Be aware, there are licensing implications: you
> pay per processor for Biztalk.
>
> It sounds like a good plan for rolling in BTS. Good luck,
>
> --- Nick Malik
> Biztalk bum
>
>
> "jss" <anonymous@discussions.microsoft.com> wrote in message
> news:21641F57-C522-4E92-B3C8-6632915FEA48@microsoft.com...
> over one day. The reason I stated that this is an initial volume is that
> this is the first process and these are work orders coming back and forth
> between systems. So, the volume will most likely increase but not
> signifigantly and the file size should be constant.
> contention will be when other business processes that might have more volume
> and/or larger file sizes need to be integrated. Also, adding other
> features such as orchestrations and BAM in support of added processes
> concern me in terms of performance and scalability.
> year.
>
>
>

Steve Heffner

2004-06-20, 11:08 pm

Hello Jeannette,

Here is the white paper on performance and also a utility which should
help you assertain if this will meet your needs.

Thanks,
Steve

Performance Whitepaper
http://www.gotdotnet.com/team/wsser...Performance.zip

Tool
http://www.gotdotnet.com/community/...id=ca5285b6-865
7-4468-9462-e36b06b3dbeb

--------------------[vbcol=seagreen]
<0GovwGAUEHA.2988@cpmsftngxa10.phx.gbl>
<21641F57-C522-4E92-B3C8-6632915FEA48@microsoft.com>
<tQFyc.24768$0y.20148@attbi_s03>[vbcol=seagreen]
cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA
03.phx.gbl[vbcol=seagreen]
would not work well.[vbcol=seagreen]
have[vbcol=seagreen]
right[vbcol=seagreen]
SQL[vbcol=seagreen]
what[vbcol=seagreen]
adding a[vbcol=seagreen]
production.[vbcol=seagreen]
hard[vbcol=seagreen]
isn't[vbcol=seagreen]
seen[vbcol=seagreen]
haven't[vbcol=seagreen]
implications: you[vbcol=seagreen]
is[vbcol=seagreen]
that[vbcol=seagreen]
forth[vbcol=seagreen]
volume[vbcol=seagreen]
- one[vbcol=seagreen]

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.