论文部分内容阅读
摘 要 轻量目录访问协议逐渐被用到越来越多的分布式目录应用程序当中。我们描述了一种分析LDAP目录使用效果的工具。利用这个工具，我们研究了一个LDAP目录在一系列不同的查询方式下的效果表现。至于做这些实验的目的，我们使用了一个LDAP模型，这个模型是通过SLAMD软件生成的高还原石油生产环境的LDAP元数据。同时，通过不同查询条件来获取它们对于整个系统延时和吞吐量影响的详细数据。
关键词 LDAP；测试；SLAMD
中图分类号：TP393 文献标识码：A 文章编号：1671-7597（2013）24-0065-03
1 概述
轻量级目录访问协议（LDAP）正在被越来越多当作目录管理的使用，其主要应用包过人事数据库管理，追踪安排日程，IP电话的直至转换数据库，用于存储网络配置信息、服务策略规则以及校验规则的网络数据库等。
在这些案例中，LDAP基本都是被当作存储人事信息和身份验证规则的目录来使用的，数据是相对静态的。因此，利用缓存技术可以提高其性能。在某些情况下，需要经常更新数据库中的信息，例如在使用IP电话时，会出现每次同一用户在不同地点使用不同终端。这时，他的个人信息便需要更新。尽管人们对LDAP服务愈加重视，在不同现实的环境中使用却是少之又少。特别是在需要频繁搜索的动态环境中，LDAP的性能也未被大家重视。
本次论文内容便是利用开源标准工具SLAMD来测试并分析超大数据量下LDAP的性能。
1.1 数据准备
利用SLAMD工具，制定相关规则条件生成数据库文件，库中的entries值均是通过现有文档文件的规则制度随机生成的。工具会输出一个标准的ldif格式文件，该文件被加载（导入）目录服务器中用于进行测试，利用一个简单的目录层次来模拟真实的文档结构。
1.1.1 硬件支持
LDAP服务器使用的是SUN的X4170M2，配置是双CPU 12核 Intel X5660，主频为2.80GHz，64G内存。操作系统为基于Linux 内核的Red Hat Linux 5.5。
其中OUD的LDAP服务进程是双CPU上同时运行处理的，而TDS由于程序编译限制只能实现服务进程与单个CPU的绑定。
LDAP客户端则是使用PC的个人电脑，CPU：Intel Core i7 -2630QM，主频2.00GHz，4G内存。
服务器和客户端均已采用千兆以太网（1Gb/s）连接。
1.1.2 LDAP服务软件
目前市面上有许多LDAP服务软件提供商，包括SUN公司的SUNONE Directory Server、Novell公司的Novell Directory Server、微软公司的Microsoft Active Directory等等。本次测试是使用IBM的Tivoli Directory Server（TDS）和Oracle的Oracle Unified Directory（OUD）两家产品。由于这两个软件均是商用类型，属于不开放内核版本，所以实验主要内容关注性能表现，对详细模块分析与系统调优不是重点。
1）TDS使用版本为：IBM Tivoli Directory Server 6。2；DB2版本：DB2 9.5。
2）OUD使用版本为：Oracle Unified Directory 11.1.2.0.0。
服务器是根据一个独立的LDAP目录服务守护进程（slapd）工作的。复制（导入）服务也是通过Unix守护进程的支持下完成的。Slapd进程包括两部分：前端是处理与客户机的通信协议，后端是进行数据库操作。这两部分均已高度集成在两款商用软件中，但就性能测试而言，需要调整的参数主要是后端数据库操作中缓冲区分配大小（cachesize），该参数的值对改善服务器性能起到重要作用，而客户机与服务器之间的连接则是可以在SLAMD工具中加以控制。
1.1.3 LDAP客户端
由于SLAMD测试工具是分布式负载生成引擎是一个 Java应用程序，所以需要简单安装配置JDK即可。
1.1.4 LDAP测试工具及测试数据生成
测试数据则可以使用SLAMD集成的MakeLDIF工具，根据事先准备好的部分规则来生成。以生成100条符合生产环境需要属性的LDIF文件为例，其中含有100条的entry，大小为42130字节，最大单条entry位443字节。
根据测试需要，分别生成2千5百万条、1亿2千5百万条和7亿条目的超大数据。元数据大小分别为10G、50G、300G。
1.2 测试方法
一般对LDAP操作分为：添加、删除、更改及查询。针对此次测试，主要考察的内容为批量导入超大数据条目数以及查询的性能；插入新节点对于Ldap原理非常简单：因为Ldap数据是“树”状的，而且这棵树是可以无限延展的。将每个需要导入的节点信息按照规范（在引用的objectClass中定义属性项目）编译成批量的。ldif文件，通过命令直接导入即可；就查询而言，分为四个步骤：打开Ldap，添加Ldap约束条件，进行一次或多次的查询，释放Ldap资源。打开Ldap：通过ldap_open初始化LDAP数据库，打开客户端与服务器的连接并由服务器端返回一个会话标识符。添加Ldap约束条件：利用ldap_bind来对客户端进行认证，客户端利用DN及认证机制向服务器发出请求要求验证身份。ldap支持多重认证机制，本次测试采用的是密码认证机制。当一次连续操作被成功执行，服务器缓存其身份直到执行ldap_unbind，图1为ldap进行查找操作的过程图。
一般定义：连接时间（connect time）是指从发出Ldap_open请求直到Ldap_bind操作成功执行的时间；处理时间（processing time）是指从Ldap_search操作开始直到查询结果返回到客户端的时间；而响应时间（response time）是指从Ldap_open开始到Ldap_unbind结束的时间。反应Ldap服务性能的标准就是这三个时间，本次测试主要针对查询操作，考虑到服务器性能及产品成熟性，查询性能较为理想，定义的单独连接、处理、响应时间过小（均小于1ms），所以这里我们利用SLAMD工具定义一个整合连接、处理、响应三个时间间隔的时间定义，命名为查询间隔时间（Search Duration），以便计算性能。 2 测试结果
本次测试主要目的是了解这两款商用级别的LDAP的批量导入超大数据条目以及查询极限性能，主要是通过分别进行不同批次的超大数量级的数据条目来实现性能上的测试。在相同条件下对比两款产品的性能。
2.1 超大数据量数据条目的批量导入
2.1.1 ORACLE的Oracle Unified Directory
7亿条目：
经过测试，导入300G数据量的过程中，共计用50015秒，平均导入速率为13995.7条/秒。
2.1.2 IBM的Tivoli Directory Server
由于软件工作机制关系，TDS批量数据导入涉及三个步骤：
1）导入前数据准备（语法校验）。
2）数据导入。
3）导入后按需建特定索引：在创建TDS实例时，系统会默认建立索引，针对特定查询要求，可以在导入后再对特殊属性建立索引。该操作可以通过TDS Web管理界面完成。
7亿条目：
1）校验时间：106271秒（29小时31分11秒）。
2）实际导入时间：76264秒（21小时11分4秒），平均导入速率为9179条/秒。
3）建立单条索引时间（以ID为例）：1633秒（27分13秒）。
2.2 查询性能测试
查询测试是通过SLAMD工具，工具自带的结果分析功能，可以大大简化比较工作。由于测试用例较多，这里只以“ORACLE OUD在2千5百万数据条目中做全局模糊查找”为例。
查询条件：
SLAMD客户端配置如下：
Number of Client=2，Threads Per Client=10，Thread Startup Delay=0，Statistics Collection Interval=60 seconds
Search Scope=whole Subtree，Search Filter 1=（id=[1-25000000]），Search Filter 2=test，Filter1 Percentage=100
查询结果：
Searches Completed
Actual Duration=655 seconds，Count=17011831，Avg/Second=28353.052
Std Dev=144.972，Correlation=-0.173
Total Duration=11942619，Total Count=17011995，Avg Duration=0.702，
校验结果：
根据测试技术文档显示：Total Duration ≈（Actual Duration）*（Number of Clients）*（Threads Per Client），Total Duration其实为查找有效时间，与Actual Duration相比，误差主要存在于线程注入先后的延迟。而Avg Duration=Total Duration/Total Count，便可以得出查询平均用时时间为0.702ms。
3 性能对比
3.1 批量导入时间比较参见表1（时间：秒s）
表1 导入时间对比
Ldap类型
条目数量 OUD TDS
2千5百万 1774 4927
1亿2千5百万 69342 11645
7亿 50015 76264
数据显示，OUD的1亿2千5百万与TDS的2千5百万数据异常。原因是测试之前未考虑到数据量跨度较大，没有对Ldap配置做好相应调优，主要参数还是cfg-num-request-handlers和cfg-cache-size两个值分配量大小，分别为请求处理数和缓存池大小。
3.2 7亿条目的数据比较
既然是极限性能测试，只取用7亿条目的数据查询结果作比较。
两款LDAP在7亿条目数据量下做全局模糊查找的对比数据。在相同数量级的已完成查找中，TDS比OUD查找速度快，但是标准差偏移较大。所谓的标准差是反映一组数据离散程度最常用的一种量化形式，是表示精确度的重要指标。值越小，说明测试得到数值越平稳，越趋近于真实值。将结果反映至坐标图如图2。
图2 结果对比坐标图
由坐标图可以看出，OUD性能从始至终很稳定；而TDS波动很大，初始值明显低于OUD，但随着时间的推进，查询速率明显上升，最后趋于稳定，停留在一个比较高的水平。
由以上这些数据表现上来看，ORACLE的OUD相比之下更适合在大数量级下的不连续短时间查询和超大批量导入。而IBM的TDS则对小数量级的长时间下查询和导入有较好的优化。
参考文献
[1]http：//files.unboundid.com/slamd/index.html.
[2]Wahl W T，Kille S.Lightweight Directory Access Protocol V3.RFC2251，Dec，2007.
[3]Directory Server Certified Performance Reports.http：//www.mindcraft.corn/perfreports/ldap.
[4]Xin Wang，Henning Sehulzfine，Dilip KandIur，Dinesh Verma.Measurement and Analysis of LDAP Performance.Special issue on proceedings ofACM SIGMETRICS，2000，28（1）：156-165.
作者简介
张健（1988-），男，2010年毕业黑龙江大学信息科学学院计算机科学与技术专业，工学学士，助理工程师，现从事信息安全工作。
关键词 LDAP；测试；SLAMD
中图分类号：TP393 文献标识码：A 文章编号：1671-7597（2013）24-0065-03
1 概述
轻量级目录访问协议（LDAP）正在被越来越多当作目录管理的使用，其主要应用包过人事数据库管理，追踪安排日程，IP电话的直至转换数据库，用于存储网络配置信息、服务策略规则以及校验规则的网络数据库等。
在这些案例中，LDAP基本都是被当作存储人事信息和身份验证规则的目录来使用的，数据是相对静态的。因此，利用缓存技术可以提高其性能。在某些情况下，需要经常更新数据库中的信息，例如在使用IP电话时，会出现每次同一用户在不同地点使用不同终端。这时，他的个人信息便需要更新。尽管人们对LDAP服务愈加重视，在不同现实的环境中使用却是少之又少。特别是在需要频繁搜索的动态环境中，LDAP的性能也未被大家重视。
本次论文内容便是利用开源标准工具SLAMD来测试并分析超大数据量下LDAP的性能。
1.1 数据准备
利用SLAMD工具，制定相关规则条件生成数据库文件，库中的entries值均是通过现有文档文件的规则制度随机生成的。工具会输出一个标准的ldif格式文件，该文件被加载（导入）目录服务器中用于进行测试，利用一个简单的目录层次来模拟真实的文档结构。
1.1.1 硬件支持
LDAP服务器使用的是SUN的X4170M2，配置是双CPU 12核 Intel X5660，主频为2.80GHz，64G内存。操作系统为基于Linux 内核的Red Hat Linux 5.5。
其中OUD的LDAP服务进程是双CPU上同时运行处理的，而TDS由于程序编译限制只能实现服务进程与单个CPU的绑定。
LDAP客户端则是使用PC的个人电脑，CPU：Intel Core i7 -2630QM，主频2.00GHz，4G内存。
服务器和客户端均已采用千兆以太网（1Gb/s）连接。
1.1.2 LDAP服务软件
目前市面上有许多LDAP服务软件提供商，包括SUN公司的SUNONE Directory Server、Novell公司的Novell Directory Server、微软公司的Microsoft Active Directory等等。本次测试是使用IBM的Tivoli Directory Server（TDS）和Oracle的Oracle Unified Directory（OUD）两家产品。由于这两个软件均是商用类型，属于不开放内核版本，所以实验主要内容关注性能表现，对详细模块分析与系统调优不是重点。
1）TDS使用版本为：IBM Tivoli Directory Server 6。2；DB2版本：DB2 9.5。
2）OUD使用版本为：Oracle Unified Directory 11.1.2.0.0。
服务器是根据一个独立的LDAP目录服务守护进程（slapd）工作的。复制（导入）服务也是通过Unix守护进程的支持下完成的。Slapd进程包括两部分：前端是处理与客户机的通信协议，后端是进行数据库操作。这两部分均已高度集成在两款商用软件中，但就性能测试而言，需要调整的参数主要是后端数据库操作中缓冲区分配大小（cachesize），该参数的值对改善服务器性能起到重要作用，而客户机与服务器之间的连接则是可以在SLAMD工具中加以控制。
1.1.3 LDAP客户端
由于SLAMD测试工具是分布式负载生成引擎是一个 Java应用程序，所以需要简单安装配置JDK即可。
1.1.4 LDAP测试工具及测试数据生成
测试数据则可以使用SLAMD集成的MakeLDIF工具，根据事先准备好的部分规则来生成。以生成100条符合生产环境需要属性的LDIF文件为例，其中含有100条的entry，大小为42130字节，最大单条entry位443字节。
根据测试需要，分别生成2千5百万条、1亿2千5百万条和7亿条目的超大数据。元数据大小分别为10G、50G、300G。
1.2 测试方法
一般对LDAP操作分为：添加、删除、更改及查询。针对此次测试，主要考察的内容为批量导入超大数据条目数以及查询的性能；插入新节点对于Ldap原理非常简单：因为Ldap数据是“树”状的，而且这棵树是可以无限延展的。将每个需要导入的节点信息按照规范（在引用的objectClass中定义属性项目）编译成批量的。ldif文件，通过命令直接导入即可；就查询而言，分为四个步骤：打开Ldap，添加Ldap约束条件，进行一次或多次的查询，释放Ldap资源。打开Ldap：通过ldap_open初始化LDAP数据库，打开客户端与服务器的连接并由服务器端返回一个会话标识符。添加Ldap约束条件：利用ldap_bind来对客户端进行认证，客户端利用DN及认证机制向服务器发出请求要求验证身份。ldap支持多重认证机制，本次测试采用的是密码认证机制。当一次连续操作被成功执行，服务器缓存其身份直到执行ldap_unbind，图1为ldap进行查找操作的过程图。
一般定义：连接时间（connect time）是指从发出Ldap_open请求直到Ldap_bind操作成功执行的时间；处理时间（processing time）是指从Ldap_search操作开始直到查询结果返回到客户端的时间；而响应时间（response time）是指从Ldap_open开始到Ldap_unbind结束的时间。反应Ldap服务性能的标准就是这三个时间，本次测试主要针对查询操作，考虑到服务器性能及产品成熟性，查询性能较为理想，定义的单独连接、处理、响应时间过小（均小于1ms），所以这里我们利用SLAMD工具定义一个整合连接、处理、响应三个时间间隔的时间定义，命名为查询间隔时间（Search Duration），以便计算性能。 2 测试结果
本次测试主要目的是了解这两款商用级别的LDAP的批量导入超大数据条目以及查询极限性能，主要是通过分别进行不同批次的超大数量级的数据条目来实现性能上的测试。在相同条件下对比两款产品的性能。
2.1 超大数据量数据条目的批量导入
2.1.1 ORACLE的Oracle Unified Directory
7亿条目：
经过测试，导入300G数据量的过程中，共计用50015秒，平均导入速率为13995.7条/秒。
2.1.2 IBM的Tivoli Directory Server
由于软件工作机制关系，TDS批量数据导入涉及三个步骤：
1）导入前数据准备（语法校验）。
2）数据导入。
3）导入后按需建特定索引：在创建TDS实例时，系统会默认建立索引，针对特定查询要求，可以在导入后再对特殊属性建立索引。该操作可以通过TDS Web管理界面完成。
7亿条目：
1）校验时间：106271秒（29小时31分11秒）。
2）实际导入时间：76264秒（21小时11分4秒），平均导入速率为9179条/秒。
3）建立单条索引时间（以ID为例）：1633秒（27分13秒）。
2.2 查询性能测试
查询测试是通过SLAMD工具，工具自带的结果分析功能，可以大大简化比较工作。由于测试用例较多，这里只以“ORACLE OUD在2千5百万数据条目中做全局模糊查找”为例。
查询条件：
SLAMD客户端配置如下：
Number of Client=2，Threads Per Client=10，Thread Startup Delay=0，Statistics Collection Interval=60 seconds
Search Scope=whole Subtree，Search Filter 1=（id=[1-25000000]），Search Filter 2=test，Filter1 Percentage=100
查询结果：
Searches Completed
Actual Duration=655 seconds，Count=17011831，Avg/Second=28353.052
Std Dev=144.972，Correlation=-0.173
Total Duration=11942619，Total Count=17011995，Avg Duration=0.702，
校验结果：
根据测试技术文档显示：Total Duration ≈（Actual Duration）*（Number of Clients）*（Threads Per Client），Total Duration其实为查找有效时间，与Actual Duration相比，误差主要存在于线程注入先后的延迟。而Avg Duration=Total Duration/Total Count，便可以得出查询平均用时时间为0.702ms。
3 性能对比
3.1 批量导入时间比较参见表1（时间：秒s）
表1 导入时间对比
Ldap类型
条目数量 OUD TDS
2千5百万 1774 4927
1亿2千5百万 69342 11645
7亿 50015 76264
数据显示，OUD的1亿2千5百万与TDS的2千5百万数据异常。原因是测试之前未考虑到数据量跨度较大，没有对Ldap配置做好相应调优，主要参数还是cfg-num-request-handlers和cfg-cache-size两个值分配量大小，分别为请求处理数和缓存池大小。
3.2 7亿条目的数据比较
既然是极限性能测试，只取用7亿条目的数据查询结果作比较。
两款LDAP在7亿条目数据量下做全局模糊查找的对比数据。在相同数量级的已完成查找中，TDS比OUD查找速度快，但是标准差偏移较大。所谓的标准差是反映一组数据离散程度最常用的一种量化形式，是表示精确度的重要指标。值越小，说明测试得到数值越平稳，越趋近于真实值。将结果反映至坐标图如图2。
图2 结果对比坐标图
由坐标图可以看出，OUD性能从始至终很稳定；而TDS波动很大，初始值明显低于OUD，但随着时间的推进，查询速率明显上升，最后趋于稳定，停留在一个比较高的水平。
由以上这些数据表现上来看，ORACLE的OUD相比之下更适合在大数量级下的不连续短时间查询和超大批量导入。而IBM的TDS则对小数量级的长时间下查询和导入有较好的优化。
参考文献
[1]http：//files.unboundid.com/slamd/index.html.
[2]Wahl W T，Kille S.Lightweight Directory Access Protocol V3.RFC2251，Dec，2007.
[3]Directory Server Certified Performance Reports.http：//www.mindcraft.corn/perfreports/ldap.
[4]Xin Wang，Henning Sehulzfine，Dilip KandIur，Dinesh Verma.Measurement and Analysis of LDAP Performance.Special issue on proceedings ofACM SIGMETRICS，2000，28（1）：156-165.
作者简介
张健（1988-），男，2010年毕业黑龙江大学信息科学学院计算机科学与技术专业，工学学士，助理工程师，现从事信息安全工作。