BIEE_周飞版上
Document Control...................................... 错误！未定义书签。
1.安装与配置 (1)
1.1．安装 (1)
1.1.配置 (1)
2.使用Admin Tool创建模型 (3)
2.1.资料库 (3)
2.2.物理模型 (5)
2.3.逻辑模型 (13)
2.4.展现模型 (27)
2.5.一致性检查 (29)
3.Answers (33)
3.1.列 (36)
3.2.视图 (39)
4.Dashboard (48)
4.1.新建仪表盘 (48)
4.2.仪表盘控件 (51)
Open and Closed Issues for this Deliverable (58)
Open Issues (58)
Closed Issues (58)
1.安装与配置
1.1．安装
1.1.配置
OBIEE的配置主要涉及到两个文件：NQSConfig.INI和
instanceconfig.xml。
1.1.1.NQSConfig.INI
NQSConfig.INI保存于SAROOTDIR\server\Config文件夹下
(SAROOTDIR指OBIEE的主程序目录，即OracleBI)。该文件配
置了BI Server的主要参数，如Repository，缓存等等。修改这
个文件需要重启BI Server。最常见的配置就是修改使用的
Repository。形式如下：Star = samplesales.rpd,
DEFAULT;；另外，在开发期间，我们还常常是关闭掉缓存，
形式如下([CACHE]节点下)：ENABLE = YES;更多的参数
请参阅文档《Oracle Business Intelligence Infrastructure
Installation and Configuration Guide》的附录A：
NQSConfig.INI File Reference。
1.1.
2.instanceconfig.xml
instanceconfig.xml保存与SADATADIR\web\config文件夹
下(SADATADIR指OBIEE的Web层目录，即OracleBIData)。
改文件下的\web\catalog文件夹包含了BIEE Web层的定义信
息，如答复、仪表盘等。这个配置文件配置了BI Presentation
实例的一些信息。最常见的，使用了哪个catalog，通过修改下
列节点来实现
gPath>，其中xxx代表使用哪个catalog。通常将其命名为与对 应的repository同名。修改这个文件夹需要重启Oracle BI Presentation Server服务。 1.1.3.日志 在开发以及维护过程中，下列日志都显得比较重要，可以用于排错及监控系统运行情况。 安装日志：SAROOTDIR\log\install.log BI Server日志文件：SAROOTDIR\Server\log。其中有3个文件：NQQuery.log是BI Server所进行的查询的日志；NQSAdminTool.log是Admin Tool的相关日志；NQServer.log 是BI Server的运行时日志 BI Presentation Server日志： SADATADIR\web\log\sawlog0.log Job Manager日志：SADATADIR\jobmanager iBot日志：SAROOTDIR\Server\log\iBots Scheduler日志：SAROOTDIR\Server\Log\NQScheduler.log 2.使用Admin Tool创建模型 Admin Tool是开发人员用来创建BI 分析模型的工具，全称是 Oracle BI Administration Tool，通过BIEE安装后的程序组可 以访问到。资料库(.rpd文件)就是由它来编辑。 创建的模型一共有三层：物理层(Physical)，逻辑层(Business Model and Mapping)，展现层(Presentation)。 物理层定义与各类数据源的链接，如关系数据库，多维数据库， XML数据源，Excel表格等等。具体需要定义物理表的结构， 主外键关系等等； 逻辑层从物理层发展而来。需要定义具体的维表和事实表的主 外键关系。这是整个模型的核心，需要兼顾技术人员和业务人 员的思维角度。各对象的名称尽量以业务人员的角度来考虑。 展现层从逻辑层发展而来。是最终用户所看到的视图，所以， 所有对象的名称均需按照客户的要求来命名，以使他们能够完 全理解各对象的含义。展现层中的一个文件夹对应答复中所看 到的一个Subject Area，即主题区域，可理解为反映了不同的 主题。 2.1.资料库 2.1.1.创建资料库 BIEE中的资料库就是在NQSConfig.INI文件中指定RPD文件。 Admin Tool打开rpd文件后的开发环境如下： 从右到左依次为物理层、逻辑层、展现层。 资料库存放在SAROOTDIR\server\Repository目录下。 新建资料库只需要File New就可以了，给资料库取个名字： sh 2.2.物理模型 此文档将使用Orace DB10.1.2中的SH这个Schema下的数据表。 物理表即可以手工创建，也可以直接导入，我们采用导入方式。 2.2.1.导入数据源 如下： 弹出的对话框如下： 需要先选择Conn Type。这几种方式都容易理解，ODBC方式需要先在操作系统中创建ODBC数据源，稍显麻烦，我们就直接采用OCI的方式，填入TNS和USER/PWD就可以了。 接下来会选择需要导入的数据库对象，通常选择Tables和Views两种类型来筛选掉多余的数据库对象。然后具体选择需 要导入的表：维表和事实表： 进行如图的选择。选择了6张维表以及COSTS和SALES两张事实表。 导入完成之后，会弹出关于数据库连接的配置信息： 导入完成后的物理模型如下： 2.2.2.创建物理模型 物理模型中，最重要的就是创建维表和事实表的主外键关系了。先打开创建主外键关系的主界面： 成本事实表COSTS与产品维、时间维、促销品维以及渠道维均有关联，所以需要在这几张表间创建主外键关系。 注意上图中被黑框标识的那个工具栏按钮，叫做“New Foreign Key”，是用于在物理层创建主外键关联的，右边相似但是为黄色的按钮叫做“New Complex Join”，是用于逻辑层创建主外键关联的。稍后也会用到。 选择“New foreign key”之后先点击Channels再点击COSTS： 这里就是指定主外键关系的地方，正常情况下，如果我们为所有表都指定了主键，Admin Tool是能够自动识别出关联的外键的。（不过由于我们并未指定主键，所以上图中并未自动识别出外键关系，需要自己选择CHANNELS中的CHANNEL_ID）字段： 在这种情况下，会弹出下列提示： 就是告知CHANNELS中没有主键，是否创建，“是”就可以了。 物理模型创建完之后应该如下所示： 关于物理层，经常会用到的一个菜单是Update All Row Counts： 这个选项是用于更新显示数据库中表的数据行的。 执行之后的效果如下： 如果你的物理层上没有显示各表包含的数据行数，请到Tools 下的Options下： 选中如图所示的选项。 Update All Row Counts也经常用于检查与数据库的连接。 2.3.逻辑模型 2.3.1.创建逻辑层 逻辑层，既可以手工创建，也可以通过拖拽物理层自动生成。 我们结合这两种方式来做。首先采取手工方式。 新建一个逻辑模型： 还是命名为SH。 再为SALES新建逻辑表： 命名为SALES即可。 数据库中SALES这张表包含了销售量字段QUANTITY_SOLD和销售 额字段AMOUNT_SOLD。我们需要将这两个字段添加到逻辑层的 SALES表中。 直接选中物理表中的这两个字段: 拖拽到逻辑层中： 把COSTS中的UNIT_PRICE和UNIT_COST也拖到SALES逻辑表中： 接下来，需要为各事实字段设置聚合规则，由于都是设置SUM 聚合规则，所以可以同时进行，选中所有字段： 右键“Set Aggregation” 设置聚合规则为Sum： 由于选中了“All columns the same”，直接确定就可以了： 下面采取拖拽的方式，将维表CHANNELS，CUSTOMERS，PRODUCTS，PROMOTIONS，TIMES全部拖拽到逻辑层： 还有一张表：COUNTRIES，这张表保存的是国家的信息，是客户维的一个属性，所以，我们将其并入CUSTOMERS表。选中COUNTRY_ID,COUNTRY_ISO_CODE,COUNTRY_NAME,COUNTRY_REGIO N,COUNTRY_SUBREGION,COUNTRY_TOTAL拖入到CUSTOMERS表下： 接下来，为逻辑层中的各表设置主外键关系，右键选种“SH”，并选择“Business Model Diagram” “Whole Diagram”。 物理层创建主外键关系时提到过“New Complex Join”按钮，这里就用到它。先选择“New Complex Join”，再先单击维表然后事实表的顺序： 这里是不能选择主外键的具体字段的，这个字段是由物理层决定的。但是可以调整的是两表的基数，即Cardinality，这是关系型数据库设计中的概念；以及连接类型，分为Inner、Left Outer、Right Outer、Full Outer；还有Driving，是指驱动表，这是在两张表需要借助于第三张表来进行关联时，会将第三张表设为驱动表，比较少见。 点击“OK”。 依次将所有维表与事实表关联： 关闭逻辑模型展示框： 可以看到维表前面的标识变成白色的了。这是Admin Tool标识维表和事实表的方式。 2.3.2.修改逻辑层 前面提到过BIEE的逻辑层需要结合技术人员和业务人员的视角，所以，我们需要尽可能的将物理层中的晦涩的字段名称修改为业务人员能理解的名称。Admin Tool提高了一个很好的工具：Rename Wizard。在Tools Utilities下： Execute： 注意底部黑色框部分，选择“Business Model…”。并选择SH，选择“Add Hierarchy”。 点击“下一步” 再下一步： 系统性能优化方案 (第一章) 系统在用户使用一段时间后（1年以上），均存在系统性能（操作、查询、分析）逐渐下降趋势，有些用户的系统性能下降的速度非常快。同时随着目前我们对数据库分库技术的不断探讨，在实际用户的生产环境，现有系统在性能上的不断下降已经非常严重的影响了实际的用户使用，对我公司在行业用户内也带来了不利的影响。 通过对现有系统的跟踪分析与调整，我们对现有系统的性能主要总结了以下几个瓶颈： 1、数据库连接方式问题 古典C/S连接方式对数据库连接资源的争夺对DBServer带来了极大的压力。现代B/S连接方式虽然不同程度上缓解了连接资源的压力，但是由于没有进行数据库连接池的管理，在某种程度上，随着应用服务器的不断扩大和用户数量增加，连接的数量也会不断上升而无截止。 此问题在所有系统中存在。 2、系统应用方式（架构）问题(应用程序设计的优化) 在业务系统中，随着业务流程的不断增加，业务控制不断深入，分析统计、决策支持的需求不断提高，我们现有的业务流程处理没有针对现有的应用特点进行合理的应用结构设计，例如在‘订单、提油单’、‘单据、日报、帐务的处理’关系上，单纯的数据关系已经难以承载多元的业务应用需求。 3、数据库设计问题（指定类型SQL语句的优化） 目前在系统开发过程中，数据库设计由开发人员承担，由于缺乏专业的数据库设计角色、单个功能在整个系统中的定位模糊等原因，未对系统的数据库进行整体的分析与性能设计，仅仅实现了简单的数据存储与展示，随着用户数据量的不断增加，系统性能逐渐下降。 4、数据库管理与研究问题(数据存储、物理存储和逻辑存储的优化) 随着系统的不断增大，数据库管理员（DBA）的角色未建立，整个系统的数据库开发存在非常大的随意性，而且在数据库自身技术的研究、硬件配置的研究等方面未开展，导致系统硬件、系统软件两方面在数据库管理维护、研究上无充分认可、成熟的技术支持。 5、网络通信因素的问题 随着VPN应用技术的不断推广，在远程数据库应用技术上，我们在实际设计、开发上未充分的考虑网络因素，在数据传输量上的不断加大，传统的开发技术和设计方法已经无法承载新的业务应用需求。 针对以上问题，我们进行了以下几个方面的尝试： 1、修改应用技术模式 2、建立历史数据库 3、利用数据库索引技术 4、利用数据库分区技术 通过尝试效果明显，仅供参考！ 随着技术的发展，智能手机硬件配置越来越高，可是它和现在的PC相比，其运算能力，续航能力，存储空间等都还是受到很大的限制，同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由，足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时，我们应该时刻牢记，写出高效代码的两条基本的原则：（1）不要做不必要的事；（2）不要分配不必要的内存。 我从去年开始接触Android开发，以下结合自己的一点项目经验，同时参考了Google的优化文档和网上的诸多技术大牛给出的意见，整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如：Nexus o ne 对每个软件的内存限制是24M)，同时Java语言本身比较消耗内存，d alvik虚拟机也要占用一定的内存空间，所以合理使用内存，彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现，新版 （Android2.2+）将换成JIT编译器实现。性能测试显示，在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.wendangku.net/doc/a618549078.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐，世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则： 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个Stri ngBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。 一个更极端的例子是，把多维数组分成多个一维数组： int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[] ArcSDE 9.1性能调优方案 编写：李国勇 日期： 2006-11-27 版本： 1.0 密级：内部公开 北京恒华伟业科技有限公司 第一章概述 影响ArcSDE运行性能的因素比较多，对其性能的优化需要根据具体情况而定。总体上说，对ArcSDE性能影响较大的因素是：服务器硬件配置、Oracle参数配置、ArcSDE 参数配置和图层管理模式。 服务器硬件配置包括：CPU主频、物理内存大小、系统总线速度、硬盘数量、磁盘寻道时间等，硬件配置参数不是本文的重点讨论内容。 Oracle参数配置包括表空间的组织和缓冲参数配置；ArcSDE参数配置包括存储参数配置和缓冲参数配置。 本调整方案主要针对输配电GIS系统，不一定适合其它行业。 本优方案所有参数基于ArcSDE 9.1、Oracle 9.2。 1.1 总论 一．性能调优的重点在Oracle，而不在ArcSDE，一般情况下，调整ArcSDE各种参数对性能提升作用不大，ArcSDE使用安装时的默认参数即可； 二．小数据量（图层数据总量小于1G存储空间）下，优化SDE的存储的优化对性能的提升不大，ArcSDE的四个频繁访问的系统表没有必要分开存储； 三．小数据量（图层数据总量小于1G存储空间）下，用户数据存储于SDE用户下对性能的影响也不大，但是出于数据库管理的考虑，建议尽可能将这两类数据分开 存储； 四．对于输配电GIS系统，数据库db_block_size设置为8KB完全满足使用要求，没有必要调整到16KB； 五．如果图层中单个图形元素覆盖范围差异不大，没有必要建立多级Grid Index，而且一般情况下默认Grid Index设置即可满足多数情况下的性能需求； 六．如果注册了版本，建议定期对数据库进行Compress和Analyse，同时要确保undo 表空间有足够可用空间（如1G）； 七．定期对磁盘做碎片整理，以提升磁盘I/0性能。 1.2 参考文献 1．ArcSDE 9.1 Configuration and Tuning Guide for Oracle? -- ESRI 2005； 2．Managing ArcSDE 9.1 Application Servers -- ESRI 2005； 3．Cost Control: Inside the Oracle Optimizer -- Oracle Donald K. Burleson。 https://www.wendangku.net/doc/a618549078.html,/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.html Linux系统性能测试与分析 1、前言 通过对系统中和性能相关的各个环节的介绍，使大家知道出现性能问题时可以从那些方面入手去查，而分析典型应用对系统资源使用的特点，让大家对应用和系统资源的依赖有了更直观的认识。大多数的硬件性能问题主要和CPU、磁盘、内存相关，还没有遇到因为开发语言的运行效率对整个应用的性能造成影响，而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是，大多数情况下，虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。当你阅读完了这遍文档以后就会有一个对系统分析的思路。 2、性能分析的目的 2.1找出系统性能瓶颈 1.硬件瓶颈 2.软件瓶颈 2.2提供性能优化方案 1.升级硬件 2.改进系统结构 达到合理的硬件和软件配置，使系统资源使用达到平衡。但遗憾的是解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待 CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销） 3、性能相关的各个环节 3.1 硬件资源 3.1.1、CPU ⒈ 是否使用SMP。 ⒉ 单颗CPU的性能对依赖CPU的某些应用的影响很严重，比如数据库的查询处理。 3.1.2、内存 MySQL5.1性能优化方案 1.平台数据库 1.1.操作系统 Red Hat Enterprise Linux Server release 5.4 (Tikanga) ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 32位Linux服务器，单独作为MySQL服务器使用。 1.2.M ySQL 系统使用的是MySQL5.1，最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面： 1）默认存储引擎更改为InnoDB InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但MySQL5.1之前的版本默认引擎均为MyISAM，此次MySQL5.5终于将默认数据库存储引擎改为InnoDB，并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟(InnoDB plugin 1.0.7，InnoDB plugin 1.1，恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储，节约存储，提高内存命中率，并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。 Multi Rollback Segments：原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。 2）多核性能提升 Java程序性能优化方案 StringTokenizer比String.split()方法效率高 更优化的方式 Java代码 while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } 比String.startsWith和endsWith性能更优的方式：Java代码 int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c'); int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c'); StringBuffer(int capacity)指定初始容量可以减少扩容的操作 服务器性能优化 1、Apache+tomcat集群方式 服务器基本设置：1个apache集成二个tomcat。 安装apache http server省略，访问地址为http://127.0.0.1:8081 安装tomcat，解压apache-tomcat-6.0.20.zip，测试时我是把两个tomcat分开放在不同的虚拟机，其中一个是和apache同一台虚拟机。 两个tomcat分别命名为worker2和worker3 先说tomcat.worker2的配置： server.xml 第一步：配置http监听端口，这里端口设为8079,该步骤非必要，只要不冲突就行了。 你是否正打算优化hashCode()方法？是否想要绕开正则表达式？Lukas Eder介绍了很多简单方便的性能优化小贴士以及扩展程序性能的技巧。 最近“全网域（Web Scale）”一词被炒得火热，人们也正在通过扩展他们的应用程序架构来使他们的系统变得更加“全网域”。但是究竟什么是全网域？或者说如何确保全网域？扩展的不同方面 全网域被炒作的最多的是扩展负载（Scaling load），比如支持单个用户访问的系统也可以支持10 个、100个、甚至100万个用户访问。在理想情况下，我们的系统应该保持尽可能的“无状态化（stateless）”。即使必须存在状态，也可以在网络的不同处理终端上转化并进行传输。当负载成为瓶颈时候，可能就不会出现延迟。所以对于单个请求来说，耗费50到100毫秒也是可以接受的。这就是所谓的横向扩展（Scaling out）。 扩展在全网域优化中的表现则完全不同，比如确保成功处理一条数据的算法也可成功处理10条、100条甚至100万条数据。无论这种度量类型是是否可行，事件复杂度（大O符号）是最佳描述。延迟是性能扩展杀手。你会想尽办法将所有的运算处理在同一台机器上进行。这就是所谓的纵向扩展（Scaling up）。 如果天上能掉馅饼的话（当然这是不可能的），我们或许能把横向扩展和纵向扩展组合起来。但是，今天我们只打算介绍下面几条提升效率的简单方法。 大O符号 Java 7的ForkJoinPool和Java8 的并行数据流（parallel Stream）都对并行处理有所帮助。当在多核处理器上部署Java程序时表现尤为明显，因所有的处理器都可以访问相同的内存。 性能分析与调优的原理 最近一直纠结性能分析与调优如何下手，先从硬件开始，还是先从代码或数据库。从操作系统（CPU调度，内存管理，进程调度，磁盘I/O）、网络、协议（HTTP，TCP/IP），还是从应用程序代码，数据库调优，中间件配置等方面入手。 单一个中间件又分web中间件（apache、IIS），应用中间件（tomcat、weblogic、webSphere）等，虽然都是中间件，每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。 常看到性能测试书中说，性能测试不单单是性能测试工程师一个人的事儿。需要DBA 、开发人员、运维人员的配合完成。但是在不少情况下性能测试是由性能测试人员独立完成的，退一步就算由其它人员的协助，了解系统架构的各个模块对于自身的提高也有很大帮助，同进也更能得到别人的尊重。 再说性能调优之前，我们有必要再提一下进行测试的目的，或者我们进行性能测试的初衷是什么？ 能力验证：验证某系统在一定条件具有什么样的能力。 能力规划：如何使系统达到我们要求的性能能力。 应用程序诊断：比如内存泄漏，通过功能测试很难发现，但通过性能测试却很容易发现。 性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。 一、一般系统的瓶颈 性能测试调优需要先发现瓶颈，那么系统一般会存在哪些瓶颈： 1、硬件上的性能瓶颈： 一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。 2、应用软件上的性能瓶颈： 一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。 例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。 3、应用程序上的性能瓶颈： 一般指的是开发人员新开发出来的应用程序。 例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。 4、操作系统上的性能瓶颈： 一般指的是windows、UNIX、Linux等操作系统。 例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。 5、网络设备上的性能瓶颈： 一般指的是防火墙、动态负载均衡器、交换机等设备。 例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。 性能测试出现的原因及其定位十分复杂，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员/DBA/运维人员一起定位性能瓶颈。 二、一般性能调优步骤 一般性能问题调优的步骤： 1、步骤一：确定问题 应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。 SQL Server 系统性能调优解决方案 前言 近几年,医药流通市场经历了激烈的震荡,导致行业逐步成熟和企业的快速变革,差异化经营成为众多医药流通的竞争选择。时空产品在中国医药流通企业的发展过程中得到了广泛且深入应用,大量的客户化开发和定制支撑了企业管理中横向和纵向的变化，很好的适应了企业在发展过程中不断变化的需求。 对于数据库管理系统的使用，很多用户都面临着一个很棘手的问题：系统效率下降。产生效率下降的因素是多方面： 1.硬件问题 2.软件问题 3.实施问题 正因为产生效率下降的因素很多，所以如何去查找原因成为我们首要关注的问题，时空公司也处在积极探索过程中。时空公司在解决一些客户问题的过程中积累了一些方法和思路，归纳总结后呈现给体系内的技术人员，本方案就系统效率调整所必需的基础知识、方法、技巧等几个方面进行阐述，从而让技术人员能够快速定位问题，解决问题，为合作伙伴提供优质，快捷的服务。 索引简介 索引是根据数据库表中一个或多个列的值进行排序的结构。索引提供指针以指向存储在表中指定列的数据值，然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似，通过搜索索引找到特定的值，然后跟随指针到达包含该值的行。 索引键：用于创建索引的列。 索引类型 聚集索引： 聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储，因此聚集索引对查找行很有效。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别（叶子节点）。只有当表包含聚集索引时，表内的数据行才按排序次序存储。如果表没有聚集索引，则其数据行按堆集方式存储。 聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻。例如：如果应用程序执行的一个查询经常检索某一日期范围内的记录，则使用聚集索引可以迅速找到包含开始日期的行，然后检索表中所有相邻的行，直到到达结束日期。这样有助于提高此类查询的性能。同样，如果对从表中检索的数据进行排序时经常要用到某一列，则可以将该表在该列上聚集（物理排序），避免每次查询该列时都进行排序，从而节省成本。 叶节点（包括数据） 非聚集索引 非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值，并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。如果一个表只有非聚集索引，它的数据行将按无序的堆集方式存储,非聚集索引可以建多个。 前端优化方案 1.提升页面静态资源加载速度 (1) 1.1减少Http请求 (1) 1.1.1项目首页、访问量非常大的页面有自己单独css内容 (1) 1.1.2移除重复的脚本及样式，统一网站资源（js库、css库）的使用。.2 1.1.3整理优化并合并现css文件及js文件，将所有的css文件以及js文件 分为base、common、page三层 (2) 1.2压缩静态资源文件，减少文件体积大小 (2) 1.2.1采用CSS Sprites技术将页面内所有背景小图标整合到一张图片。 .. 2 1.2.2不要在HTML使用太多大图像 (2) 1.2.3采用开源工具来压缩减小css及js文件体积 (2) 1.3内嵌图像。 (3) 1.4静态资源尽量合并到少数几个域名访问，减少DNS查询 (3) 2.加快页面的渲染展示速度 (3) 2.1 Css和js文件的位置 (3) 2.2规范img标签的使用 (3) 2.3精简页面标签，减少DOM元素 (4) 2.4规范Css代码 (4) 3.服务器端静态资源访问优化 (4) 3.1服务器部署时通过web服务器及应用服务集群配置，让静态资源通过web 服务器提供访问，提高静态资源并发访问效率 (4) 3.2通过在web服务器配置静态资源的缓存以及压缩策略，提高用户访问速度. (4) 3.3通过第三方网络静态资源缓存服务(CDN)，提高网站访问速度，提升用户访 问体验。 (4) 1.提升页面静态资源加载速度 1.1减少Http请求 1.1.1项目首页、访问量非常大的页面有自己单独css内容 静态页面生成时直接生成到文件中，动态文件的话在模板文件中include。 设计说明 方案设计说明内容提要 一．工程概况 二．设计依据 三．门窗性能设计指标及保证措施 四．选用材料及设计说明 方案设计说明具体内容 （一）工程概况 1．工程简况 工程名称：博鳌金湾C3地块铝合金门窗制作安装工程 工程建设地点：琼海市博鳌镇龙博大道东侧 建设单位：琼海华悦实业有限公司 本工程抗震设防烈度为7度。基本风压W0=0.85KN/m2。 使用年限：50年 2．工程装饰范围 本工程所有铝合金门窗为：M987系列单轨推拉门、M987系列双轨推拉门、50系列平开门、50系列平开窗、50系列上悬窗、987系列推拉窗。 （二）设计依据 1．设计依据 ·基本风压值：W0=0.85KN/m2。 ·地震设防：7度。 ·地区粗糙度：B类。 ·业主下发的招标图纸。 ·业主下发的招标文件。 2．技术法规、标准与规范 2．1 幕墙门窗设计规范 ·《建筑幕墙》GB/T 21086-2007 ·《玻璃幕墙工程技术规范》 JGJ102-2003 ·《金属与石材幕墙工程技术规范》 JGJ113-2001 2．2性能检测、验收标准 ·《玻璃幕墙工程质量检验标准》 JGJ/T139-2001 ·《建筑幕墙物理性能分级》 GB/T15225-1994 ·《建筑幕墙空气渗透性能测试方法》 GB/T15226-1994 ·《建筑幕墙风压变形性能测试方法》 GB/T15227-1994 ·《建筑幕墙雨水渗透性能测试方法》 GB/T15228-1994 ·《建筑外窗抗风压性能分级及检测方法》 GB/T7106-2002 ·《建筑外窗气密性能分级及检测方法》GB/T7107-2002 ·《建筑外窗水密性能分级及检测方法》GB/T7108-2002 一、操作系统调优 对于操作系统优化来说，是尽可能的增大可使用的内存容量、提高CPU的频率，保证文件系统的读写速率等。经过压力测试验证，在并发连接很多的情况下，CPU的处理能力越强，系统运行速度越快。。 【适用场景】任何项目。 二、Java虚拟机调优 应该选择SUN的JVM，在满足项目需要的前提下，尽量选用版本较高的JVM，一般来说高版本产品在速度和效率上比低版本会有改进。 JDK1.4比JDK1.3性能提高了近10%-20%，JDK1.5比JDK1.4性能提高25%-75%。因此对性能要求较高的情况推荐使用JDK1.6。 【适用场景】任何项目。 三、Apache集成Tomcat Web服务器专门处理HTTP请求，应用服务器是通过很多协议为应用提供商业逻辑。虽然Tomcat也可以作web服务器，但其处理静态html的速度比不上Apache，且其作为web服务器的功能远不如Apache，因此把Apache和Tomcat集成起来，将html和Jsp的功能部分进行明确分工，让Tomcat只处理Jsp部分，其他的由Apache，IIS等web服务器去处理，由此大大提高Tomcat的运行效率。 如果一个项目中大量使用了静态页面、大量的图片等，并有有较大的访问量，推荐使用Apache集成Tomcat的方式来提高系统的整体性能。 Apache和Tomcat的整合有三种方式，分别是JK、http_proxy和ajp_proxy.其中JK方式是最常见的方式，JK本身有两个版本分别是1和2，目前1最新版本是1.2.8，而版本2早已经废弃了。http_proxy是利用Apache自带的mod_proxy模块使用代理技术来连接Tomcat。Ajp_proxy连接方式其实跟http_proxy方式一样，都是由mod_proxy所提供的功能。只需要把配置中的http://换成ajp://,同时连接的是Tomcat的AJP Connector所在的端口。 相对于JK的连接方式，后两种在配置上比较简单的，灵活性方面也一点都不逊色。但就稳定性而言不像JK这样久经考验，所以建议采用JK的连接方式。Apache+JK+Tomcat配置： 使用到的两个配置文件分别是：httpd.conf和mod_jk.conf。其中httpd.conf是Apache服务器的配置文件，用来加载JK模块以及指定JK配置文件信息。mod_jk.conf是到Tomcat服务器的连接定义文件。 【部署步骤】 1.安装Apache服务器 2.部署Tomcat 3.将mod_jk.so拷贝到modules目录下面 4.修改httpd.conf和mod_jk.conf 【适用场景】大量使用静态页面的应用系统。 四、Apache和Tomcat集群 对于并发要求很高的系统，我们需要采取负载均衡的方式来分担Tomcat服务器的压力。负载均衡实现大概有四种：第一是通过DNS，但只能简单的实现轮流分配，不能处理故障；第二是基于MS IIS,windows 2003 server本身就带了负载均衡服务；第三是硬件方式，通过交换机功能或专门的负载均衡设备来实现；第四种是软件的方式，通过一台负载均衡服务器进行，上面安装软件。使用Apache Httpd Server做负载均衡器，Tomcat集群节点使用Tomcat就可以做到上述第四种 (一) --方案和原则 一.方案演化 历经一周多的性能测试和性能调优工作接近尾声了，这里总结下一周多的进展和调优情况。首先声明一点，我没有性能调优方面的经验，很多方法都是请教了大牛和网上查找得到的答案，感觉自己进步了很多。 1.1封装框架 刚开始对于压力测试采用的自己先的压力测试框架，就是启N多线程。然后调用远程服务器进行压力测试，调用完成后有响应时间等统计信息（见pc2性能测试方案篇） 优点：压力测试简单，不需要写太多代码。 缺点：和客户端性能有很大关系，在不同客户端上起线程的速度肯定不一样，这样就导致了测试出来数据价值不是很大。 1.2 windows下Jmeter 进行测试 优点：统计信息全面，较为切近的模拟并发情况。 缺点：由于windows下客户端性能差别较大，启动线程并没有linux下快，会导致发送的请求数有限，tps上不去的。 1.3 linux下Jmeter 进行测试 优点：较好的模拟并发情况，并发效率较高。 缺点: 使用较为复杂，如果使用nmon更需要一定的配置基础。 二.调优原则 1. 贵在坚持，不可以一簇而就，别人的经验通常是针对特定系统，特定环境的，不可以照搬，不可以不知所以然。 2. 细节决定成败，调优的准备工作要做好，消除外部因素对测试造成的影响。 3. 可以按照先整体-后部分-再整体的思路进行测试，先整体是看看整体哪块有问题，找出比较慢的部分进行重点测试和调优，然后再整体测试保证所有应用并发是没有问题。 (二) --方法和步骤 1. webTrace跟踪数据库SQL 瓶颈：是否走到索引，是否sql执行计划最优等。 2. jProfile跟踪那块代码消耗cpu较多，（jprofile使用方法见工具篇）。 3. kill -3进行线程查看，如果有大量BLOCKED线程，则说明有问题，如果RUUNNBLE的线程很多都是在执行一样的操作那就说明这部分比较消耗资源，要做优化。 4. apache调优，对apache的各个参数进行调优，最终使apache参数对应于当前系统和当前并发量最优。所以调优的并发量参考数据要经过计算，不可以认为响应时间越快，tps越高越好。（经验告诉我们apache由于是多进程多线程的，我们采用的是apache 和jboss一直链接的情况，也不会消耗太多性能，所以还是apache好些。其在并发处理方面的能力要显著高于JBOSS） 5. jvm 调优：对于jboss配置的jvm 垃圾回收机制进行调优，让其垃圾回收更加及时高效。 6. 内存使用调优，使用jconsole 进行监控，如果内存直线上升，最终得不到稳定，则说明有可能存在内存泄露等问题。 7. linux 内核调优。这部分难度较高，一般不需要，如果以上步骤不能满足性能要求，考虑此步骤。 (三) --遇到的问题(数据库) 1. Webtrace 分析sql 性能，发现 userPermissionService.listVAccountIdsByUserIdAndProductCode 是数据库未分析数据，执行方案是基于开销的方式，导致执行计划未走到索引。后来是走的索引，但是仍然较慢。 分析： K3系统数据库索引性能优化解决方案（具体应用篇） --重建索引速度较慢，请在系统空闲时间进行 DBCC DBREINDEX(t_icitem) DBCC DBREINDEX(t_item) DBCC DBREINDEX(t_itemclass) DBCC DBREINDEX(t_itemright) DBCC DBREINDEX(t_user) DBCC DBREINDEX(t_group) go if not exists(select 1 from sysindexes where name='ix_group_fgroupid') create index ix_group_fgroupid on t_group(fgroupid) go if not exists(select 1 from sysindexes where name='ix_itemright_ftypeid') create index ix_itemright_ftypeid on t_itemright(ftypeid) go 1 SQL Server调整 当用户使用K3系统一段时间以后，发现系统的响应时间越来越长。这种情形往往是由于账套数据库缺乏维护引起的。缺乏维护的数据库会存在过多地碎片、过期的统计、隐含着可能的错误查询结果的数据库的逻辑和物理的不一致性，这些都会直接影响系统的性能。这里介绍解决上述账套数据库性能问题常用的方法。 1.1 使用DBCC语句发现和解决上述问题。 DBCC: 数据库一致性检查器。 打开SQL 查询分析器，执行如下语句。 u DBCC SHOWCONTIG 显示指定表的数据和索引的有关数据碎片的信息DBCC SHOWCONTIG(表名[，索引名]) 在有大的改动的表，引入数据的表，或者引起低效查询的表上使用该语句。例：DBCC SHOWCONTIG（’T_ITEM’） u DBCC DBREINDEX 重建指定数据库中表的一个或多个索引。 例1：重建某个索引 DBCC DBREINDEX ('T_ITEM', uk_item2, 80) 例2：重建所有索引 DBCC DBREINDEX ('T_ITEM',’’,80) u DBCC SHOW_STATISTICS 显示指定表上的指定目标(例如一个索引名称))的当前分布统计信息。这些统计信息是被SQL Server查询优化器使用的DBCC SHOW_STATISTICS(表名，目标) 例：DBCC SHOW_STATISTICs('t_item','pk_item') u sp_updatestats & UPDATE STATISTICS 更新统计信息；sp_updatestats 对当前数据库中所有用户定义的表运行UPDATE STATISTICS. 使用UPDATE STATISTICS 语句的时机：在一个空表上创建一个索引，然后在以后应用它。执行TRUNCATE TABLE语句，然后在以后重新应用该表。通过使用FULLSCAN或SAMPLE选项请求明细的索引统计信息。 例1. UPDATE STATISTICS T_ITEM 例2. UPDATE STATISTICS T_ITEM(PK_ITEM) 例3. USE AIS20011203150410 EXEC sp_updatestats u DBCC CHECKTABLE 检查指定表或索引视图的数据、索引及text 、ntext 和image 页的完整性。如果你相信一个指定的表可能被破坏了，这条命令非常有用。 web项目性能优化方案收藏 性能优化有两个用途：提高页面的相应速度和减少服务器的开销 以下是最近几天在网上搜索的资料，并结合我们自己的项目做了测试，感觉我们的Web工程在性能上还有很大的提升空间！一下介绍几点优化的方案，仅供参考！ 1、jsp预编译 jsp页面的预编译有三种： a手动方法，部署完毕后全局访问一遍所有页面 b通过shell脚本把生成的.class文件直接发送到现场 c通过weblogic.xml配置的预编译在现场部署时完成预编译 以下结合我们项目介绍一下各自优缺点 A是我们现在所用的方法，部署完毕后现场工程师访问一个我们提供的页面，通过Ajax系统遍历全部页面。缺点：不适用于集群部署！ B 配合5中的类加载也是大型项目最常用的方式，代码安全性好和访问速度 快是最大的优点！但是他的缺点也很明显：页面更新不灵活。 C 这个办法实现简单，可以提高第一次访问页面的速度，但是缺点比较严重： 大大增加了Weblogic部署应用时的负担，而且不会预编译WEB-INF下的文件（Oracle给的官方说法也是绕过WEB-INF的） 可行方案（张翔赞助）：在B方案的基础上还是使用默认的加载jsp文件机制，这样发包前我们自己替现场的Weblogic完成了预编译的过程，降低了Weblogic部署的负担，而且能灵活修改jsp文件 2、控制JavaScript Javascript是不标准HTML内容的最大来源，虽然实现了很多非常炫的效果但是却放缓了页面加载的时间。而且经常使用 window.document.getElementById("")也会影响速度。 可行方案： A 把页面验证拿到内部结合我们的common页面来使用，这样验证处理更灵 活，更美观，页面加载也更快。 B 做一个缓存来处理大量使用到document的页面，如： Var rootDoc = window.document; rootDoc. getElementById("").value=….. rootDoc. getElementById("").value=….. C 能用innerText的尽量使用innerText，减少innerHTML的使用 3、控制jsp时间戳校验频率 Webloic提供了控制jsp更新频率的配置项 性能优化解决方案(QoS) 应用场景 随着网络应用的飞速发展，P2P应用的出现，网络流量模型、应用模型都发生了质的变化，对网络中的关键应用类型、关键用户业务的服务质量保证需求也变得越来越迫切。统一集中的QoS 策略管理以方便、快捷的实现全网端到端的QoS业务保证，成为每个网络管理员不可或缺的需求。 作为业界领导的网络设备厂商，H3C通过多年对网络的深刻理解和积累，在流量分析的基础上，推出了性能优化解决方案(QoS)，为客户提供了图形化的全网端到端QoS策略管理方案，真正为管理员做到了QoS服务保证所见即可得，成为业界极少数几个能提供完整QoS策略管理解决方案的厂商之一。 解决方案介绍 H3C性能优化解决方案(QoS)实现了流量展示分析、QoS策略执行、QoS策略检测一个完整的业务管理流程。管理员可以借助流量展示清晰的了解网络流量模型，发现网络带宽瓶颈、应用流量瓶颈和用户流量瓶颈： 图1 带宽利用率 图2 应用流量分析 图3 用户流量分析 根据流量分析的结果，管理员可以借助图形化的QoS配置工具，制定全网的QoS策略，完成对指定的关键流量端到端的QoS服务保证配置，实现QoS业务在图形化操作界面上的“所见即可得”： 图4 全网QoS端到端管理 完成QoS策略部署后，H3C性能优化解决方案为管理员提供SLA（服务水平协议）工具，可以实现对QoS策略实施效果的监测审计，并输出图形报表，确保关键的业务得到了指定的服务保证 水平： 图5 SLA监测QoS策略实施效果 方案优势 ◆从分析到执行，再到审计监测，完整的业务流程解决方案 为管理员提供的不是一个简单的配置工具，而是一个从发现问题到分析问题再到解决问题的完整业务流程解决方案，将工作流程融入于管理工具之中。 ◆向导式的操作界面，方便管理员完成端到端的QoS服务保证策略，所见即可得 友好的操作界面，管理员可以直接通过图形界面完成全网QoS策略的预制，并可直接下发网络设备完成配置，真正实现端到端QoS策略，所见即所得。 ◆性能优化与网络拓扑、告警、用户信息等联动，形成融合统一管理方案 ?性能优化与网络拓扑关联，异常流量通过拓扑直观展示 ?与网络告警关联，自学习网络流量基线，当网络流量与基线模型不符时，短信、邮件 等方式发送告警信息给管理员 ?与网络接入用户关联，网络会话流量直接定位到用户信息，方便管理员识别流量系统性能优化方案
安卓性能优化方案
SDE性能调优方案
22提供性能优化方案---Google-Code
MySQL5.1性能优化方案
Java程序性能优化方案
服务器性能调优
10种java性能优化方案
性能分析与调优的原理及原则
SQL2008系统性能优化解决方案
前端性能优化方案
方案设计说明及优化建议
Tomcat性能调优方案
性能调优step by step
K3 wise erp 数据库索引性能优化解决方案
web项目性能优化方案
性能优化解决方案(QoS)