充分发挥服务器的各项资源

在当前的网站架构中,经常会有较多的角色分工,如:缓存服务(文件型)、缓存加速服务(内存型)、PHP/Java 计算服务和数据库服务等等。每种服务对服务器的资源占用各有不同,例如:缓存加速服务就需要大量的内存,而 PHP/Java 计算服务则需要占用大量的 CPU 资源。如何充分发挥单机的资源利用,往往是运维的同学负责规划。认为的来进行分配,必然会有所疏漏,也正因此现在发展出 VMware 类虚拟服务器的云计算,可以实现一定的自动分配资源,达到节省成本的效果。

但使用 VMware 类方案并不太适合单个企业选用,原因一:架设一套自主的虚拟机集群,会产生软硬件成本,二:虚拟服务器系统本身要消耗掉一小部分性能。或者我们可以考虑以下方案 :) 可在原有的业务基础上进行简单的梳理,以达到需要的效果。

我们把服务器抽象出,磁盘、内存和 CPU 三项资源。服务角色可把 PHP/Java 归为计算类型,而 Memcached/Redis 等归为内存类型,对文件/页面缓存归为磁盘类,数据库较为特殊,它对三类资源的需求都比较高,将其定位特殊的全需求类型。

现在资源和服务类型都很清晰了,那么我们就可以针对服务器的三项资源进行网络化,抽象出三小块分布式服务。PHP/Java 计算类型,可在Web Server层加入分布式逻辑,使得业务可自动均衡的分配到服务器群;对于 Memcached/Redis 这些缓存加速服务基本都带有分布式支持能力;而磁盘类型的业务则需要找到一个适合业务所需要的解决方案(如业务本身对文件名没要求,那可考虑 FastDFS 类分布式存储系统,否则可考虑 MongoFS 类存储系统)以此我们可以构建出下图所绘的架构:

此架构不仅能让服务器的各项资源得到充分发挥,还具备分布式计算的热备能力,并且单台服务器的软件、配置环境标准化,可减少运维的工作量,日常维护也更加方便。是一举几得的好事!以下为我们某个业务的服务器组状态:

上面这组服务器,我们部署有 PHP/Memcached/MySQL 和一个分布式文件系统。

题外话:这素云计算的基础形态麽?嗯,有点云的意思,当然未能达到这个高度。主要因这个方案是非常基础的,仅适合单网站(公司)使用,如果非要说云,那只能说私有云。而要做公有云,我们还需要在此架构基础上,加入安全隔离、资源租赁和统计等很多子系统。

此文撰写于昨晚国航灰机晚点的几个小时里~晚上10点的票居然凌晨3点才到家~故留此印记。

HTTP 的后台任务

  众所周知 HTTP 协议是无保持连接的,HTTP 1.1 虽然实现了保持连接的能力,但依然无法在连接上实现交互功能。浏览器给服务器发送一个 GET 请求,然后等待服务器返回数据,完成一个数据交互处理。问题就是出在等待返回这点,当有一个不需要服务器返回数据,但需要服务器处理一定的操作时,就显得这个等待是没有必要的。

举个比较长见的例子:

一个使用 Javascript (或图片) 方式记录的统计程序,需要用户每次打开页面都在服务器端做记录操作,而我们不需要收取服务器端返回的任何结果,只要服务器能做计数的操作就可以了。

虽然是 Javascript 或图片的调用,但在页面在浏览器渲染并显示给用户的过程,依然会造成一定的延时。如果我们能把这个没用的等待剔除,就可以加快页面的加载速度。

  但这个应用非常特殊,正常来说根本没有这样的 web server 支持 _-!!,我在 google 查阅过一些资料,可以使用给浏览器发送 Header : Content-Length: 0 的方法来实现 ,经过测试在未经过 nginx 的情况下确实能够令到浏览器停止加载,但如果前端有 nginx 就没有任何效果了。

  如需要 100% 的效果,只能从 web server下手,在收到 GET 请求时就直接返回一个内容,但继续进入 PHP 处理接下来的数据操作。

  Yo2 的页面访问都是经由 yo2cache 处理的,so 我们很容易就实现了这项功能 :)

@139.com 邮箱实现服务器监测通知

  当你手上管理着好几台服务器,需要及时获取这些服务器网络断开或死机的消息通知,那么手机短信通知将是最好的途径。这点小事情不需要开通什么SMS短信端口的 :) 你只要注册一个 @139.com 邮箱即可,该邮箱带有手机短信通知功能(好像通过手机查看邮件内容是需要付费的 _-!! 但我只需知道 web 服务是否正常,就把服务器信息简单的写在标题即可)

使用 PHP 监测 web 服务 80 端口是否正常:

发送邮件的 class (smtp.txt),请自行修改文件名
[code]<?
include_once('smtp.php');
@ob_end_flush();
//请修改为自己的发信邮箱地址(用原来的@139.com邮箱无法发送成功 _-!!,错误不明)
$smtp = new smtp("smtp.163.com",25,true,"***@163.com" ,"***");

function testServer($ip){
// 如果服务器在1小时内出现过错误则跳过检测
if(file_exists("/tmp/check-$ip") && (time() - filemtime("/tmp/check-$ip")) < 3600)return false;
global $smtp;
$h = '';
echo "CHECK: $ip";
if($fs = @fsockopen($ip,80, $errno, $errstr, 10)){
@fwrite($fs, "GET / HTTP/1.0rnHost: oneoo.comrnrn");
$h .= @fgets($fs, 256);
@fclose($fs);}
if(strpos($h,'200') === false){
@touch("/tmp/check-$ip");
echo " Failn";
//请修改为自己的邮箱地址
$smtp -> sendmail( '***@139.com', "wesnet@163.com", "Yo!", "服务器 $ip 出现异常", $h, "TXT" );
return false;
}else @unlink("/tmp/check-$ip");
echo " OKn";
return true;
}

testServer('***.***.***.***');
testServer('***.***.***.***');//检测多个服务器

echo "Finish TEST!n";

?>

  把该程序放在相对最稳定的服务器上,并设置 crontab 定时执行该程序 (如果还担心这台服务器不稳定,可以在其他服务器上也搞个监测程序 :)

  程序虽然是非常简单,但作用不小哦。我就是用这个方法来监测 Yo2 的服务器,服务器一出现无法访问,就能在 10 分钟内短信通知我了。

  如果服务器没有 PHP 环境,也可以使用 perl 来写个 :D

使用 PRTG 软件监控服务器、网络状态

  PRTG 是一个 For Windows 的服务器远程监控工具,它可支持多种监控协议,比较常用的是 SNMP 协议,大部分路由器等网络设备都支持该协议。服务器只需要安装一个 snmpd 监控即可。

综合监控界面

以下介绍如何使用 PRTG 工具来监控服务器的资源、网络状态 :

第一、必须在服务器上安装 snmpd 工具

Linux: yum -y install snmpd && yum -y install net-snmp

第二、配置 snmpd 工具以提供 CPU、RAM、Disk和网络状态的监控

请编辑 /etc/snmp/snmpd.conf

加入配置内容:

access notConfigGroup “” any noauth exact mib2 none none
view mib2   included  .iso.org.dod.internet.mgmt.mib-2 fc

如需要监控 CPU 和disk等状态,请加入以下配置内容:

com2sec adminUser  default       admin
group   adminGroup v1           adminUser
view adminview included  .1.3.6
access adminGroup “” any noauth exact adminview none none

load 12 14 14
disk / 10000

红色部分是设置只允许 admin 用户才能获取 CPU 和disk等状态数据,如果服务器的状态数据敏感,可使用 v2 协议,并加上密码 :)

蓝色部分是设置监控某分区,当然也可以设置多个,以监控多个分区

第三、配置 PRTG 客户端监控服务器状态

 PRTG 添加监控项目

添加网络监控:

添加网络监控1 添加网络监控2 添加网络监控3 添加网络监控4 添加网络监控5 添加网络监控6

添加CPU、磁盘等的监控:

跟添加网络监控的步骤有些区别,在第三步选择协议的时候不选择Standard Traffic Sensor 而选择 Custom SNMP Sensor。

在输入服务器信息时,如果 snmpd 配置文件中设置 CPU、磁盘等监控信息不为 public 默认访问可读取时,SNMP Community String 需要输入你在配置文件中设置的用户名

第五步需要输入正确的 OID (附表),并设置数据类型为 Gauge ;如是磁盘、内存等数据可设置 Scale 为 1024

添加CPU、磁盘等的监控1 添加CPU、磁盘等的监控2 添加CPU、磁盘等的监控3

设置综合监控界面

设置综合监控界面

还可以针对某项监控数据加上报警设置,如高亮显示,甚至可以自动执行某程序和发送 email 通知。

OID 对照表:

1.3.6.1.4.1.2021.10.1.3.1  //CPU 每分钟的 Load
1.3.6.1.4.1.2021.4.6.0  //已使用内存空间大小

1.3.6.1.2.1.6.9.0 //系统的 TCP 端口连接数

1.3.6.1.4.1.2021.9.1.6.1 //第一个监测 Disk 的总空间大小
1.3.6.1.4.1.2021.9.1.8.1 //第一个监测 Disk 的已使用空间大小
1.3.6.1.4.1.2021.9.1.9.1 //第一个监测 Disk 的使用比率

更详细的 OID 可使用 snmptranslate -Tp 1.3.6.1.4.1.2021 命令获取

httperf 一个高性能的压力测试工具

  Httperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance. The focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.

  Httperf 是一个高效的 http 压力测试工具,使用它可以模拟出超过1千的并发访问,能充分测试出 web server 的性能。而之前使用的 siege 测试工具则未能突破 500 个并发测试(如果您知道如何可以实现,请告诉我)

使用 httperf 应该能了解到自己编写 yo2cache 软件性能极限如何了 :)

以下是 gzip 格式访问的测试数据(因缓存文件以 gzip 格式保存,所以性能是最高的)

oneoo@oneoo-pc:~/Desktop$ httperf –server oneoo.com –num-conns 2000 –add-header “accept-encoding: gzip”
httperf –client=0/1 –server=oneoo.com –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –add-header=’accept-encoding: gzip’ –num-conns=2000 –num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 1.304 s

Connection rate: 1533.7 conn/s (0.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.6 avg 0.7 max 6.3 median 0.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 1533.7 req/s (0.7 ms/req)
Request size [B]: 81.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.0
Reply size [B]: header 302.0 content 10482.0 footer 0.0 (total 10784.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.29 system 1.01 (user 22.4% system 77.6% total 100.0%)
Net I/O: 16273.4 KB/s (133.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是 deflate (2级压缩率)格式访问的统计数据(需要从 gzip 解压,再压缩为 deflate 的数据处理)

oneoo@oneoo-pc:~/Desktop$ httperf –server oneoo.com –num-conns 2000 –add-header “accept-encoding: deflate”
httperf –client=0/1 –server=oneoo.com –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –add-header=’accept-encoding: deflate’ –num-conns=2000 –num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 4.113 s

Connection rate: 486.2 conn/s (2.1 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.0 avg 2.1 max 11.8 median 2.5 stddev 0.3
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 486.2 req/s (2.1 ms/req)
Request size [B]: 84.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 1.5
Reply size [B]: header 305.0 content 11014.0 footer 0.0 (total 11319.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.91 system 3.20 (user 22.2% system 77.8% total 100.0%)
Net I/O: 5414.3 KB/s (44.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是 deflate (4级压缩率)格式访问的统计数据

oneoo@oneoo-pc:~/Desktop$ httperf –server oneoo.com –num-conns 2000 –add-header “accept-encoding: deflate”
httperf –client=0/1 –server=oneoo.com –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –add-header=’accept-encoding: deflate’ –num-conns=2000 –num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 5.329 s

Connection rate: 375.3 conn/s (2.7 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 2.6 avg 2.7 max 32.8 median 2.5 stddev 0.7
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 375.3 req/s (2.7 ms/req)
Request size [B]: 84.0

Reply rate [replies/s]: min 374.8 avg 374.8 max 374.8 stddev 0.0 (1 samples)
Reply time [ms]: response 0.6 transfer 2.0
Reply size [B]: header 305.0 content 10457.0 footer 0.0 (total 10762.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.29 system 4.01 (user 24.2% system 75.2% total 99.4%)
Net I/O: 3975.4 KB/s (32.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

以下是文本格式访问的统计数据

oneoo@oneoo-pc:~/Desktop$ httperf –server oneoo.com –num-conns 2000 –add-header “accept-encoding: normal”
httperf –client=0/1 –server=oneoo.com –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –add-header=’accept-encoding: normal’ –num-conns=2000 –num-calls=1
Maximum connect burst length: 1

Total: connections 2000 requests 2000 replies 2000 test-duration 2.349 s

Connection rate: 851.3 conn/s (1.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 1.1 avg 1.2 max 5.8 median 1.5 stddev 0.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 851.3 req/s (1.2 ms/req)
Request size [B]: 83.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.6 transfer 0.6
Reply size [B]: header 278.0 content 42562.0 footer 0.0 (total 42840.0)
Reply status: 1xx=0 2xx=2000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.62 system 1.73 (user 26.2% system 73.7% total 99.9%)
Net I/O: 35683.0 KB/s (292.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

从以上数据可以看到 yo2cache 性能挺好的,最高能达到每秒 1500 个并发处理。性能瓶颈是出现在缓存数据的解压与压缩处理上,如果缓存空间足够大的话,可以考虑保存多种格式的缓存数据,就能解决这个瓶颈问题。

  而在 deflate 数据压缩方面,因为2级压缩率与4级压缩率所产生的数据量差距不大,但并发性能有一定差距,可以考虑使用 2 级压缩率。