传送门☞轮子的专栏☞转载请注明☞http://blog.csdn.net/leverage_1229

5报表性能

为不影响系统的整体性能，报表统计将通过报表服务来解决可能产生的性能问题。
报表服务是运转在服务端的报表服务程序，用来解析报表模板，取得报表数据，生成报表，提供对报表运行、部署和维护的强大支持。报表服务既可以作为独立的服务程序运行，也可以以嵌入运行模式，和用户的应用一起部署到应用服务器上。报表服务的实现完全遵循J2EE 规范，可以部署在任何遵循J2EE 规范的应用服务器上，包括WebLogic 、WebSphere、、Oracle 9i应用服务器等主流应用服务器，从而实现应用服务器的无关性。报表服务通过JDBC访问数据库，所以它可以应用在任何支持JDBC规范的数据库环境中，包括Oracle等主流数据库系统，从而实现数据库的无关性。
报表服务具有如下特性：

5.1高性能

在许多报表解决方案中，巨大的报表会消耗报表服务器的可用内存，从而使得其它较小的报表执行失败。因此把报表单独作为一个服务，包含一个可扩展的报表引擎，它限制了内存的使用和与非内存限制的报表的冲突。报表性能也通过按需处理和基于实时的渲染而得到了优化。

5.2缓存

报表服务通过提供了报表的缓存进一步提高了性能。通过缓存经常使用相同的参数值进行访问的报表，以降低渲染报表所需要的时间和空间费用。在报表处理之后，缓存拷贝就可以用于其他后来访问同一个报表的用户而不需要再作任何处理。有了这个方法，如果多个用户打开这个报表，只有第一个请求会产生报表处理过程。然后这个报表被缓存起来，其余的用户查看到的是这个缓存的报表。

5.3快照

报表服务支持快照报表的创建，快照报表是按照一个预先计划的时间间隔进行渲染，然后用于用户查看。快照类似于缓存报表;主要的区别是快照通常是按照一个计划定期的创建的。像缓存报表一样，快照可以通过定期生成复杂或耗时的报表来提高报表性能，并使得用户可以查看预先生成的快照而不是按需生成报表。快照报表还是一个可维护历史报表的有用的方法，因为每一个报表实例都反映了快照产生时的数据情况。

5.4多种文件格式

用户需要能够访问和共享采用他们最熟悉的格式的报表。报表服务支持渲染最常见的文件格式，包括HTML、PDF、CSV、XML和图像 (TIFF)，报表的格式是部分可编辑的，使用户可以基于这些报表创建定制的文档。

5.5多种查询方式

因为报表时基于关系数据库的，所以可以很方便的构造出SQL查询方式，按条件或组合条件查询，可以对各要素进行模糊查询，可以将查询结果分类排序、分析，可以将查询结果打印，可以将查询结果输出EXCEL文件。

5.6异步发布数据

报表服务支持远程模式，这种模式下报表运行在一个远程报表服务的报表服务器上，将需要提交的报表通过异步的方式提交给报表服务，并通过报表生成台生成。

6海量数据处理

性能保障是系统设计的重要环节，主要是保证在实际使用中保障系统的性能。主要考虑的因素是大数据量和多客户端的情况。系统压力的产生主要在于海量数据对底层系统的压力以及大量客户端对应用服务的压力。
在采用大集中的方式下，系统的数据量非常大。每天产生的GB级的数据会对系统产生两个方面的压力：数据的传输会占用网络带宽，另外数据的存储会占用空间。
在数据的传输方面，如果数据量比较大的时候，会占用网络带宽，在网络是多个业务共享使用的时候，会阻碍其他业务的进行，对此系统在网络传输方面设计成可以指定占用带宽的方式，在业务繁忙的情况下，可以为其他业务释放一些网络资源。
在数据的存储方面，我们的系统的存储设计对硬件是完全透明的，用户可以根据数据量的大小，性能的要求决定采用何种存储方式。

6.1大批量影像压缩算法

对于图像压缩而言，可以根据压缩的效率自底向上可以分为二进制压缩、像素级压缩、内容级压缩等不同的层次。然而现有对票据类图像的压缩大多采用是JPEG等压缩格式，现有技术存在的最大问题是没有考虑到图像之间的内容关联关系。在票据类等内容相关的影像上，因为没有计算图像内容的相关性，很难实现高效的压缩。对于几百万甚至上千万个图像的压缩，目前来说并没有更有效的压缩方法。
鉴于上述情况，建议采用更高的压缩算法如NKZ，其目的是针对目前海量影像在传输、存储方面的难题，利用票据类影像的特征、在进行亚像素级和模板聚类的海量信息抽取和分析基础上、对海量影像进行高压缩比、高质量且高速的压缩算法及算法。

6.2大批量影像传输算法

目前来说，影像传输使用较多的是FTP协议，但是这里面存在着连接的问题。FTP在传输的过程中，每张影像需要建立一次数据连接。在数据集中模式下，服务器需要一天要存储上百万张影像，实现10次业务中转需要上千万次的连接；系统每次建立连接的时间至少为10ms；以目前作业时间来计算，需要将近27小时，远大于我们每天8小时的工作时间。因此出现了性能的瓶颈。虽然我们可以通过建立多台FTP服务器来实现均衡，但是不能从本质上解决传输连接时间过长的问题。例如，在东莞银行中，每天仅30万张票据，有3个岗位扫描，5台识别服务，10个补录岗位，每一笔业务需要传输100~500张票据。每天的影像在网络中的传输次数就需要上百万次连接请求，仅连接时间就占去了3个多小时，网络带宽仅占有了30%，造成了资源的浪费。
针对目前银行前后台分离业务系统中的影像传输过程中，票据影像文件小、数量大、连接耗时等问题，采用一种大批量影像数据传输的解决方案。其原理是连接复用，目的是减少连接建立时间，充分利用带宽，以满足大批量影像传输的性能需求。

6.3异步处理机制

系统采用的是多层结构开发。客户端没有业务逻辑，所有的业务逻辑都放在服务器端处理。系统采用了连接池，对象池，线程池技术，对服务器端的资源进行重用。在多个用户使用的时候，能够显著地提高系统的运行效率。

某大型银行深化系统之十八：性能设计之三相关推荐

某大型银行深化系统之十七：性能设计之二
传送门☞轮子的专栏☞转载请注明☞http://blog.csdn.net/leverage_1229 4流水线性能评估 4.1吞吐率TP 吞吐率是指单位时间内流水线所完成的任务数或输出结果的数量. 4 ...
某大型银行深化系统之十四：技术架构
传送门☞轮子的专栏☞转载请注明☞http://blog.csdn.net/leverage_1229 技术架构在上述功能架构中,除了核心层外,应用层及服务层都包括了用户UI界面,因此服务中包括了Ma ...
某大型银行深化系统之二：设计策略
传送门 ☞ 轮子的专栏 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229 1糅合技术(Mashup) Mashup是糅合,即一种交互式Web应用程序,它利用了从 ...
某大型银行深化系统之二十：异常规范
传送门 ☞ 轮子的专栏 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229 1异常抛出与捕捉规则 1.1任何抛出异常的方法必须先声明异常 {// Construc ...
某大型银行深化系统技术方案之十六：业务应用层
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 面向完整的业务应用处理.对于不同类型的业务应用,定制其特有的处理流程和不同基础服务的组合 ...
某大型银行深化系统技术方案之十五：服务层之服务调用
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
某大型银行深化系统技术方案之十四：服务层之服务调度机制
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
某大型银行深化系统技术方案之十二：服务层之服务分类
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
某大型银行深化系统技术方案之十：核心层之任务调度
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 核心层核心层主要提供后台业务集中处理中最基本.共性的信息处理.流程调度和相关的管理功能 ...

某大型银行深化系统之十八：性能设计之三