z***y
发帖数: 7151 | 1 原帖在ITPUB。 找不到了现在。
讨论话题：
1.如何让SQL Server支持高并发环境？
2.如何有效提升数据库性能？
3.你如何看待SQL Server未来几年的发展前景？
本期活动精彩案例分享：
【案例描述】
某零售巨头上线了一套基于微软系统的促销网站，系统本身已经稳定了，日常并发用户
数在200-300左右。大约在3个月之前的某天，销售部门老大准备举行一次全球性的促销
活动，要求把系统的并发数从目前的200-300提升10倍，达到2000-3000。
经过专业公司的压力测试，数据库在并发数达到600左右的时候，基本失去响应，由此
认定系统瓶颈存在于数据库端。一场轰轰烈烈的数据库性能调整就此展开。
【数据库环境描述】：
数据库类型： 某零售巨头促销专题网站
影响范围： 全球性
数据量： 500G
OS: Windows 2008
数据库版本： SQL Server 2008
数据库架构方式：单实例数据库
【案例进展】：
为了在有限的时间解决问题，甲方IT部门的老大亲自挂帅，组织了一支全球性的技术团
队，成员包括甲方自己的IT人员，软件供应商，系统集成商，专业数据库服务商，专业
压力测试商等等，人员更加是五花八门，很跨亚欧美澳各大洲，技术人员，业务人员，
管理人员都有。
每天的工作几乎就是不停的开会，英语好的，不好的，懂技术的，不懂技术的都啪啦啪
啦的上来讲一堆，由于人数众多，且彼此不熟悉，效率可想而知。
研究来研究去，出主意的人太多，也就没什么注意了，最后也没什么特别的结论，结果
也就不了了之。
我在这个过程中也提了一些建议，但是声音太小，基本被淹没了。
【结果】：
最后IT老大给业务部门老大提交了一份报告，大意是，经过专业团队的研究，在目前的
硬件，架构的基础上，并发性能已经最大化了，不能进一步提升，建议适当拉长促销的
时间段，减少对系统的压力。
【讨论】：
上面是一个真实的但不成功的案例，目的是引出我们今天的讨论，
假设你是此次案例的技术专家，你会有一些什么合理化的建议来提升系统的并发性能呢？
有哪些招数可以使用？ 这种对并发有求较高的环境，选用SQL Server是否适合呢？
你有维护高并发SQL Server数据库的实战经验吗？在你的努力下，最终并发数达到了多
少? |
y****9
发帖数: 144 | 2 >> 数据库在并发数达到600左右的时候，基本失去响应，由此认定系统瓶颈存在于数据
库端。
If i were called to work on this problem, the first step I could do is to
ask the performance data at time of 600 cocurrent users for analysis. what
is the bottle-neck, CPU or I/O or middle tier? what kind of wait events (
Oracle teram, but SQL server also has DM views to expose wait event). Based
on the wait event I can do further anaysis. |
a9
发帖数: 21638 | 3 典型的偷懒的做法吧，呵呵。
呢？
【在 z***y 的大作中提到】
: 原帖在ITPUB。 找不到了现在。
: 讨论话题：
: 1.如何让SQL Server支持高并发环境？
: 2.如何有效提升数据库性能？
: 3.你如何看待SQL Server未来几年的发展前景？
: 本期活动精彩案例分享：
: 【案例描述】
: 某零售巨头上线了一套基于微软系统的促销网站，系统本身已经稳定了，日常并发用户
: 数在200-300左右。大约在3个月之前的某天，销售部门老大准备举行一次全球性的促销
: 活动，要求把系统的并发数从目前的200-300提升10倍，达到2000-3000。
|
s**********o
发帖数: 14359 | 4 才几千用户，我的网站是每天50万访问次数，你为什么要600用户同时访问DB啊，不会
CACHE吗，只有写的时候才需要真正的访问，看来你们应该聘我做ARCHITECT了，LOL |
a9
发帖数: 21638 | 5 电子商务跟一般网站还是很不一样的。
【在 s**********o 的大作中提到】
: 才几千用户，我的网站是每天50万访问次数，你为什么要600用户同时访问DB啊，不会
: CACHE吗，只有写的时候才需要真正的访问，看来你们应该聘我做ARCHITECT了，LOL
|
s**********o
发帖数: 14359 | 6 我的就是卖东西的，一天50万访问，几千个订单，多数都试买的一天几万个，你什么商
务啊，一秒钟600个订单？
【在 a9 的大作中提到】
: 电子商务跟一般网站还是很不一样的。
|
m****d
发帖数: 372 | 7 这个问题从architect来看，确实有不少可以改进，不应该轻易让数据库搞崩溃。应该把
load限制在middle tier,而不要让所有的用户一下都涌入database,这可以提高不少并发
性能；如使用connectino pool, 最大connection 数， web tier允许的最大连接数；
数据库本身来看，oracle可以用RAC,读写分离，常用表缓存,尽量避免热点块竞争，rai
d 5改raid 10,方法还是很多，得看具体问题具体分析。
不会
LOL
【在 a9 的大作中提到】
: 电子商务跟一般网站还是很不一样的。
|
s**********o
发帖数: 14359 | 8 那么大的公司居然把责任推在DB上，搞开发的应该统统LAY OFF掉了。LOL
该把
并发
rai
【在 m****d 的大作中提到】
: 这个问题从architect来看，确实有不少可以改进，不应该轻易让数据库搞崩溃。应该把
: load限制在middle tier,而不要让所有的用户一下都涌入database,这可以提高不少并发
: 性能；如使用connectino pool, 最大connection 数， web tier允许的最大连接数；
: 数据库本身来看，oracle可以用RAC,读写分离，常用表缓存,尽量避免热点块竞争，rai
: d 5改raid 10,方法还是很多，得看具体问题具体分析。
:
: 不会
: LOL
|
a9
发帖数: 21638 | 9 就事论事啊。人家说一秒600个订单，咋就照600来想办法。
我原来做的系统，就一台sqlserver，还得镜像热备，30几个订单是没问题的，再快就
快不上去了。
【在 s**********o 的大作中提到】
: 我的就是卖东西的，一天50万访问，几千个订单，多数都试买的一天几万个，你什么商
: 务啊，一秒钟600个订单？
|
z***y
发帖数: 7151 | 10 小博瑞头：
这是案例， 是转载。
【在 s**********o 的大作中提到】
: 才几千用户，我的网站是每天50万访问次数，你为什么要600用户同时访问DB啊，不会
: CACHE吗，只有写的时候才需要真正的访问，看来你们应该聘我做ARCHITECT了，LOL
|
|
|
y****9
发帖数: 144 | 11 这本质上是一个scalability的问题。所以首先要搞清楚到底是什么影响了scalablity.
没有具体的数据 (i.e metrics to point out which area is the bottleneck)。这
个问题只能对怎样提高数据库的scalability作些泛泛之谈。 for example, if it is
CPU-bound then it is relatively easy to scale by adding more CPUs ( in
Oracle RAC you can add another node), if it is I/O bound then it is more
difficult to scale usually.
Also we need to assume app design is good enough ( 90% time performance
problem is poor app design in my working env). If not, some areas such as
reduce unncesary logic read, using bind varialbe ( in sql server I guess
called paramterized sql, ), proper index design to eliminate table scan, etc
could be checked
Based
【在 y****9 的大作中提到】
: >> 数据库在并发数达到600左右的时候，基本失去响应，由此认定系统瓶颈存在于数据
: 库端。
: If i were called to work on this problem, the first step I could do is to
: ask the performance data at time of 600 cocurrent users for analysis. what
: is the bottle-neck, CPU or I/O or middle tier? what kind of wait events (
: Oracle teram, but SQL server also has DM views to expose wait event). Based
: on the wait event I can do further anaysis.
|
a9
发帖数: 21638 | 12 话说这个每秒600个交易到底能不能做到？
scalablity.
is
etc
数据
to
what
(
【在 y****9 的大作中提到】
: 这本质上是一个scalability的问题。所以首先要搞清楚到底是什么影响了scalablity.
: 没有具体的数据 (i.e metrics to point out which area is the bottleneck)。这
: 个问题只能对怎样提高数据库的scalability作些泛泛之谈。 for example, if it is
: CPU-bound then it is relatively easy to scale by adding more CPUs ( in
: Oracle RAC you can add another node), if it is I/O bound then it is more
: difficult to scale usually.
: Also we need to assume app design is good enough ( 90% time performance
: problem is poor app design in my working env). If not, some areas such as
: reduce unncesary logic read, using bind varialbe ( in sql server I guess
: called paramterized sql, ), proper index design to eliminate table scan, etc
|
j*******n
发帖数: 48 | 13 Please define "并发数" at 600.
It's a big difference if it means concurrent connections vs. DB transactions
vs. business transactions (orders).
One order transaction can easily take over 100 DB transactions (read/write
of product/inventory data as well as product browsing activity before order
process).
It's easy to scale out using caching for read-only data. And for writes/
updates, it's common to using partitioning and sharding. |
s**********o
发帖数: 14359 | |
j*******n
发帖数: 48 | 15 You can google it. Basically it takes the idea of partitioning to and goes
to the next level.
It's commonly used in large scale MySQL and NoSQL (like MongoDB)
implementations. |
