Combined or separate?

We are trying to decide wether to place SQL Server 2000 on the IIS box or
another separate box.
What are the pros and cons of doing this? I'm thinking something like
performance (shared memory vs. TCP),
memory/cpu consumption of the SQL server. Currently the IIS box has an
average CPU usage of ~10%
without having SQL Server 2000 installed.
CasperIf the box can handle the memory and extra proc, then physically no
problem...
However, it is generally not a good practice to put your SQL on the IIS box
because of the security risk... If someone is able to hack into your IIS
box, then they also get SQL for free...
Hope this helps.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Casper Hornstrup" <msdn@.csite.com> wrote in message
news:OVJ0i2POFHA.2384@.tk2msftngp13.phx.gbl...
> We are trying to decide wether to place SQL Server 2000 on the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>|||In general the only time this is a good idea, is when implementing a web
farm, and the load on the SQL functionality is a bottleneck to the web
application, and the SQL funtionality (from web app) is read-only.
Say in the case of something like a searh, where the write (update)
functionality is implemented through some kind of publishing on a scheduled,
recurring basis, and the web site (IIS) only reading the local database...
Then the idea of having multiple local copies of the Database, one on each
IIS box in the web farm, can allow you to scale out to any degree
necessary...
"Casper Hornstrup" wrote:

> We are trying to decide wether to place SQL Server 2000 on the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>
>|||So, is this because using shared memory don't make a significant difference
in performance or because there are other divantages that outweigh that
performance increase?
Casper
"CBretana" <cbretana@.areteIndNOSPAM.com> wrote in message
news:8395D217-1EAD-42D0-BB69-4BB617A2F5C4@.microsoft.com...
> In general the only time this is a good idea, is when implementing a web
> farm, and the load on the SQL functionality is a bottleneck to the web
> application, and the SQL funtionality (from web app) is read-only.
> Say in the case of something like a searh, where the write (update)
> functionality is implemented through some kind of publishing on a
scheduled,
> recurring basis, and the web site (IIS) only reading the local database...
> Then the idea of having multiple local copies of the Database, one on each
> IIS box in the web farm, can allow you to scale out to any degree
> necessary...|||I would suggest that there are many reasons to separate SQL
and IIS onto different machines. As Wayne said, there is a
security risk with putting SQL on the same machine as IIS.
There is also the issue of licenses if you have multiple web
servers (and thus multiple SQL Server instances). Then there
is the idea of isolating the bottlenecks. If IIS is the
bottleneck, you can upgrade your IIS servers with more
memory, for example, without having to touch your SQL boxes.
If SQL's drive array is the bottleneck, you can upgrade one
array (assuming one SQL Server and multiple IIS machines)
without having to update all of your IIS machines. If SQL's
memory and/or CPU are the bottleneck, you can again upgrade
the SQL box while using inexpensive servers for your IIS
servers. If you need better read scalability, then you can
create a shared-none cluster of SQL servers separately from
how you handle IIS.
In short, I would suggest that only in the simplest designs
or most extreme, esoteric reasons should anyone consider
putting SQL on the same box as IIS.
Thomas
"Casper Hornstrup" <msdn@.csite.com> wrote in message
news:OVJ0i2POFHA.2384@.tk2msftngp13.phx.gbl...
> We are trying to decide wether to place SQL Server 2000 on
> the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking
> something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the
> IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>|||Shared memory is not the issue, unless the database is very small, the data
will be on disk at least part of the time... The issue, is that in any
production system, there is a chance that you will need more performace as
the business grows, and f your database system proovides OLTP (OnLine
Transaction Processing) functionality, which requires large numbers of
read/write operations, then you cannot <easily> scale up the performance whe
n
the database is "Copies" in multiple places. The "Writes" become a massive
issue. Reads are no problem, because you can replicate the data to multiple
instances...
So if you design and architect your system around having IIS AND SQL On the
same box, and your company never needs morethan one IIS/SQL box to service
it's business, then you're fine... But if yu need to increase performance, a
s
soon as you need to add another IIS box, (and create a web farm) you will
need to put the SQL on it's own separate box...
Again, the exception is if the SQL functionality used by the web app is
readonly...
"Casper Hornstrup" wrote:

> So, is this because using shared memory don't make a significant differenc
e
> in performance or because there are other divantages that outweigh that
> performance increase?
> Casper
> "CBretana" <cbretana@.areteIndNOSPAM.com> wrote in message
> news:8395D217-1EAD-42D0-BB69-4BB617A2F5C4@.microsoft.com...
> scheduled,
>
>