大约一个星期前，安德鲁 和 我 启动 一个新的 Django 打造的网站，站名叫 Hey!Wall 。这是一个按照社交网络中的“墙”的概念建立的社交网站，它为各类朋友提供了一个留言及分享照片、视频和链接的空间。
我们想对其进行性能评估，并进行一些服务器配置和代码修改来决定采取何种步骤进行改进。我们使用 httperf 进行了测试，并通过优化将其性能提高了整整一倍。
服务器和客户端
服务器一是一台 Slicehost 提供的 Xen VPS ，配有 256MB 内存，运行的是 Debian Etch 系统。部署在美国中西部。
为了测试，采用了一台位于英国的 Xtraordinary Hosting 提供的 Xen VPS，作为客户端。通常我们使用的 ADSL 访问互联网络，但这让我们很难向服务器发起足够多的访问请求。使用连接良好的 VPS 作为客户端使我们可以真正地对服务器加以考验。
服务器规格说明
很难确切地描述服务器的规格。该 VPS 配有 256MB 内存，与数个类似的 VPS 同居一台主机（大概是一台 装有 16GB 内存的 Quad Core 服务器）之上。假定装满了 256MB 切片的话，物理服务器上最多装有 64 台 VPS 。如果四个处理器都是 2.4GHz，那么共 9.6 GHz ，除以 64 得到最少 150MHz 的 CPU 。
在 Xen VPS 上，无需竞争你就可以获得稳定的内存和 CPU 分配，但通常 主机上任何空闲的 CPU 都将得到使用。如果在同一机器上的其它 VPS 处于空闲状态，你的 VPS 将能够使用更多的 CPU 。这也许意味着在测试期间使用了更多的 CPU ，即某些测试可能比其它的使用了更多的 CPU 资源。
使用 httperf 评估性能
现有各式各样的网络性能测试工具，主要包括 ab (来自 Apache), Flood 和 httperf。我们使用 httperf 并没有任何特别理由。
httperf 命令看起来如下所示：
httperf --hog --server=example.com --uri=/ --timeout=10 --num-conns=200 --rate=5
在该例中，我们向 http://example.com/ 发起了 200 次访问请求，每秒最多 5 次。
测试计划
某些工具支持进程，可以模仿用户对网站提交任务。我们使用了一种简单的“暴力”测试来了解该站点每秒能够处理多少请求。
该基本方法是发起一定数量的请求，能够判断服务器如何反应：状态 200 为成功，状态 500 为失败。提高频率（每秒制造的请求数量）然后再试一遍。如果开始返回大量的 500 ，则已经达到极限。
监测服务器资源
另一个方面是要掌握服务器在内存和 CPU 使用方面的情况。要跟踪这一情况，我们运行 top 并将输出记录为日志文件以供稍后查阅。该 top 命令如下所示：
top -b -d 3 -U www-data > top.txt
在该例中，我们以用户 www-data 每三秒记录一次进程的日志信息。如果你想更加明确的指定目标，可以使用 -p 1, 2, 3 ，而不是 -U username ，其中 1、2 和 3 是 pid（即要观测进程的进程ID）。
网页服务器为配有以 FastCGI processes 方式运行的 Python 2.5 的 Lighttpd 。尽管数据库的日志也是很有用的信息，但我们没有记录该进程（PostgreSQL）的日志。
另一个有用的工具是 vmstat，特别是 swap 列显示了有多少内存进行了交换。交换的意思是你没有足够的内存，它是一种性能杀手。要想反复运行 vmstat 的话，必须指定每次检查间隔的秒数。如：
vmstat 2
使用 httperf 进行已认证访问
httperf 只是简单地向某个 URL 发出简单的 GET 请求，并下载 html 文本（但不包括任何媒体文件）。对公共/匿名（public/anonymous）网页发起的访问请求是件轻松的事情，但如果要访问需要登录的页面怎么办呢？
httperf 可以传递请求头部信息。Django 身份校验（ authentication）（由 django.contrib.auth 提供）使用的进程依赖于在客户端 cookie 中所保存的进程 id 。而客户端在请求的头部信息中传递 cookie 。你可以看到这一切是如何进行的。
登录站点，查看 cookies 信息。其中应该有个类似 sessionid=97d674a05b2614e98411553b28f909de 的数值。要通过 httperf 传递该 cookie，可以使用 --add-header 参数选项。如：
httperf ... --add-header='Cookie: sessionid=97d674a05b2614e98411553b28f909den'
小心头部信息之后的 n 。如果少了该字符，你的每个请求可能都会返回超时信息。
