ECS:4 vCPU 8 GiB
php-fpm配置
pm = dynamic
pm.max_children = 100
pm.start_servers = 11
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 2048
pm.process_idle_timeout = 10s
request_terminate_timeout = 120
request_slowlog_timeout = 2
一台ECS
2001400并发的时候开始出现故障,1800的时候完成全部失败,请求成功率57.51%(120541/89051)
弹性伸缩
自动伸缩增加机器的时候会出现异常
没有弹性伸缩2台ECS,请求成功率67.15%(144956/70903)详情
没有弹性伸缩4台ECS,请求成功率88.57%(316114/40810)详情
结论:
并发1300的时候会出现4分异常
安装nginx
yum -y install nginx
yum install nginx 时报错:No package nginx available.
先安装epel:
yum install epel-release
查看
ps -aux | grep nginx
安装php
yum install -y php72w php72w-opcache php72w-xml php72w-mcrypt php72w-gd php72w-devel php72w-mysql php72w-intl php72w-mbstring
yum -y install php php-mysql php-cgi php-mbstring php-gd php-fastcgi
安装spawn-fcgi来运行php-cgi
yum install spawn-fcgi
下载spawn-fcgi 的启动脚本
wget http://bash.cyberciti.biz/dl/419.sh.zip ;
unzip 419.sh.zip
mv 419.sh /etc/init.d/php_cgi
chmod +x /etc/init.d/php_cgi
启动php_cgi
/etc/init.d/php_cgi start
查看进程
netstat -tulpn | grep :9000
若出现如下代表一切正常
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 4352/php-cgi
开机启动
chkconfig nginx on
跨域
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
配置文件
worker_processes 8; # nginx 进程数,建议按照cp
事情大概是这样的,需求要在用户注册的时候发一些帮助邮件给用户(原本用户在注册之后已经有发别的邮件的了,短信,IM什么的)
原来这个注册的方法也就10多行代码。但是有时候我们为了省事,直接在注册代码后面添加了各种代码。
例如这个注册方法本来是这样的
<?php
namespace App\Htt\Controllers;
use Illuminate\Http\Request;
class UserController extends Controller
{
public function register(Request $request)
{
//获取参数
//验证参数
//写入数据库
//return 注册信息
}
}
现在有一个需求,要求注册之后给用户的邮箱发一个广告,绝大多数的人(也包括以前的我)就直接在这后面接着写代码了
<?php
namespace App\Htt\Controllers;
use Illuminate\Http\Request;
class UserController extends Controller
{
public function register(Request $request)
{
//获取参数
//验证参数
//写入数据库
//发送广告邮件
//return 注册信息
}
}
这是比较直观的写法,后来又有需求要发个短信。
<?php
namespace App\Htt\Controllers;
use Illuminate\Http\Request;
class UserController extends Controller
{
public function register(Request $request)
{
//获取参数
//验证参数
//写入数据库
//发送广告邮件
//发送短信
//return 注册信息
驱动是一段设计用来于一种特定类型的数据库服务器进行交互的软件代码。驱动可能会调用一些库。类似于Java中的数据库驱动的概念
而对于PHP来说,同样主流使用的也是网络协议驱动、本地协议驱动,即MySQL客户端库、MySQL Native驱动库。 这些库实现了用于和MySQL数据库服务器进行交互的底层协议。
数据库驱动位于PHP和数据库进行通信的最底层,不同的数据库厂商都会在基于某个框架的前提下实现自己的驱动,用以提供基本功能、以及特定数据库的高级功能。
在驱动层之上是"连接器"、或者是适配器抽象层,用于PHP代码和数据库进行连接,程序员可以使用PDO(PHP Database Object)、或者直接使用扩展接口(mysql、mysqli)这些暴露出来的API与底层数据库进行通信。
数据库厂商提供的底层数据库驱动
自从Node横空出世后,很快有人就用它来开发爬虫,网上也常见Node爬虫教程。然而,很难看到一个通用的、功能丰富的爬虫开源项目,到Github上找了一下找到这个,算是目前能找到的最好的了。
这里将它的文档翻译一下,期待更多的实用案例。
node-crawler
目标打造成Node社区最强大和流行的爬虫/内容抽取工具库,且支持生产环境。
特性:
更新日志:https://github.com/bda-research/node-crawler/blob/master/CHANGELOG.md
$ npm install crawler
var Crawler = require("crawler");
var c = new Crawler({
maxConnections : 10,
// 这个回调每个爬取到的页面都会触发
callback : function (error, res, done) {
if(error){
console.log(error);
}else{
var $ = res.$;
// $默认使用Cheerio
// 这是为服务端设计的轻量级jQuery核心实现
console.log($("title").text());
}
done();
}
});
// 爬取一个URL,使用默认的callback
c.queue('http://www.amazon.com');
// 爬取URL列表
c.queue(['http://www.google.com/','http://www.yahoo.com']);
// 爬取页面,自
今天逛测试之道论坛,发现这篇文章,虽然标题是写着为了面试,但其中的理论知识对在座的同仁也会有很大的帮助!
因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
我曾经做过web测试,后台测试,客户端软件,其中包括功能测试,性能测试,用户体验测试。最擅长的是功能测试
测试类型有:功能测试,性能测试,界面测试。
功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术**设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试
一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。
系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间
QPS(TPS):每秒钟request/事务 数量
并发数: 系统同时处理的request/事务数
响应时间: 一般取平均响应时间
(很多人经常会把并发数和TPS理解混淆)
理解了上面三个要素的意义之后,就能推算出它们之间的关系:
QPS(TPS)= 并发数/平均响应时间
一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素
我们做项目要排计划,可以多人同时并发做多项任务,也可以一个人或者多个人串行工作,始终会有一条关键路径,这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样,也有一条关键路径,这个关键路径是就是系统影响时间;
关键路径是有CPU运算、IO、外部系统响应等等组成。
我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。
而通常境况下,我们面对需求,我们评估出来的出来QPS、并发数之外,还有另外一个维度:日PV。
通过观察系统的访问日志发现,在用户量很大的情况下,各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。
通常的技术方法:
A)淘宝
一般来说,利用以下经验公式进行估算系统的平均并发用户数和峰值数据
1. 平均并发用户数为 C = nL/T
2. 并发用户数峰值 C‘ = C + 3*根号C
C是平均并发用户数,n是login session的数量,L是login session的平均长度,T是值考察的时间长度
C’是并发用户数峰值
举例1,假设系统A,该系统有3000个用户,平均每天大概有400个用户要访问该系统(可以从系统日志从获得),对于一个典型用户来说,一天之内用户从登陆到退出的平均时间为4小时,而在一天之内,用户只有在8小时之内会使用该系统。
那么,
平均并发用户数为:C = 400*4/8 = 200
并发用户数峰值为:C‘ = 200 + 3*根号200 = 243
举例2, 某公司为其170000名员工设计了一个薪酬系统,员工可进入该系统查询自己的薪酬信息,但并不是每个人都会用这个系统,假设只有50%的人会定期用该系统,这些人里面有70%是在每个月的最后一周使用一次该系统,且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为(朝九晚五):
n = 170000*0.5*0.7/5 = 11900
C= 11900*5/60/8 = 124
吞吐量计算为:F = Vu * R / T 单位为个/s
F为事务吞吐量,Vu为虚拟用户数个数,R为每个虚拟用户发出的请求数,T为处理这些请求所花费的时间
对绝大多数场景,我们用(用户总量/统计时间)*影响因子(一般为3)来进行估算并发量。
比如,以乘坐地铁为例子,每天乘坐人数为5万人次,每天早高峰是7到9点,晚高峰是6到7点,根据8/2原则,80%的乘客会在高峰期间乘坐地铁,则每秒到达地铁检票口的人数为50000*80%/(3*60*60)=3.7,约4人/S,考虑到安检,入口关闭等因素,实际堆积在检票口的人数肯定比这个要大,假定每个人需要3秒才能进站,那实际并发应为4人/s*3s=12,当然影响因子可以根据实际情况增大!
比如一个网站,每天的PV大概1000w,根据2/8原
在线用户数:用户同时在一定时间段的在线数量
并发用户数:某一时刻同时向服务器发送请求的用户数
一般而言,我们习惯以5-20的比率来推算并发用户与在线用户之间的关系。即,并发与在线的比例约为5%-20%
比如,某网站存在注册用户数为10W人,但同时在线最多1W人,但这1W个人,可能只有500人会浏览帖子,500人会进行发帖,只有这1000个人对服务器才有交易,那我们计算并发量的时候,就可以以1000为标准!
昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章,感觉学到了不少东西,以下将该书中的我认为是精华的一篇过来给大家一起看看:
在实际的性能测试中,经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”,下面用一个实际的例子来说明它们之间的差别。
假设有一个OA系统,该系统有2000个使用用户——这就是说,可能使用该OA系统的用户总数是2000名,这个概念就是“系统用户数”,该系统有一个“在线统计”功能(系统用一个全局变量记数所有已登录的用户),从在线统计功能中可以得到,最高峰时有500人在线(这个500就是一般所说的“同时在线人数”),那么,系统的并发用户数是多少呢?
根据我们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。当然,500这个数值只是表明在最高峰时刻有500个用户登录了系统,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间上,假设其中40%的用户在较有兴致地看系统公告(注意:“看”这个动作是不会对服务端产生任何负担的),20%的用户在填写复杂的表格(对用户填写的表格来说,只有在“提交”的时刻才会向服务端发送请求,填写过程是不对服务端构成压力的),20%部分用户在发呆(也就是什么也没有做),剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下,可以说,只有20%的用户真正对服务器构成了压力。因此,从上面的例子中可以看出,服务器实际承受的压力不只取决于业务并发用户数,还取决于用户的业务场景。
在实际的性能测试工作中,测试人员一般比
"<font>你好</font>"
<param name="MovieWindowWidth" value="320">;<b>hello</b>;alert("hello");doucment.write("abc");
<Script Language="JavaScript"> </script>;<br>;<tr>;<td>;</tr>;</td>;</html>;</body>;</table>
等