应用程序跟踪对性能改变进行量化分析
|
使用ApacheWeb服务器作为示例，以了解如何分析公共配置的性能含义。使用应用程序跟踪来观察应用程序运行过程中进行的系统调用。通过统计调用的次数和发生的时间，您可以轻松地了解性能改变的影响。 您可以对应用程序进行跟踪，以找出它们暂停或不运行的原因。并且可以使用同样的方法，了解更多关于应用程序的信息并理解某些配置的性能含义。因为Apache非常流行并且大多数读者对它都比较熟悉，所以本文使用Apache作为示例。Apache所进行的每次系统调用都会对Web页面的提供带来延迟，通过跟踪不同配置下的Web服务器，您可以确定具体配置的影响。 在应用程序的执行过程中，当需要打开文件、发送数据包或者使用系统资源时，它会对基础操作系统进行相应的系统调用。跟踪应用程序意味着可以在调用发生时观察到这些系统调用，这将使得您能够深入地了解该应用程序的行为。在Solaris和IBMAIX®操作系统(AIX)中，使用truss命令完成这项任务，而在Linux®中则使用strace。清单1显示了对pwd命令进行跟踪的示例。
|
在删除开始处与加载该应用程序相关的输出内容后，您可以看到所进行的三次系统调用：
- getcwd返回当前工作目录。输出内容中显示了字符串“/export/home/sean”返回到缓冲区。
- write可以显示给定的字符串。因为在其执行之后才显示这个系统调用，所以先输出了它的执行结果。还可以注意到，write系统调用的结果是写入字符的个数数目，在这个示例中为17加上一个回车。
- _exit使用错误代码0退出该程序，这个错误代码通常表示成功结束。
尽管这是一个很简单的示例，但它演示了通过应用程序跟踪可以观察程序内部机制的程度。有关跟踪方面更深入的信息，请参见参考资料部分。
可以通过一个名为httpd.conf的文件对ApacheWeb服务器进行配置。清单2显示了一个简单配置中的部分内容。
清单2.示例httpd.conf
第一行定义了在何处可以找到HTML文件。将所有的请求都映射到这个目录。如果请求/project/charter.html，将使用/var/apache/htdocs/project/charter.html提供该页面。httpd.conf中剩余的部分由两个Directory节组成。<Directory...>和</Directory>之间的任何内容都将应用于指定目录及其所有的子目录。在本例中，第一节将两项设置应用于根目录，而第二节则指向/var/apache/htdocs。
如果多个节应用于单个请求，那么将会对这些命令进行组合，并且最适合的目录具有高优先级。例如，将使用/var/apache/htdocs/project/charter.html提供/project/charter.html请求的页面。/var/apache/htdocs是/的子目录，所以OptionsIndexesFollowSymLinksMultiViews来自第二节，AllowOverrideNone来自第一节。
可以对许多内容进行配置，并且每项内容都具有其性能含义。本文余下的内容重点关注于如何对这些改变的影响进行量化分析。
在您进行任何调整之前，务必要了解系统当前的运行方式。使用-X参数启动Apache，这个参数将强制Apache进入单进程调试模式。这样做可以确保将请求发送到正在进行跟踪的进程，并且消除常规进程间通信所带来的开销。
在守护进程启动之后，通过运行ps-ef找到相应的进程ID，并查找httpd守护进程。在找到该进程之后，使用truss-c-pPID附加到该进程。-c选项表示对系统调用进行计数，而不是逐个显示它们，而-p则表示将跟踪器附加于一个正在运行的进程。
使用Web浏览器请求文档。在页面加载之后，回到truss应用程序，然后按Ctrl-C以结束计数。对于静态HTML页面，您应该看到如清单3所示的内容（为使这些数字变得更有趣，本示例进行了100次相同的请求）。
清单3.系统调用基准
truss返回系统调用的列表、执行调用耗费的总时间、调用的次数和任何发现的问题。在这个报表的结尾处，返回了这些系统调用耗费的总时间，以及执行应用程序所耗费的时间。对于这些目的来说，所耗时间是没有意义的，因为它指的是从启动truss开始到其结束的时间，而与Web请求没有任何关系。
清单3显示了最简单的情况。在来自Web浏览器的连接请求到达后，accept系统调用完成该连接。Web服务器使用read调用获得请求的内容，将请求的内容映射到磁盘上的文件。Web服务器首先使用stat64验证该文件是否存在，使用open64打开该文件以便进行读取，然后使用mmap64将该文件的内容映射到内存中。然后使用write将这个文件发送回客户端，使用另一个write生成日志文件，并且服务器执行来自浏览器的最后一个read。该列表中其余的调用都是系统开销，并且当配置发生改变时，不会有显著的变化。
100次请求总共耗费0.269秒(0.149+0.120)，这样的性能相当不错，并且该服务器每秒钟应该可以提供大约370个页面(100/0.269)。但是不能完全相信这些数值，因为它们仅表示进程耗费在CPU上的时间，而不是其真正的执行时间（也称为时钟时间）。还有更多的因素需要考虑，如磁盘和网络的速度、计算机上正运行的其他内容、该守护进程运行于调试模式的事实。您还需要考虑系统调用跟踪本身的开销。
本文中使用的方法重点关注这些操作的相对计时和使用应用程序跟踪消除浪费掉的操作。如果您需要了解Web服务器每秒可以提供的页面数目，参考资料部分中有相应的软件链接，它可以帮助您确定该数值。
源代码网供稿.