Is there any reason why it would be bad to run web services and your database on the same server?

4 Responses to “Is there any reason why it would be bad to run web services and your database on the same server?”

1. acww.pudge says:

   March 1, 2010 at 4:44 pm

   No I think that should work pretty good
   References :
2. Kryzchek says:

   March 1, 2010 at 4:51 pm

   Disk thrashing could be a problem if you have a heavy userload. It’s usually preferable to have SQL Server on it’s own machine, since it is constantly accessing the disk.

   It also gives you a single point of failure. If your server goes down, both your database and your web service are inaccessible.
   References :
3. jetero41 says:

   March 1, 2010 at 5:40 pm

   I am soooo far from an expert ,but i’ll give you my 2 cents ( got to be highly overvalued)
   What about the vulnerablity to hackers and viruses if the database shares the server with web services.?
   References :
4. Klausy says:

   March 1, 2010 at 5:55 pm

   Your best option would be to setup the database and webserver on different boxes. Also the db server should only allow traffic on port 1433 (default port for ADO/SQL communications). Ideally the db server would also exist behind a firewall seperate from the web server for real security.

   However…we all know of times when budget and other restraints means this is not possible so here are some suggestions for best performance when hosting web and sql on the same hardware.

   1. Secure SQL Server as much as possible. Make sure your apps use seperate logins with strong authentication. In fact lock down the server as much as possible.

   2. Ideally setup your server with at least 4 physical hard drives. One for the OS, one for IIS and the websites, One for the SQL Server Data file and finally one for the SQL transaction logs. Each of these on a seperate drive will drastically improve performance as it will cut down on the time to read data of the drives. If you do nothing else then at least put the transaction log files on a seperate drive.

   3. Be anal about SQL and system backups. If a drive does fail etc you can allways rebuild on one of the other 4 – ideally you will have setup this using drive mirroring or a RAID array of some kind.

   4. Use a robust Data Access Layer like the Microsoft Data Access Block for best performance. The most common performance issues are related to poor closing of connections, bad connection strings etc etc.

   5. Make sure all data access is done via stored procedures and use strongly typed parameter collections for added security and safety

   You may want to have a look at these guides from Microsoft. A bit heavy but well worth it for peace of mind.

   Improving .NET Application Performance and Scalability – http://msdn2.microsoft.com/en-us/library/ms998530.aspx

   Enterprise Solution Patterns Using Microsoft .NET – http://msdn2.microsoft.com/en-us/library/ms998469.aspx

   Designing Data Tier Components and Passing Data Through Tiers – http://msdn2.microsoft.com/en-us/library/ms978496.aspx
   References :