永洪bi报表对服务器配置要求

永洪bi报表对服务器配置要求：

服务器配置产品型号：I2496286S-E。

服务器配置产品类型：双路四核机架式服务器。

服务器配置处理器：Xeon E5620。

服务器配置内存：2G DDR3 REG ECC。

服务器配置创建虚拟目录：

服务器配置若要从主目录以外的目录发布信息，则就要创建虚拟目录了，虚拟目录是指物理上未包含在主目录中的目录，但浏览器却认为该目录包含在主目录中。

服务器配置创建的方法：比如你的主目录在“c:\Inetpub\wwwroot”下，而你的网页文件在“E:\All”中，你就可以创建一个别名为test的虚拟目录。

就可以这样来创建：在“默认Web站点”上单击右键，选“新建→虚拟目录”，依次在“别名”处输入“test”，在“目录”处输入“E:\All”后再按提示操作即可添加成功。

一、 BitComet 设置： ( 未加说明的参数，请保持原始设定值不变 )

1. 运行 BitComet 0.56 ，打开自己的 BitComet 的 " 选项 " 一栏，点击第一栏 " 网络连接 "

全局最大下载速度 无限制 调整到 1000(2M 以下用户 1000 是个不可达到的数字，所以可行 ) 。

全局最大上传速度 无限制 调整到 40 ( 根据个人情况合理选择，这是我的建议数 ) 。

监听端口 建议不要和 6881-6889 16881-16889 重复，个人感觉 19770-22000 之间比较好。

( 当然你映射了端口，那么就以你映射的监听端口为准，不需改动 ) ，装了防火墙的用户在你的防火墙里面打开你的监听端口。

2. 点击任务设置，目前此项里面的参数暂时保持不变，在后来的调整中需要用到其中的“每任务最大上传速度”

3. 点击界面外观

最多显示 peer 数量 改到 1000

4. 点击高级设置

如果多少分钟之内不能连接则添加备用 Tracker:30 30 改到 0

备用 Tracker 列表

5. 点击网络连接

每任务最大连接数：改到 1000 。

每任务保持连接数：改到 50 。

全局保证上传连接数：改到 10 。

连接发起间隔： 改到 150 或 100 。

最大同时尝试的 TCP 连接个数： 改到 1000 。

是否允许通过 UDP 实现内网互连：内网设定“允许” 公网设定“禁止”。

6. 点击 IP 规则

下载任务每 IP 最大允许连接数 : 改到 20

上传任务每 IP 最大允许连接数 : 改到 5

内网的用户把“允许向服务器报告内网 IP 便于子网内连接”打上钩

7. 点击磁盘缓存

256M 内存配置

磁盘缓存最小值： 6M 磁盘缓存最大值： 30M 减小磁盘缓存当空闲物理内存低于： 50M 在最大最小值范围内自动调整缓存大小上打上钩。

二、下载过程的参数调整

热门种子：

1. 进行完上面的设置，请您下载一个热门种子 ( 种子数超过 20 ，用户连接数超过 200) ，单独开始这一个下载。

2. 下载时您可以看见连接的种子和用户在不断增加，上传下载速度缓慢增加，等速度达到您平时正常下载速度的 1/2 ，连接数大于 50 ，种子数 1 个以上时 ( 大约需要 5-10 分钟 ) ，点击“任务设置”把“每任务最大上传速度”改到 10-20 之间一个数，继续下载。

3. 2 分钟后，如果你的速度起来了，并且起伏不大相对稳定，请保持。如果你的速度没有起来，可以用以下 2 种办法：

a. 把每任务最大上传继续以每次 2K 的速度调小；

b.a 不起作用说明你的调整时间不对，把“每任务最大上传速度”恢复到“无限制”过段时间再调小它。

冷门种子

冷门种子在您进行调小“每任务最大上传速度”时可能效果不大，如果有效果，请保持。无效果，就不要设置“每任务最大上传速度”或者设高点比如 25-30 。

注意事项：

1. 想知道自己是内网还是外网的看自己的 IP ， 10.x.x.x ， 192.168.x.x 都是内网，看不见远程的基本也是内网。

2. 外网用户如果 BitComet0.56 下载效果不理想可以试用 BC 以前版本或者贪婪 abc 、比特精灵等。

3. 限制上传的朋友下载完毕后，强烈要求取消全局上传限制做种 3 个小时以上。

4. 热门种子下载时，尽量只下载一个文件，这样才让你享受到 BitComet 的飞速快感。

5. 上传参数的选取，要依据自己的网络情况，仔细调整，如果我说的参数不适合您，请您自己多琢磨，仔细进行微调。

我的调节经验：

一个任务开始下载几分钟以后，就把上面第 5 点方法的“每任务保持连接数”由“ 1000 ”改为“自动调整”，全局最大下载速度再改回“无限制”，一会你就会发现， BT 的速度明显比调节前快了 ( 我的现在一般是 170-180K, 比以前快了近 50K ！ ) ；如果变化不大，再在两个办法之间来回设置一下。

大部分的BI工具都是基于B/S 架构的。每一次来自浏览器的点击，都是通过HTTP协议像服务器发送一次 Request 请求，一次报表的查询本质上发送了一条 SQL 查询命令到了应用服务器端通过程序翻译再到数据库服务器做了一次数据查询动作。

如果这个 SQL 查询本身就比较复杂，底层数据模型建立的又不好，或者在数据库服务器硬件环境配置本身也不好的情况下，这条SQL的执行可能就需要花费很长的时间。这个是第一个时间损耗的点。第二个点就是SQL的查询可能返回了大量的数据，比如几十万、上百万、上千万、上亿的数据，这个数据最后打包通过HTTP协议Response响应返回，需要通过网络返回到Browser 浏览器端，几十万的数据可能有上百兆MB，上百万、上千万的数据可能是几百兆（MB）甚至一个GB的数据。大家试想一下平时下载个电影需要多长时间，下载一个几百兆的文件需要多长时间，这个还跟网络带宽有很大的关系，这个是第二个时间损耗的点。

数据返回到浏览器前端，在图表展现的时候，如果写了很多复杂的表达式、聚合函数，数据需要消耗本地浏览器所在电脑大量的内存来完成数据的计算。前端指标计算、条件表达式和各类聚合函数设计的越多，需要的时间就越长，这个就是第三个时间损耗的点。最后就是页面的渲染，图表越多、结构越复杂、列越多，数据渲染通过HTML组织到最后的呈现时间就越长，这个就是第四个时间损耗的点。

到最后页面全部加载完成，HTTP 请求终止与服务器断开连接。

在这个过程中，大量的时间损耗主要集中在数据查询、大数据量的返回，以及基于大数据量下的前端聚合函数、条件表达式的时间损耗上。所以，报表的优化首先要解决的就是在数据库服务器上的查询效率，SQL 的结构要合理、底层数据模型的结构要合理，这是SQL层面的优化，更是数据模型的优化。同时，减少数据的返回量，减少网络带宽的消耗，数据返回量小了，最终到前端聚合和渲染的速度也会加快。这样整个从查询到返回到展现的时间都会大大缩短。

有的朋友说，用户就是要查询大量的数据展现在二维表格上怎么办，还是按照刚才的四个点去分析。第一，通过设置合理的联动查询条件，逐步减少数据量的返回。第二，通过设置分页将查询分散在每一次与Server 的交互上，也可以减少数据量的返回。第三，提前将能够聚合的数据逻辑在服务器端完成，将计算前置，或者使用列式数据库或者分布式计算来减少查询阶段的时间消耗，都可以实现纯二维报表的优化。

当然也有朋友说使用C/S架构的BI工具是不是就可以解决这个问题。C/S架构的原理是Client 客户端和Server 服务器端的架构，将数据加载到本地电脑内存来计算，在性能和效率上比B/S架构确实要快很多。但C/S架构就意味着需要在每个用户的本地电脑上安装一套客户端软件，有多少用户就需要安装多少，并且在程序升级方面需要单独独立的升级，不太适合大批量的用户。对比B/S架构，B/S架构中用户只需要通过电脑上自带的浏览器随时访问报表，所有的程序升级都是在服务器上一次性升级就可以完成。

B/S架构和C/S架构没有孰优孰劣，只是在不同的场景下各有优劣。

---