Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.
Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.
|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.co...ance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA
|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:

>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Network
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirements
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.com/sql_server_performance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:
>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Network
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirements
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hardware scalability

Dear all,
My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
2000 SP3a installed (around 90 databases in which around 10 are used daily
not intensively - total data size : 5.5Go - in which 10% is for daily used
databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
replication is implemented. The server is setup as editor only (distributor
and subscribers are on other powerful servers). All is working fine. Network
load is low (10Mo pikes for I/O). We have got around 20 frequent users on
this server.
We are planning to implement two new databases that should represents a
significant increase in workload (frequent heavy batches processes - 1Go of
data). Moreover, we need to integrate them in the transactional replication
process.
We are wondering if our hardware will be sufficient enough to support this
added workload. Yet, I've not found any rule to deduce hardware requirements
from databases size and use.
Could you give me clues for scaling my server, knowing that I have no
similar test server to make benchmarking? Maybe have you similar systems?
Thanks a lot,
Eric.Eric,
You're correct there's not much to go on here. However, I would point out
one thing. Sounds like the server infrequently services reasonably short
requests. That indicates that the single processor is probably keeping up
with the requests because its generally only getting one request at a time.
So the responsiveness to the users is acceptable. By integrating heavy
batch processes into the mix, there's a strong likelihood that SQL won't
have an internal scheduler free when a user request is initiated. A mix of
heavy batch or large query, with OLTP on too few processors usually results
in end users waiting on screens.
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:DF71D8B2-6184-4631-82F3-6FE96FA81514@.microsoft.com...
> Dear all,
> My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
> 2000 SP3a installed (around 90 databases in which around 10 are used daily
> not intensively - total data size : 5.5Go - in which 10% is for daily used
> databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
> replication is implemented. The server is setup as editor only
> (distributor
> and subscribers are on other powerful servers). All is working fine.
> Network
> load is low (10Mo pikes for I/O). We have got around 20 frequent users on
> this server.
> We are planning to implement two new databases that should represents a
> significant increase in workload (frequent heavy batches processes - 1Go
> of
> data). Moreover, we need to integrate them in the transactional
> replication
> process.
> We are wondering if our hardware will be sufficient enough to support this
> added workload. Yet, I've not found any rule to deduce hardware
> requirements
> from databases size and use.
> Could you give me clues for scaling my server, knowing that I have no
> similar test server to make benchmarking? Maybe have you similar systems?
> Thanks a lot,
> Eric.|||"Danny" <someone@.nowhere.com> wrote in message
news:KpdWe.6396$XO6.2458@.trnddc03...
> Eric,
> You're correct there's not much to go on here. However, I would point out
> one thing. Sounds like the server infrequently services reasonably short
> requests. That indicates that the single processor is probably keeping up
> with the requests because its generally only getting one request at a
> time. So the responsiveness to the users is acceptable. By integrating
> heavy batch processes into the mix, there's a strong likelihood that SQL
> won't have an internal scheduler free when a user request is initiated. A
> mix of heavy batch or large query, with OLTP on too few processors usually
> results in end users waiting on screens.
>
I have to agree with Danny on this one. The right answer (as always with
database) is, It depends.
Do you want to optimize your server for general usage, or do you want to
optimize your server to handle the spikes in performance.
For general usage, I would suggest that you add more RAM to the box. 4GB
total and give 2GB to SQL Server. You will still have spikes, most likely
due to the processor running heavy batches, but should otherwise be in
decent shape. On the replication side of the house, depending on the size
of your transactions which are being replicated and how often replication
occurs (immediate, every 15 minutes etc.). You may want to upgrade your NIC
if possible to 100MB or even 1GB.
If you want to optimize to handle the spikes, then more RAM, 2 procs with
higher speeds and larger L2 caches should help out.
You can read up on a lot of the perf counters to watch for at
www.sql-server-performance.com Take a look at McGeHee's article... It's a
great first step...
http://www.sql-server-performance.c...mance_audit.asp
Rick Sawtell
MCT, MCSD, MCDBA|||The "standard" config for a dedicated and heavy-duty SQLServer
hardware is 2-processors, all the RAM you can get, at least separate
physical drive for log files, generally RAID-5 for the main DBs.
These days with 200gb drives going for a hundred bux you don't need
RAID just to get your storage size up, but it still helps isolate
physical storage concerns. Network-attached storage is even better,
if you have gigahertz networks. And oh yes, Windows2003, makes
hyperthreading work and has better general threading and COM 1.5+.
Click up Dell and configure such a server, betcha can get a couple of
3ghz processors starting around, um, ... $10k? $15k? Depends. Once
you reach blade-scale, adding another processor is cheap.
Let's say a proper current box like this would be around 5x faster
than a single PIII with a single physical disk drive.
J.
On Thu, 15 Sep 2005 02:00:07 -0700, "itparis"
<itparis@.discussions.microsoft.com> wrote:

>Dear all,
>My company has got a Win 2000 SP3 (PIII 1.2Ghz, 1.5Go RAM) server with SQL
>2000 SP3a installed (around 90 databases in which around 10 are used daily
>not intensively - total data size : 5.5Go - in which 10% is for daily used
>databases). SQL Server is setup to use at most 800Mo of RAM. Transactional
>replication is implemented. The server is setup as editor only (distributor
>and subscribers are on other powerful servers). All is working fine. Networ
k
>load is low (10Mo pikes for I/O). We have got around 20 frequent users on
>this server.
>We are planning to implement two new databases that should represents a
>significant increase in workload (frequent heavy batches processes - 1Go of
>data). Moreover, we need to integrate them in the transactional replication
>process.
>We are wondering if our hardware will be sufficient enough to support this
>added workload. Yet, I've not found any rule to deduce hardware requirement
s
>from databases size and use.
>Could you give me clues for scaling my server, knowing that I have no
>similar test server to make benchmarking? Maybe have you similar systems?
>Thanks a lot,
>Eric.

Hardware requirement

Hi !
We have a sql server 2000, IIS and windows 2000 op-sys.
1133 Mhz cpu, 512 Mb RAM, raid5 scsi disk.
One prod database size 1164 Mb
Two test databases size 45 Mb
The server have 4 user in production and 1 programmer.
Is this server to small ?
If yes, what should we upgrade ?
Regards Jan RockstedtConsidering that your database and number of users is within the limitations
for MSDE (2GB data, 5 concurrent users), and MSDE is designed to run on a
desktop machine, I would say that your server might be overspec'd rather
than underspec'd.
Do you have any performance issues with it?
--
Jacco Schalkwijk
SQL Server MVP
"Jan" <_NO_SPAM_@.telia.com> wrote in message
news:O2LAncL8DHA.1548@.tk2msftngp13.phx.gbl...
> Hi !
> We have a sql server 2000, IIS and windows 2000 op-sys.
> 1133 Mhz cpu, 512 Mb RAM, raid5 scsi disk.
> One prod database size 1164 Mb
> Two test databases size 45 Mb
> The server have 4 user in production and 1 programmer.
> Is this server to small ?
> If yes, what should we upgrade ?
> Regards Jan Rockstedt
>|||I have problem with the RAM.
The server is allocating 560 Mb of 512 Mb, and using the swap file.
Is the any recomendation of memory alocating in SQL server 2000 ?
//Jan
Jacco Schalkwijk wrote:
> Considering that your database and number of users is within the
> limitations for MSDE (2GB data, 5 concurrent users), and MSDE is
> designed to run on a desktop machine, I would say that your server
> might be overspec'd rather than underspec'd.
> Do you have any performance issues with it?
>
> "Jan" <_NO_SPAM_@.telia.com> wrote in message
> news:O2LAncL8DHA.1548@.tk2msftngp13.phx.gbl...
>> Hi !
>> We have a sql server 2000, IIS and windows 2000 op-sys.
>> 1133 Mhz cpu, 512 Mb RAM, raid5 scsi disk.
>> One prod database size 1164 Mb
>> Two test databases size 45 Mb
>> The server have 4 user in production and 1 programmer.
>> Is this server to small ?
>> If yes, what should we upgrade ?
>> Regards Jan Rockstedt|||F.Y.I the sql server i configure:
Dynamically configure SQL server memory
Minimum 41 MB
Maximum 388 MB
Minimum query memory (KB) 1024
Jan wrote:
> I have problem with the RAM.
> The server is allocating 560 Mb of 512 Mb, and using the swap file.
> Is the any recomendation of memory alocating in SQL server 2000 ?
> //Jan
> Jacco Schalkwijk wrote:
>> Considering that your database and number of users is within the
>> limitations for MSDE (2GB data, 5 concurrent users), and MSDE is
>> designed to run on a desktop machine, I would say that your server
>> might be overspec'd rather than underspec'd.
>> Do you have any performance issues with it?
>>
>> "Jan" <_NO_SPAM_@.telia.com> wrote in message
>> news:O2LAncL8DHA.1548@.tk2msftngp13.phx.gbl...
>> Hi !
>> We have a sql server 2000, IIS and windows 2000 op-sys.
>> 1133 Mhz cpu, 512 Mb RAM, raid5 scsi disk.
>> One prod database size 1164 Mb
>> Two test databases size 45 Mb
>> The server have 4 user in production and 1 programmer.
>> Is this server to small ?
>> If yes, what should we upgrade ?
>> Regards Jan Rockstedt|||If you want to avoid having the server use the page file (I guess that's
mostly IIS that does that) you can limit SQL Server to 340 MB or less, or
you can buy some more memory. Memeory is quiet cheap these days.
--
Jacco Schalkwijk
SQL Server MVP
"Jan" <_NO_SPAM_@.telia.com> wrote in message
news:OUgXrrU8DHA.2316@.TK2MSFTNGP09.phx.gbl...
> F.Y.I the sql server i configure:
> Dynamically configure SQL server memory
> Minimum 41 MB
> Maximum 388 MB
> Minimum query memory (KB) 1024
> Jan wrote:
> > I have problem with the RAM.
> > The server is allocating 560 Mb of 512 Mb, and using the swap file.
> >
> > Is the any recomendation of memory alocating in SQL server 2000 ?
> >
> > //Jan
> >
> > Jacco Schalkwijk wrote:
> >> Considering that your database and number of users is within the
> >> limitations for MSDE (2GB data, 5 concurrent users), and MSDE is
> >> designed to run on a desktop machine, I would say that your server
> >> might be overspec'd rather than underspec'd.
> >>
> >> Do you have any performance issues with it?
> >>
> >>
> >> "Jan" <_NO_SPAM_@.telia.com> wrote in message
> >> news:O2LAncL8DHA.1548@.tk2msftngp13.phx.gbl...
> >> Hi !
> >>
> >> We have a sql server 2000, IIS and windows 2000 op-sys.
> >> 1133 Mhz cpu, 512 Mb RAM, raid5 scsi disk.
> >>
> >> One prod database size 1164 Mb
> >> Two test databases size 45 Mb
> >>
> >> The server have 4 user in production and 1 programmer.
> >>
> >> Is this server to small ?
> >> If yes, what should we upgrade ?
> >>
> >> Regards Jan Rockstedt
>
>

Hardware Configuration - Need Advice

We have a web app currently being hosted on a RAID 5 with four disks, 2 GB
RAM, Xenon 3.2 processor. Also running Windows 2003 Server Standard Ed. and
SQL Server 2000 Standard Edition. Our database is about 4GB and at most we
have 10 concurrent users hitting our server, with a mix of read and write
operations. Both the OS and our DB are on the same machine. I am aware that
having both IIS and SQL Server on the same box is not the ideal
configuration, but it has suited our needs given the load.
We are looking to private license our software to one other company, which
would entail the licensee having their own seperate db, but running in the
same instance of SQL Server. At a minimum, I'm thinking we would move SQL
Server onto its own dedicated machine, keeping the current RAID 5 config.
Perhaps this would not be sufficient?
What I'm looking for is some indication as to whether or not the proposed
platform could handle an increased user load, say 20 times what is now (200
concurrent users). This is primarily an OLTP db used for ACH processing,
with several reporting features. I'm fully aware that the application design
itself, along with query tuning, indexing, etc is equally important as the
hardware, but need some guidance on the hardware itself.
What I'm looking for are some general guidelines to follow given this
scenario. Thanks in advance.Eric there is no way to answer that without knowing a lot more of what your
current system is doing and how the hardware is holding up now. Do you do 1
transaction per second or 1 thousand? What are the disk Queues, processor
queues etc. like now?
--
Andrew J. Kelly SQL MVP
"Eric" <Eric@.discussions.microsoft.com> wrote in message
news:3C2BC87F-5505-4DD6-9E79-A053B86527BA@.microsoft.com...
> We have a web app currently being hosted on a RAID 5 with four disks, 2 GB
> RAM, Xenon 3.2 processor. Also running Windows 2003 Server Standard Ed.
> and
> SQL Server 2000 Standard Edition. Our database is about 4GB and at most
> we
> have 10 concurrent users hitting our server, with a mix of read and write
> operations. Both the OS and our DB are on the same machine. I am aware
> that
> having both IIS and SQL Server on the same box is not the ideal
> configuration, but it has suited our needs given the load.
> We are looking to private license our software to one other company, which
> would entail the licensee having their own seperate db, but running in the
> same instance of SQL Server. At a minimum, I'm thinking we would move SQL
> Server onto its own dedicated machine, keeping the current RAID 5 config.
> Perhaps this would not be sufficient?
> What I'm looking for is some indication as to whether or not the proposed
> platform could handle an increased user load, say 20 times what is now
> (200
> concurrent users). This is primarily an OLTP db used for ACH processing,
> with several reporting features. I'm fully aware that the application
> design
> itself, along with query tuning, indexing, etc is equally important as the
> hardware, but need some guidance on the hardware itself.
> What I'm looking for are some general guidelines to follow given this
> scenario. Thanks in advance.