online-performance tuning guide -笔记2

#######################系统结构##########################################
两个部分
硬件和软件组件
为需求配置正确的系统结构

硬件和软件组件
--硬件组建
----CPU  多核
----memery 大量的缓存数据避免直接发生磁盘读取
----I/O 子系统 硬盘 客户端pc 和高性能磁盘阵列不同，磁盘阵列 能够处理每秒几千次IO 并且通过多IO和热插拔的在线设备提供高可用。
----网络 带宽和速度

--软件组件
----管理用户接口
----执行业务逻辑
----管理用于请求和资源分配
----管理数据和事务

软件组建和硬件组建的区别是，硬件组建只能执行任务，比如存储和提取数据，但是软件组建能够执行多任务，比如管理用户接口和执行业务逻辑。

管理用户接口：
对于应用程序的用户是可见的，包括以下功能
打印用户端屏幕
收集用户数据并将其转换成业务逻辑
使输入的数据生效
引导以应用的级别和状态

执行业务逻辑：
此组建执行了核心业务规则，也是应用功能的核心。修复这个组件的费用也是相当昂贵的。这个组建时被一些声明和程序所执行。关于声明的一个例子是定义唯一键和外键，基于程序的逻辑的例子是折扣的策略。

组件的一般功能包括：
将一个数据模型移动到一个相关的表结构
在相关的表结构定义约束
编写程序代码逻辑来执行业务规则

管理用户请求和资源分配
这个组件在软件的所有部分执行，但是一些请求和资源会被应用的设计影响，但是一些不会。

在一个多用户的应用中，大多数用户请求的资源分配被数据库或者操作系统所处理。但是在一个大量用户并且使用方式未知的急速增长的应用中，应用的设计师必须事先确保 没有单独软件组件变得超载和不稳定。

这个组件的一般功能包括：
数据库的链接管理
执行sql的效率 游标和sql共享
管理客户状态信息
均衡经过硬件资源的用户请求负载
设置硬件软件组件的可选目标
持续的异步任务执行队列

管理数据和事务
这个组件负责了数据库和操作系统的大部分职责
这个组件的一般功能是：
使用锁和事务的意义提供数据的同时访问
使用索引和内存缓存提供对数据的最优访问
确保硬件失败时所有的的数据改变都被记录日志
强制所有的规则都清晰的为数据定义

 

为你的需求配置正确的体系结构
配置初始的系统体系结构是很大的反复研究的过程。结构必须满足符合预算和原定约束的系统需求。如果系统要求交互的用户业务决定基于数据库的内容，那么用户的需求决定了体系结构。如果系统中很少有交互用户，那么体系结构就是过程决定的。

交互型用户的例子：
会计和记账应用
订单输入系统
基于web的零售应用
贸易系统

过程主导的应用例子：
公用营业额系统
欺诈侦测系统
直达邮件

有时候过程主导的应用更容易设计多用户应用，因为用户接口元素是有限的，但是因为目标是源于过程的，结构不习惯于处理大数据容量并且不同的成功因素会变得不清晰。过程主导的应用来自于基于用户的应用和数据仓库。因此本书主要对交互型用户的结构展开讨论。

注意：生成一个系统结构不是一个确定的过程，需要自习考虑业务需求，技术选择，现有的基础设置和系统，以及实在的物力资源，例如预算和人力资源。

以下的问题会激励你在结构上的想法，尽管不是明确的引导。这些问题演示了业务模型怎样影响体系结构，缓和执行并且全面考虑性能和系统的可用性。例如

+ 系统支持多少个用户？
大多数应用分成以下类别
--少数用户轻巧的使用或者专用的机器
这种类型的应用一般只有一个用户，这个应用设计主要是为了单用户更加有效率，去提供好的响应时间，但是做这个应用需要最少的管理。这些应用的用户很少互相影响并且会有最少的资源冲突。
--在一个公司中共享应用，使用中间件增大用户数量
对于这种类型的应用，用户数受限于公司实际通过此系统处理业务的员工数。因此，用户的数量是可以预测的。但是交付一个可靠的服务对业务是至关重要的。用户会使用共享的资源，所以设计必须致力于在很重的系统负载下解决响应时间，每个会话增长的资源消耗和未来增长的空间。
--网络上无限的用户群
对这种类型的应用，额外的工程花费在必须保证没有系统组件超过了它设计的限制。这将会产生一个引起瓶颈使得系统暂停和不稳定。这个应用需要复杂的负载均衡无状态的应用服务器和有效的数据库连接管理，总的来说，统计信息和管理员需要确保如果他们的需求由于系统负载不能被满足用户得到反馈。

+用户交互方法是什么？
用户接口范围的选择- 从一个web浏览器到客户端程序
+用户的所在地会是哪里？
用户之间的距离影响到了应用如何处理网络问题。位置印务也会影响一天中的忙时，当它不能处理批或者系统维护功能。
+网速会是什么？
网速影响应用和数据库服务器的数据量和用户接口的会话特点。高度的会话用户接口能够能和后端服务器交流。一个较少会话的接口工作在屏幕发送和屏幕接受的模型，在一个慢的网络上，不可能使用高的会话接口达到高的数据输入速度。
+用户会访问多少数据，多少数据是只读的？
在线的数据请求量影响设计的各个方面，从表和索引的设计到显示层。设计效果次序保证用户反馈时间不是数据库大小的函数，如果应用是大面积只读的，那么应用和对于本地应用服务器的缓存的数据分布会是一个切实可行的选项。这也减少了核心事务数据库的负载。
+什么是需要的用户响应时间
考虑用户类型是很重要的。如果用户需要精确的信息区做重要的决策，那么用户的反馈时间不能妥协。其它用户类型，比如用户数据输入活动，可能不需要这么高的性能。
+所有的改变都必须实时做吗？
决定事务需要在用户响应时间被执行是很重要的，或者如果可以的话，他们会在异步执行的队列中排序。

以下是能够影响设计的二级问题，但是在预算和缓和执行真正的有更大的影响

+数据库会有多大？
数据库的大小影响数据库服务器机器的大小。系统上有非常大的数据库，可能必要有一个比规定负载更大的机器。这是因为大数据的管理大于数据库大小的函数。随着表和索引的增长，在可接受的时间限制内，它会花费更大比例的cpu去完成表盒索引的重建。

+业务需要的吞吐量是多大？
+可用的需求是？
+有技巧去创建和管理这个应用么？
+由于预算的约束不得不使用什么折衷？

 

+用户期望24小时的服务么？
对于交易一天24小时经营的今天网络应用是必须满足的。但是运行在一个单时区的企业系统可能能够忍受一小时以上的down 机。这段时间的down机可以被用来做一批系统管理的进程。这样会比全天可用的系统更加有效益。

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24799772/viewspace-677677/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24799772/viewspace-677677/