We have an application running where IIS and SQL are on the same machine. It's a windows2003standard server, with 4gigs of RAM running on a VM.
我们有一个运行的应用程序,其中IIS和SQL在同一台机器上。它是一个Windows2003标准服务器,在VM上运行4GB RAM。
Now the numbers of users are rising constantly. There are some huge statistics also, which can be run by the users but has very much impact of the performance for other users. So we need to improve the performance somehow.
现在,用户数量不断增加。还有一些巨大的统计数据,可以由用户运行,但对其他用户的性能影响很大。所以我们需要以某种方式提高性能。
I thought of separating IIS and SQL on 2 different machines with windows2008 64bit and at least 6gigs RAM for each machine, but it also should have a failover solution.
我想在每台机器上使用windows2008 64位和至少6 GB内存的2台不同机器上分离IIS和SQL,但它也应该有一个故障转移解决方案。
Can you recommend some scenarios for how to solve the performance and the failover issue?
您能否推荐一些有关如何解决性能和故障转移问题的方案?
Thanks
ps:
Just for info: we are now using inproc state management in IIS, but i think it will be better to change to sqlstatemanagement.
仅供参考:我们现在在IIS中使用inproc状态管理,但我认为更改为sqlstatemanagement会更好。
EDIT
I've broadened the question to the point of failover. As our client doesn't want to spend too much money on server and SQL licenses. Would it be "ok" to just have a replication to a second SQL server and use this as a failover? Do you know some better "cheap" solutions?
我已经将问题扩展到了故障转移的程度。因为我们的客户不想在服务器和SQL许可证上花太多钱。将复制到第二个SQL服务器并将其用作故障转移是否“可以”?你知道一些更好的“廉价”解决方案吗?
The application is just for internal use, but now more and more departments are involved in this project.
该应用程序仅供内部使用,但现在越来越多的部门参与此项目。
6 个解决方案
#1
2
Right now you have 32 bit OS on the VM I assume. Since Standard Edition does not allow AWE the two servers (IIS and SQL) the SQL Server will load up the maximum it can about 1.8 GB and leave plenty of RAM to IIS and OS. But once you move to 64 bit OS things will change as the SQL Server will take all the RAM for its buffer pool (~5GB if 6GB available) and then start giving it back to OS when notified. This behavior can be tweaked by configuring SQL Server memory options. By splitting the IIS and SQL onto separate VMs you leave all the memory on the SQL VM for its buffer pools, and that is good. Ideally you should have enough RAM so that SQL can load the entire database(s) into memory (including tempdb) and only touch the disk for log writes and when it has to checkpoint the database(s). In other words, more RAM means faster SQL. It is by far the most important hardware resource SQL requires for performance and will give the biggest bang for the buck.
现在你假设在VM上有32位操作系统。由于Standard Edition不允许AWE使用两台服务器(IIS和SQL),因此SQL Server将加载最大约1.8 GB的内存,并为IIS和OS留下足够的RAM。但是一旦你转移到64位操作系统,事情会发生变化,因为SQL Server将为其缓冲池占用所有RAM(如果有6GB可用,则为~5GB),然后在收到通知时开始将其返回给操作系统。可以通过配置SQL Server内存选项来调整此行为。通过将IIS和SQL拆分到单独的VM上,可以将SQL VM上的所有内存留给缓冲池,这很好。理想情况下,您应该有足够的RAM,以便SQL可以将整个数据库加载到内存(包括tempdb)中,只触摸磁盘以进行日志写入以及何时必须检查数据库。换句话说,更多的RAM意味着更快的SQL。它是迄今为止SQL对性能所需的最重要的硬件资源,并将带来最大的收益。
Now back to the broad question on 'failover'. In SQL Server the solutions for high availability split into two categories: automatic and manual. For automatic failover you really have only a few solutions:
现在回到关于“故障转移”的广泛问题。在SQL Server中,高可用性解决方案分为两类:自动和手动。对于自动故障转移,您实际上只有几个解决方案:
- Clustering. Traditionally this is rather expensive to implement because of the high cost of hardware that supports clustering, but with VMs this is a different story. Standard Edition SQL supports two node clusters. Clustering is a bit hard to deploy, but is quite easy operate and requires no application changes to support. With clustering the unit of failover is an entire SQL Server instance (ie. every database, including master/tempdb/model and msdb, all logins, all SQL Agent jobs etc etc). A cluster is not a performance solution, as the stand-by server is just sitting idle in case the main one crashes. You can leverage the stand-by VM by deploying the so called 'active-active' cluster. What that mean is that you deploy two clusters, one active on VM1 and stand-by on VM2, the other active on VM2 and stand-by on VM1. In case of failover one of the VMs will have to take the load of both instances, and this is why active-active deployments are sometimes frowned upon. Given that you plan to deploy on VMs not on (expensive) metal, I'd recommend against it since there is no huge cost to 'ammortize'.
- Mirroring. This will keep a hot stand-by mirror of your database (not instance). Mirroring is preferred to clustering because of lower cost to deploy (no special hardware), lower failover time (seconds as opposed to minutes in clustering) and geodistribution capabilities (mirroring supports distribution of nodes on separate continets, clustering only supports a short distance of few hundred meters between nodes). But because the unit of failover is a database, mirroring does not provide the ease of use of clustering. A lot of the resources needed by an application do not reside in the database: logins, Agent jobs, maintenance plans, database mail messages and so on and so forth. Because only the database fails over, the failover has to be carefully planned so that the application continues to work after the failover (eg. logins have to transferred). The application also has to be aware of the mirroring deployment so that it connects properly. With Standard Edition you will only be able to deploy mirroring in high-safety mode.
- Hardware mirroring. I'm not going to enter into details on this one, it requires specialized SAN hardware capable of disk level mirroring.
集群。传统上,由于支持群集的硬件成本较高,因此实施起来相当昂贵,但对于VM而言,这是一个不同的故事。 Standard Edition SQL支持两个节点集群。集群有点难以部署,但操作非常简单,无需支持应用程序更改。通过群集,故障转移单元是一个完整的SQL Server实例(即每个数据库,包括master / tempdb / model和msdb,所有登录,所有SQL Agent作业等)。群集不是性能解决方案,因为备用服务器只是闲置以防主要服务器崩溃。您可以通过部署所谓的“主动 - 主动”群集来利用备用VM。这意味着您部署了两个集群,一个在VM1上处于活动状态,在VM2上处于备用状态,另一个在VM2上处于活动状态,在VM1上处于备用状态。在故障转移的情况下,其中一个VM必须承担两个实例的负载,这就是为什么主动 - 主动部署有时不受欢迎的原因。鉴于你计划部署在没有(昂贵)金属的虚拟机上,我建议反对它,因为'ammortize'没有巨大的成本。
镜像。这将保留数据库(不是实例)的热备用镜像。镜像优于群集,因为部署成本较低(无需特殊硬件),故障转移时间较短(与群集中的分钟数相对的秒数)和地理分布功能(镜像支持在单独的端口上分配节点,群集仅支持少量短距离)节点之间的百米)。但由于故障转移单元是数据库,因此镜像不提供集群的易用性。应用程序所需的许多资源不驻留在数据库中:登录,代理作业,维护计划,数据库邮件消息等等。由于只有数据库进行故障转移,因此必须仔细规划故障转移,以便应用程序在故障转移后继续工作(例如,必须转移登录)。应用程序还必须了解镜像部署,以便正确连接。使用Standard Edition,您只能在高安全模式下部署镜像。
硬件镜像。我不打算详细介绍这个,它需要能够进行磁盘级镜像的专用SAN硬件。
If you're considering manual failover solutions then there are couple more alternatives:
如果您正在考虑手动故障转移解决方案,那么还有更多选择:
-
Log Shipping. Log shipping is basically out-of-band mirroring. Instead of transferring log records in real-time over a dedicated TCP connection, the log is transferred via file copy operations. There are very few reasons to choose log shipping over mirroring: the stand-by database can be queried for reporting, the stand-by can be located on a location with sporadic connectivity, the stand-by can be housed by a really low powered machine.
记录运输。日志传送基本上是带外镜像。日志不是通过专用TCP连接实时传输日志记录,而是通过文件复制操作传输。通过镜像选择日志传送的原因很少:可以查询备用数据库进行报告,备用数据库可以位于具有零星连接的位置,备用数据库可以由非常低功率的机器安装。
-
Replication. This is really not a high availability solution. Replication is a solution to provide data copies and/or to exchange data updates between sites. While it can be used to deploy some sort of high-availability make-shift 'solution', there are many problems with that and basically no advantage. Compared to both log shipping and mirroring, it has a number of additional disadvantages because the unit of failover is not even a database, is only slices of data within a database (some of the tables). Metadata like user and security permissions are not failed over, schema changes have to be done in a replication aware mode and some changes cannot even be replicated. By contract both mirroring and log shipping provide stand-by copy identical with the production database that automatically cover any change done to the database.
复制。这实际上不是高可用性解决方案。复制是一种在站点之间提供数据副本和/或交换数据更新的解决方案。虽然它可以用于部署某种高可用性的make-shift“解决方案”,但是存在许多问题并且基本上没有优势。与日志传送和镜像相比,它还有许多其他缺点,因为故障转移单元甚至不是数据库,只是数据库中的数据片段(某些表)。用户和安全权限等元数据不会进行故障转移,架构更改必须在复制感知模式下完成,甚至无法复制某些更改。通过合同,镜像和日志传送都提供与生产数据库相同的备用副本,该数据库自动覆盖对数据库所做的任何更改。
You mention that you are concerned about license costs: you actually don't need a license for any of the passive servers with any of these technologies except replication. The stand-by servers require a license only if they become active and runs the database for more than 30 days.
您提到您担心许可证成本:除了复制之外,您实际上不需要使用任何这些技术的任何被动服务器的许可证。备用服务器仅在它们变为活动状态并且运行数据库超过30天时才需要许可证。
Considering you plan to deploy on VMs my choice would be clustering. If you would deploy on metal, I'd recommend mirroing instead because of the cost of clustering hardware.
考虑到您计划在VM上部署,我的选择将是群集。如果你要在金属上部署,我建议使用镜像,因为集群硬件的成本。
#2
1
SQL Server always works best if it is the "ONLY" thing running on a machine. You will have a quick, easy and good benefit from just doing that. It seems to like to take control of everything and is always happier when it can :)
如果SQL Server是在机器上运行的“唯一”的东西,它总是最好的。只需这样做,您将获得快速,简单和良好的好处。它似乎想控制一切,并且它总是更快乐:)
#3
1
You must refer to these 2 articles on codeproject for ASP.Net performance tuning
您必须在codeproject上参考这两篇关于ASP.Net性能调优的文章
1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx
1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx 2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx
I have personally implemented these techniques in my asp.net apps and gained more than 30% performance improvements.
我个人在我的asp.net应用程序中实现了这些技术,并且性能提升了30%以上。
Additionally you can refer to this article for 99.99% uptime for your application.
此外,您可以参考本文,了解您的应用程序99.99%的正常运行时间。
#4
1
It sounds like you really asking should you put the DB on a separate machine. This may not improve performance (it will actually decrease as latency increases) but will improve scalability (which I am guessing is what you really need).
听起来你真的要问你应该把DB放在一台单独的机器上。这可能无法提高性能(实际上会随着延迟的增加而减少),但会提高可扩展性(我猜你正是需要的)。
Performance <> scalability.
性能<>可伸缩性。
However more issues come into play- if you don't have enough RAM performance may decrease having the DB on the same box- SQL server likes to use RAM.
然而,更多的问题发挥作用 - 如果你没有足够的RAM性能可能会减少数据库在同一个盒子上 - SQL服务器喜欢使用RAM。
That's why for things like TFS that use SQL server, for a low number of users Microsoft recommend it is all installed on 1 machine, but for a higher number of users Microsoft recommend the DB is situated on a different server.
这就是为什么像TFS这样使用SQL服务器的东西,对于少数用户微软推荐它全部安装在一台机器上,但对于更多用户,微软建议数据库位于不同的服务器上。
You can read about the deployment options for TFS here.
您可以在此处阅读有关TFS的部署选项。
Switching SQL Server state management will not increase performance- it will likely decrease it, but you will gain other benefits (like reliability).
切换SQL Server状态管理不会提高性能 - 它可能会降低性能,但您将获得其他好处(如可靠性)。
It sounds like you need to actually find out what the performance bottleneck is first. In my experience this is typically in the DB.
听起来你需要首先找出性能瓶颈是什么。根据我的经验,这通常在数据库中。
Have you looked into standard ASP.NET optimization techniques like caching? Microsoft provides guidance on application tuning that also might be useful to you.
您是否研究过标准的ASP.NET优化技术,如缓存? Microsoft提供了有关应用程序调优的指导,这些指南也可能对您有用。
As you using SQL Server in a Web application scenario, if you are using SQL Server 2005 and above you might wish to read about Snapshot isolation. Sometimes not using it is a cause of performance issues in Web applications.
在Web应用程序方案中使用SQL Server时,如果您使用的是SQL Server 2005及更高版本,则可能希望了解有关快照隔离的信息。有时不使用它是Web应用程序中性能问题的原因。
#5
0
Separation of the layers may help. Often the tuning of a machine for a DB is quite specific, so that's a reasonable first effort.
分层可能有所帮助。通常,为数据库调整机器是非常具体的,因此这是合理的第一次努力。
However if you have two kinds of user activities, one of which is very heavy then you are always going to run the risk of having a few heavy users hurt the rest of the population.
但是,如果你有两种用户活动,其中一种非常沉重,那么你总是会冒着让一些重度用户伤害其他人的风险。
Two things you may consider:
你可以考虑两件事:
- Can you adopt a "DataWarehouse" approach? Have a second DB trickle-fed from the first. The new DB being where the heavy users do their work. Sure their stats will be slightly out of date, but that's conceptually always going to be true -- by the time they look at the answers the world will have moved.
- Control the number of stats requests you allow at any one time. Perhaps have them submitted as a "job" to a queue. Run them as a low priority.
你能采用“DataWarehouse”方法吗?从第一个开始有第二个DB涓流。新数据库是重度用户开展工作的地方。当然他们的统计数据会略微过时,但这在概念上总是如此 - 当他们看到世界将要移动的答案时。
控制您一次允许的统计信息请求数。也许将它们作为“工作”提交到队列中。将它们作为低优先级运行。
#6
0
Naturally separating IIS and SQL server is the first step. Sql server really want to have a complete machine for itself.
自然地分离IIS和SQL服务器是第一步。 Sql server真的想拥有一台完整的机器。
The second thing that is important is to analyze the application as it runs. Never try to optimize the performance of your application without having real usage data, because you probably just spend time optimizing stuff that rarely gets called. One technique I have used with success in the past is to create a System.Diagnostics.Stopwatch in Request_Begin in the global.asax, then store it in a context variable
第二件重要的事情是在运行时分析应用程序。在没有真实使用数据的情况下,永远不要尝试优化应用程序的性能,因为您可能只是花时间优化很少被调用的东西。我过去成功使用的一种技术是在global.asax中的Request_Begin中创建System.Diagnostics.Stopwatch,然后将其存储在上下文变量中
var sw = new Stopwatch();
sw.Start()
HttpContext.Current.Items["stopwatch"] = sw;
In Request_End, you obtain the stopwatch agin
在Request_End中,您获得秒表agin
sw = HttpContext.Current.Items["stopwatch"];
sw.Stop();
Timespan ts = sw.Elapsed;
And then write to a log table how long time it took to process the request. Also log the URL (both with and without query string parameters) and all sorts of stuff that will help you to analyze performance.
然后写入日志表处理请求所花费的时间。同时记录URL(包含和不包含查询字符串参数)以及可帮助您分析性能的各种内容。
Then you can analyze you application and find which operations take the longest time, which are called the most, etc. That will allow you to see if there is one page that is requested a lot, and it generally takes a long time to complete, that should be a target of optimization, using whatever tools you have for that, both .NET and SQL profilers.
然后你可以分析你的应用程序并找出哪些操作占用时间最长,哪些操作最多,等等。这样你就可以看到是否有一个页面被请求了很多,而且通常需要很长时间才能完成,这应该是优化的目标,使用你拥有的任何工具,.NET和SQL分析器。
Other stuff I also normally log are, IP addresses, and user ID for logged in users. That also gives me an invaluable debbugging tool when errors arise.
我通常记录的其他内容,IP地址和登录用户的用户ID。当错误出现时,这也给了我一个宝贵的调试工具。
A reason to put it in a table, as opposed to writing it to a log file is that you can use SQL syntax to filter out, group, calculate average times, etc.
将其放入表中而不是将其写入日志文件的原因是您可以使用SQL语法来过滤,分组,计算平均时间等。
#1
2
Right now you have 32 bit OS on the VM I assume. Since Standard Edition does not allow AWE the two servers (IIS and SQL) the SQL Server will load up the maximum it can about 1.8 GB and leave plenty of RAM to IIS and OS. But once you move to 64 bit OS things will change as the SQL Server will take all the RAM for its buffer pool (~5GB if 6GB available) and then start giving it back to OS when notified. This behavior can be tweaked by configuring SQL Server memory options. By splitting the IIS and SQL onto separate VMs you leave all the memory on the SQL VM for its buffer pools, and that is good. Ideally you should have enough RAM so that SQL can load the entire database(s) into memory (including tempdb) and only touch the disk for log writes and when it has to checkpoint the database(s). In other words, more RAM means faster SQL. It is by far the most important hardware resource SQL requires for performance and will give the biggest bang for the buck.
现在你假设在VM上有32位操作系统。由于Standard Edition不允许AWE使用两台服务器(IIS和SQL),因此SQL Server将加载最大约1.8 GB的内存,并为IIS和OS留下足够的RAM。但是一旦你转移到64位操作系统,事情会发生变化,因为SQL Server将为其缓冲池占用所有RAM(如果有6GB可用,则为~5GB),然后在收到通知时开始将其返回给操作系统。可以通过配置SQL Server内存选项来调整此行为。通过将IIS和SQL拆分到单独的VM上,可以将SQL VM上的所有内存留给缓冲池,这很好。理想情况下,您应该有足够的RAM,以便SQL可以将整个数据库加载到内存(包括tempdb)中,只触摸磁盘以进行日志写入以及何时必须检查数据库。换句话说,更多的RAM意味着更快的SQL。它是迄今为止SQL对性能所需的最重要的硬件资源,并将带来最大的收益。
Now back to the broad question on 'failover'. In SQL Server the solutions for high availability split into two categories: automatic and manual. For automatic failover you really have only a few solutions:
现在回到关于“故障转移”的广泛问题。在SQL Server中,高可用性解决方案分为两类:自动和手动。对于自动故障转移,您实际上只有几个解决方案:
- Clustering. Traditionally this is rather expensive to implement because of the high cost of hardware that supports clustering, but with VMs this is a different story. Standard Edition SQL supports two node clusters. Clustering is a bit hard to deploy, but is quite easy operate and requires no application changes to support. With clustering the unit of failover is an entire SQL Server instance (ie. every database, including master/tempdb/model and msdb, all logins, all SQL Agent jobs etc etc). A cluster is not a performance solution, as the stand-by server is just sitting idle in case the main one crashes. You can leverage the stand-by VM by deploying the so called 'active-active' cluster. What that mean is that you deploy two clusters, one active on VM1 and stand-by on VM2, the other active on VM2 and stand-by on VM1. In case of failover one of the VMs will have to take the load of both instances, and this is why active-active deployments are sometimes frowned upon. Given that you plan to deploy on VMs not on (expensive) metal, I'd recommend against it since there is no huge cost to 'ammortize'.
- Mirroring. This will keep a hot stand-by mirror of your database (not instance). Mirroring is preferred to clustering because of lower cost to deploy (no special hardware), lower failover time (seconds as opposed to minutes in clustering) and geodistribution capabilities (mirroring supports distribution of nodes on separate continets, clustering only supports a short distance of few hundred meters between nodes). But because the unit of failover is a database, mirroring does not provide the ease of use of clustering. A lot of the resources needed by an application do not reside in the database: logins, Agent jobs, maintenance plans, database mail messages and so on and so forth. Because only the database fails over, the failover has to be carefully planned so that the application continues to work after the failover (eg. logins have to transferred). The application also has to be aware of the mirroring deployment so that it connects properly. With Standard Edition you will only be able to deploy mirroring in high-safety mode.
- Hardware mirroring. I'm not going to enter into details on this one, it requires specialized SAN hardware capable of disk level mirroring.
集群。传统上,由于支持群集的硬件成本较高,因此实施起来相当昂贵,但对于VM而言,这是一个不同的故事。 Standard Edition SQL支持两个节点集群。集群有点难以部署,但操作非常简单,无需支持应用程序更改。通过群集,故障转移单元是一个完整的SQL Server实例(即每个数据库,包括master / tempdb / model和msdb,所有登录,所有SQL Agent作业等)。群集不是性能解决方案,因为备用服务器只是闲置以防主要服务器崩溃。您可以通过部署所谓的“主动 - 主动”群集来利用备用VM。这意味着您部署了两个集群,一个在VM1上处于活动状态,在VM2上处于备用状态,另一个在VM2上处于活动状态,在VM1上处于备用状态。在故障转移的情况下,其中一个VM必须承担两个实例的负载,这就是为什么主动 - 主动部署有时不受欢迎的原因。鉴于你计划部署在没有(昂贵)金属的虚拟机上,我建议反对它,因为'ammortize'没有巨大的成本。
镜像。这将保留数据库(不是实例)的热备用镜像。镜像优于群集,因为部署成本较低(无需特殊硬件),故障转移时间较短(与群集中的分钟数相对的秒数)和地理分布功能(镜像支持在单独的端口上分配节点,群集仅支持少量短距离)节点之间的百米)。但由于故障转移单元是数据库,因此镜像不提供集群的易用性。应用程序所需的许多资源不驻留在数据库中:登录,代理作业,维护计划,数据库邮件消息等等。由于只有数据库进行故障转移,因此必须仔细规划故障转移,以便应用程序在故障转移后继续工作(例如,必须转移登录)。应用程序还必须了解镜像部署,以便正确连接。使用Standard Edition,您只能在高安全模式下部署镜像。
硬件镜像。我不打算详细介绍这个,它需要能够进行磁盘级镜像的专用SAN硬件。
If you're considering manual failover solutions then there are couple more alternatives:
如果您正在考虑手动故障转移解决方案,那么还有更多选择:
-
Log Shipping. Log shipping is basically out-of-band mirroring. Instead of transferring log records in real-time over a dedicated TCP connection, the log is transferred via file copy operations. There are very few reasons to choose log shipping over mirroring: the stand-by database can be queried for reporting, the stand-by can be located on a location with sporadic connectivity, the stand-by can be housed by a really low powered machine.
记录运输。日志传送基本上是带外镜像。日志不是通过专用TCP连接实时传输日志记录,而是通过文件复制操作传输。通过镜像选择日志传送的原因很少:可以查询备用数据库进行报告,备用数据库可以位于具有零星连接的位置,备用数据库可以由非常低功率的机器安装。
-
Replication. This is really not a high availability solution. Replication is a solution to provide data copies and/or to exchange data updates between sites. While it can be used to deploy some sort of high-availability make-shift 'solution', there are many problems with that and basically no advantage. Compared to both log shipping and mirroring, it has a number of additional disadvantages because the unit of failover is not even a database, is only slices of data within a database (some of the tables). Metadata like user and security permissions are not failed over, schema changes have to be done in a replication aware mode and some changes cannot even be replicated. By contract both mirroring and log shipping provide stand-by copy identical with the production database that automatically cover any change done to the database.
复制。这实际上不是高可用性解决方案。复制是一种在站点之间提供数据副本和/或交换数据更新的解决方案。虽然它可以用于部署某种高可用性的make-shift“解决方案”,但是存在许多问题并且基本上没有优势。与日志传送和镜像相比,它还有许多其他缺点,因为故障转移单元甚至不是数据库,只是数据库中的数据片段(某些表)。用户和安全权限等元数据不会进行故障转移,架构更改必须在复制感知模式下完成,甚至无法复制某些更改。通过合同,镜像和日志传送都提供与生产数据库相同的备用副本,该数据库自动覆盖对数据库所做的任何更改。
You mention that you are concerned about license costs: you actually don't need a license for any of the passive servers with any of these technologies except replication. The stand-by servers require a license only if they become active and runs the database for more than 30 days.
您提到您担心许可证成本:除了复制之外,您实际上不需要使用任何这些技术的任何被动服务器的许可证。备用服务器仅在它们变为活动状态并且运行数据库超过30天时才需要许可证。
Considering you plan to deploy on VMs my choice would be clustering. If you would deploy on metal, I'd recommend mirroing instead because of the cost of clustering hardware.
考虑到您计划在VM上部署,我的选择将是群集。如果你要在金属上部署,我建议使用镜像,因为集群硬件的成本。
#2
1
SQL Server always works best if it is the "ONLY" thing running on a machine. You will have a quick, easy and good benefit from just doing that. It seems to like to take control of everything and is always happier when it can :)
如果SQL Server是在机器上运行的“唯一”的东西,它总是最好的。只需这样做,您将获得快速,简单和良好的好处。它似乎想控制一切,并且它总是更快乐:)
#3
1
You must refer to these 2 articles on codeproject for ASP.Net performance tuning
您必须在codeproject上参考这两篇关于ASP.Net性能调优的文章
1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx
1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx 2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx
I have personally implemented these techniques in my asp.net apps and gained more than 30% performance improvements.
我个人在我的asp.net应用程序中实现了这些技术,并且性能提升了30%以上。
Additionally you can refer to this article for 99.99% uptime for your application.
此外,您可以参考本文,了解您的应用程序99.99%的正常运行时间。
#4
1
It sounds like you really asking should you put the DB on a separate machine. This may not improve performance (it will actually decrease as latency increases) but will improve scalability (which I am guessing is what you really need).
听起来你真的要问你应该把DB放在一台单独的机器上。这可能无法提高性能(实际上会随着延迟的增加而减少),但会提高可扩展性(我猜你正是需要的)。
Performance <> scalability.
性能<>可伸缩性。
However more issues come into play- if you don't have enough RAM performance may decrease having the DB on the same box- SQL server likes to use RAM.
然而,更多的问题发挥作用 - 如果你没有足够的RAM性能可能会减少数据库在同一个盒子上 - SQL服务器喜欢使用RAM。
That's why for things like TFS that use SQL server, for a low number of users Microsoft recommend it is all installed on 1 machine, but for a higher number of users Microsoft recommend the DB is situated on a different server.
这就是为什么像TFS这样使用SQL服务器的东西,对于少数用户微软推荐它全部安装在一台机器上,但对于更多用户,微软建议数据库位于不同的服务器上。
You can read about the deployment options for TFS here.
您可以在此处阅读有关TFS的部署选项。
Switching SQL Server state management will not increase performance- it will likely decrease it, but you will gain other benefits (like reliability).
切换SQL Server状态管理不会提高性能 - 它可能会降低性能,但您将获得其他好处(如可靠性)。
It sounds like you need to actually find out what the performance bottleneck is first. In my experience this is typically in the DB.
听起来你需要首先找出性能瓶颈是什么。根据我的经验,这通常在数据库中。
Have you looked into standard ASP.NET optimization techniques like caching? Microsoft provides guidance on application tuning that also might be useful to you.
您是否研究过标准的ASP.NET优化技术,如缓存? Microsoft提供了有关应用程序调优的指导,这些指南也可能对您有用。
As you using SQL Server in a Web application scenario, if you are using SQL Server 2005 and above you might wish to read about Snapshot isolation. Sometimes not using it is a cause of performance issues in Web applications.
在Web应用程序方案中使用SQL Server时,如果您使用的是SQL Server 2005及更高版本,则可能希望了解有关快照隔离的信息。有时不使用它是Web应用程序中性能问题的原因。
#5
0
Separation of the layers may help. Often the tuning of a machine for a DB is quite specific, so that's a reasonable first effort.
分层可能有所帮助。通常,为数据库调整机器是非常具体的,因此这是合理的第一次努力。
However if you have two kinds of user activities, one of which is very heavy then you are always going to run the risk of having a few heavy users hurt the rest of the population.
但是,如果你有两种用户活动,其中一种非常沉重,那么你总是会冒着让一些重度用户伤害其他人的风险。
Two things you may consider:
你可以考虑两件事:
- Can you adopt a "DataWarehouse" approach? Have a second DB trickle-fed from the first. The new DB being where the heavy users do their work. Sure their stats will be slightly out of date, but that's conceptually always going to be true -- by the time they look at the answers the world will have moved.
- Control the number of stats requests you allow at any one time. Perhaps have them submitted as a "job" to a queue. Run them as a low priority.
你能采用“DataWarehouse”方法吗?从第一个开始有第二个DB涓流。新数据库是重度用户开展工作的地方。当然他们的统计数据会略微过时,但这在概念上总是如此 - 当他们看到世界将要移动的答案时。
控制您一次允许的统计信息请求数。也许将它们作为“工作”提交到队列中。将它们作为低优先级运行。
#6
0
Naturally separating IIS and SQL server is the first step. Sql server really want to have a complete machine for itself.
自然地分离IIS和SQL服务器是第一步。 Sql server真的想拥有一台完整的机器。
The second thing that is important is to analyze the application as it runs. Never try to optimize the performance of your application without having real usage data, because you probably just spend time optimizing stuff that rarely gets called. One technique I have used with success in the past is to create a System.Diagnostics.Stopwatch in Request_Begin in the global.asax, then store it in a context variable
第二件重要的事情是在运行时分析应用程序。在没有真实使用数据的情况下,永远不要尝试优化应用程序的性能,因为您可能只是花时间优化很少被调用的东西。我过去成功使用的一种技术是在global.asax中的Request_Begin中创建System.Diagnostics.Stopwatch,然后将其存储在上下文变量中
var sw = new Stopwatch();
sw.Start()
HttpContext.Current.Items["stopwatch"] = sw;
In Request_End, you obtain the stopwatch agin
在Request_End中,您获得秒表agin
sw = HttpContext.Current.Items["stopwatch"];
sw.Stop();
Timespan ts = sw.Elapsed;
And then write to a log table how long time it took to process the request. Also log the URL (both with and without query string parameters) and all sorts of stuff that will help you to analyze performance.
然后写入日志表处理请求所花费的时间。同时记录URL(包含和不包含查询字符串参数)以及可帮助您分析性能的各种内容。
Then you can analyze you application and find which operations take the longest time, which are called the most, etc. That will allow you to see if there is one page that is requested a lot, and it generally takes a long time to complete, that should be a target of optimization, using whatever tools you have for that, both .NET and SQL profilers.
然后你可以分析你的应用程序并找出哪些操作占用时间最长,哪些操作最多,等等。这样你就可以看到是否有一个页面被请求了很多,而且通常需要很长时间才能完成,这应该是优化的目标,使用你拥有的任何工具,.NET和SQL分析器。
Other stuff I also normally log are, IP addresses, and user ID for logged in users. That also gives me an invaluable debbugging tool when errors arise.
我通常记录的其他内容,IP地址和登录用户的用户ID。当错误出现时,这也给了我一个宝贵的调试工具。
A reason to put it in a table, as opposed to writing it to a log file is that you can use SQL syntax to filter out, group, calculate average times, etc.
将其放入表中而不是将其写入日志文件的原因是您可以使用SQL语法来过滤,分组,计算平均时间等。