阿弟：從300qps至3000qps的優化之路
原文連接： http://www.postgres.cn/news/viewone/1/283
原做者：阿弟 創做時間：2017-08-16 23:40:18
前言
如今的併發文章動不動就係統架構，虛得不行。網友阿弟寫的這篇反而從零開始步步實操，是篇好文章，至關值得借鑑週末基於這模式作個併發實踐，到時步驟也發佈到掘金好參考對比
背景
一個車貨匹配項目，初步估計有100萬司機。支持每秒500次查詢最新貨源列表，業務高峯時每分鐘大約10萬司機（包括大量無註冊司機）在線查詢最新的貨源訂單。即1500qps，固然還有不少低頻率的業務，如每秒幾筆貨源訂單。php
環境準備: 測試資源是線下開發機，非生產環境html
數據庫服務器
CPU：至強 4核 單線程nginx
RAM：32Ggit
硬盤：7200轉SAS 1T 2個作了raid1github
OS：Centos 6.4golang
網卡：1000Mweb
IP：192.168.1.6sql
應用服務器
CPU：至強 4核 單線程數據庫
RAM：32Gapache
硬盤：7200轉SAS 1T 2個作了raid1
OS：Centos 7.0
網卡：1000M
IP：192.168.1.10
交換機
H3C 1000M
平臺初步技術方案
基於公司目前技術儲備，咱們能夠選擇使用的組件有nginx/apache/php/go/pgbouncer/pg,這些組件能夠組合的架構仍是很豐富的，原則上能知足業務需求的狀況下，架構是越簡單越好。複雜的架構出問題的機率越高
但很明顯，整個系統的瓶頸確定是在各類Api與數據庫通訊這一環節上面,這是優化的重中之重
測試環境服務組件版本號
PostgreSQL 9.4.一、nginx-1.6.二、apache-2.2.3一、php-5.5.3八、pgbouncer-1.5.四、golang-1.7.3
一、PostgreSQL 9.4.1
編譯安裝
wget https://ftp.postgresql.org/pub/source/v9.4.1/postgresql-9.4.1.tar.gz
./configure --prefix=/home/ad/pgsql
gmake -j 4
gmake install
複製代碼
初始化
su postgres
/home/ad/pgsql/bin/initdb -D /home/ad/data -U postgres -E utf8 --locale=c -W
複製代碼
參數配置
listen_addresses = '*'
port = 9410
max_connections = 2000
superuser_reserved_connections = 3
shared_buffers = 6048MB
work_mem = 2MB
maintenance_work_mem = 512MB
autovacuum_work_mem = 512MB
synchronous_commit = on
checkpoint_segments = 32
checkpoint_timeout = 5min
checkpoint_completion_target = 0.5
checkpoint_warning = 30s
wal_level = minimal #單機模式
effective_cache_size = 32GB
log_destination = 'csvlog'
logging_collector = on
log_min_duration_statement = 1000
log_line_prefix = '%a %r %u %d %p'
log_statement = 'ddl'
track_activity_query_size = 4096
autovacuum = on
log_autovacuum_min_duration = 0
autovacuum_max_workers = 3
複製代碼
其它參數所有先默認
二、apache-2.2.31
編譯安裝
./configure --prefix=/home/ad/apache-2.2.31 --enable-rewrite --enable-deflate
--enable-expires --enable-headers --enable-modules=most --with-mpm=worker --enable-so
複製代碼
選擇worker-mpm模式
參數配置
Listen 8812
LoadModule php5_module modules/libphp5.so #這個是編譯好php後自動加上去的
User apache
Group apache
ServerName 127.0.0.1:8812
< Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
allow from all
</Directory>
<IfModule mime_module>
AddType application/x-httpd-php .php
</IfModule>
Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-default.conf
複製代碼
其它參數所有先默認
三、php-5.5.38
編譯安裝
wget http://cn2.php.net/get/php-5.5.38.tar.gz/from/this/mirror
mv mirror php-5.5.38.tar.gz
tar zxf php-5.5.38.tar.gz
cd php-5.5.38
./configure --prefix=/home/ad/php --with-apxs2=/home/ad/apache/bin/apxs
--with-pgsql=/home/ad/pgsql --enable-fpm
gmake -j 4
gmake install
複製代碼
參數配置
error_reporting = E_ALL & ~E_NOTICE
track_errors = Off
max_execution_time = 30
memory_limit = 128M
display_errors = On #生產環境不建議打開
log_errors = On
複製代碼
四、nginx-1.6.2
編譯安裝
wget http://nginx.org/download/nginx-1.6.2.tar.gz
tar zxf nginx-1.6.2.tar.gz
cd nginx-1.6.2
./configure --prefix=/home/ad/nginx --with-http_ssl_module --with-http_spdy_module
--with-http_stub_status_module --with-pcre
複製代碼
參數配置
user nginx nginx;
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;
error_log logs/error.log;
pid logs/nginx.pid;
events {
use epoll;
worker_connections 65535;
}
http {
include mime.types;
default_type application/octet-stream;
upstream openapi{
server 192.168.1.10:8812
}
server {
listen 6001;
server_name 192.168.1.10;
location / {
proxy_pass http://openapi;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
複製代碼
五、pgbouncer-1.5.4
pgbouncer鏈接池也裝在應用服務器上面
編譯安裝
安裝pgbouncer須要libevent包
wget https://github.com/downloads/libevent/libevent/libevent-2.0.19-stable.tar.gz
tar zxf libevent-2.0.19-stable.tar.gz
cd libevent-2.0.19-stable
./configure --prefix=/home/ad/libevent
gmake -j 4
gmake installl
--加載libevent動態庫
echo '/home/ad/libevent/lib' > /etc/ld.so.conf.d/libevent.conf
ldconfig
wget http://pgfoundry.org/frs/download.php/3393/pgbouncer-1.5.4.tar.gz
tar zxf pgbouncer-1.5.4
cd pgbouncer-1.5.4
./configure --prefix=/home/ad/pgbouncer/ --with-libevent=/home/ad/libevent/
gmake -j 4
gmake install
複製代碼
參數配置
運行參數文件/home/ad/pgbouncer/pgbouncer.ini
[databases]
car_goods_matching = host=192.168.1.6 port=9410 dbname=car_goods_matching
user=postgres password=pgsql
[pgbouncer]
listen_port = 9410
listen_addr = *
auth_type = md5
auth_file = /home/ad/pgbouncer/user.txt
logfile = /home/ad/pgbouncer/pgbouncer.log
pidfile = /home/ad/pgbouncer/pgbouncer.pid
admin_users = pgb_admin
pool_mode = session
max_client_conn = 65535
default_pool_size = 1024
client_idle_timeout = 60
idle_transaction_timeout = 30
複製代碼
用戶及口令文件/home/ad/pgbouncer/user.txt
"pgb_admin" "pgsql"
複製代碼
六、golang-1.7.3
直接安裝
yum install golang -y複製代碼
測試數據及腳本
一、數據庫環境
--創建測試庫
create database car_goods_matching;
--創建用戶表並生成100萬用戶數據,用戶註冊時間隨機分佈
CREATE TABLE public.users
(
id serial not null unique,
nickname text not null,
mobileno text not null unique,
createtime timestamp not null default now()
);
COMMENT ON TABLE public.users IS '用戶表';
COMMENT ON COLUMN public.users.id IS 'id號';
COMMENT ON COLUMN public.users.nickname IS '呢稱';
COMMENT ON COLUMN public.users.mobileno IS '手機號';
COMMENT ON COLUMN public.users.createtime IS '註冊時間';
--生成用戶數據
INSERT INTO public.users(nickname,mobileno,createtime) select
t::text,t::text,'2015-12-01'::timestamp + (random()*31449600)::integer *
interval '1 seconds' FROM generate_series(13800000001,13801000000) as t;
--創建索引
CREATE INDEX users_createtime_idx ON users USING BTREE(createtime);
--創建訂單表並生成1000萬訂單數據,用戶下單時間隨機分佈
CREATE TABLE orders
(
id serial not null unique,
createtime timestamp not null default now(),
users_id integer not null,
goods_name text not null
);
COMMENT ON TABLE public.orders IS '運力需求訂單表';
COMMENT ON COLUMN public.orders.id IS 'id號';
COMMENT ON COLUMN public.orders.createtime IS '下單時間';
COMMENT ON COLUMN public.orders.users_id IS '用戶id號';
COMMENT ON COLUMN public.orders.goods_name IS '貨源名稱';
--這是生成訂單的函數，天天30000訂單
CREATE OR REPLACE FUNCTION orders_make(a_date date) RETURNS TEXT AS
$$
BEGIN
INSERT INTO orders(users_id,goods_name,createtime)
SELECT
users.id,
md5(random()::Text),
a_date::timestamp + (random()*86399)::integer * interval '1 seconds'
FROM
users
WHERE
users.createtime < a_date
ORDER BY
random()
LIMIT 30000
;
RETURN 'OK';
END;
$$
LANGUAGE PLPGSQL;
COMMENT ON FUNCTION orders_make(a_date date) IS '生成訂單數據';
--調用函數生成數據，時間比較長，耐心等
SELECT orders_make('2015-12-01'::date + t) FROM generate_series(0,365) as t;
--把生成的數據序號從新生成
create sequence order_id_seq_tmp;
copy (select nextval('order_id_seq_tmp'),createtime,users_id,goods_name from orders
order by createtime) to '/home/pg/orders.txt';
truncate table orders;
copy orders from '/home/pg/orders.txt';
SELECT SETVAL('orders_id_seq',(select id FROM orders ORDER BY id DESC LIMIT 1));
DROP sequence order_id_seq_tmp;
--創建索引
CREATE INDEX orders_createtime_idx ON orders USING BTREE(createtime);
CREATE INDEX orders_users_id_idx ON orders USING BTREE(users_id);
--數據生成後記得作一下統計
vacuum analyze
複製代碼
二、測試程序
--調試性能使用hello.php
<?php
echo "hello world!!";
?>
--獲取訂單列表api接口goodslist.php
<?php
FUNCTION isint($val,$empty_is_true=FALSE)
{
$val=strval($val);
IF ($val=="" && !$empty_is_true)
{
RETURN FALSE;
}
ELSEIF($val=="" && $empty_is_true)
{
RETURN TRUE;
}
IF (STRVAL(INTVAL($val))!=STRVAL($val))
{
RETURN FALSE;
}
ELSE
{
RETURN TRUE;
}
}
//生成json字符串
FUNCTION openapi_json_encode($data)
{
if (version_compare(PHP_VERSION, '5.4.0', '>='))
{
RETURN json_encode($data,JSON_UNESCAPED_UNICODE);
}
else
{
RETURN json_encode($data);
}
}
IF (!isint($_GET['offset']))#偏移量
{
$_GET['offset']="0";
}
IF ($_GET['pool']=="1") #鏈接池
{
$conn=pg_connect("host=192.168.1.10 port=9410 dbname=car_goods_matching user=pgb_admin password=pgsql");
}
ELSE #直連
{
$conn=pg_connect("host=192.168.1.6 port=9410 dbname=car_goods_matching user=postgres password=pgsql");
}
$sql="SELECT orders.id,orders.createtime, orders.goods_name, users.nickname,users.mobileno FROM orders INNER JOIN users ON orders.users_id=users.id ORDER BY orders.id DESC OFFSET ".$_GET['offset']." LIMIT 10 " ;
$sql_result=pg_query($conn,$sql) ;
$data['return_code']="FAIL";
$data['data']= pg_fetch_all($sql_result);
IF ($data['data'])
{
$data['return_code']="SUCCESS";
}
ECHO openapi_json_encode($data);
pg_close($conn);
?>
複製代碼
性能校準
一、apache+php
短鏈接測試
配置apache,關閉長鏈接配置
vim /home/ad/apache/conf/extra/httpd-default.conf
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 5
複製代碼
重啓服務
/home/ad/apache/bin/apachectl restart複製代碼
在另一臺電腦上使用wrk工具進行測試
wrk -t4 -c8 -d60s http://192.168.1.10:8812/hello.php
Running 1m test @ http://192.168.1.10:8812/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 432.30us 768.90us 36.84ms 99.35%
Req/Sec 3.51k 186.91 4.02k 85.21%
837934 requests in 1.00m, 135.05MB read
Requests/sec: 13942.51
Transfer/sec: 2.25MB
複製代碼
使用atop查看服務器的資源使用狀況
http鏈接斷開等待狀況
netstat -n | grep -i TIME_WAIT | wc -l
6000
複製代碼
長鏈接測試
非全程長鏈接
vim /home/ad/apache/conf/extra/httpd-default.conf
KeepAlive On
MaxKeepAliveRequests 100 #鏈接超過100次請求就結束
KeepAliveTimeout 5 #鏈接超過5秒就結束
複製代碼
跑wrk測試
wrk -t4 -c8 -d60s http://192.168.1.10:8812/hello.php
Running 1m test @ http://192.168.1.10:8812/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.96ms 21.25ms 444.92ms 99.33%
Req/Sec 5.91k 748.39 7.90k 80.88%
1405959 requests in 1.00m, 201.38MB read
Requests/sec: 23393.64
Transfer/sec: 3.35MB
複製代碼
使用atop查看服務器的資源使用狀況
全程長鏈接
vim /home/ad/apache/conf/extra/httpd-default.conf
KeepAlive On
MaxKeepAliveRequests 1000000
KeepAliveTimeout 60
複製代碼
跑wrk測試
wrk -t4 -c8 -d60s http://192.168.1.10:8812/hello.php
Running 1m test @ http://192.168.1.10:8812/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 356.51us 722.91us 37.48ms 99.30%
Req/Sec 6.34k 315.97 6.91k 93.21%
1513403 requests in 1.00m, 216.49MB read
Requests/sec: 25213.26
Transfer/sec: 3.61MB
複製代碼
使用atop查看服務器的資源使用狀況
從上面測試的結果來看，在高併發，高壓力的狀況下，進程複用能夠提升一倍的系統性能。短鏈接時產生了大量的TIME_WAIT進程，產生的緣由主要是客戶端不斷的鏈接和斷開，在高併發的狀況下，服務器遲遲沒收到客戶端斷開鏈接的第四次握手信號形成的，這些進程會一直佔用locale port, 致使本地端口號給消耗光了。能夠設置下面的內核參數來提升locale port的使用效率
net.ipv4.tcp_syncookies = 1 #表示開啓SYN Cookies,可防範少許SYN攻擊，默認爲0
net.ipv4.tcp_tw_reuse = 1 #容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認是0
net.ipv4.tcp_tw_recycle = 1 #表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認是0
net.ipv4.ip_local_port_range = 1024 65535 #增大locale port數量，默認是從32768開始
不過這幾個參數是治標不治本，最終仍是要回到提高api自己的處理能力.另外對於動態的api接口業務，若是你的客戶端直接與apache進行通訊，現實中基本都是短鏈接業務，因此用apache+php跑個13000已是極限了。
二、nginx+apache+php
nginx與apache短鏈接通訊
下面咱們來看看nginx+apache+php在短鏈接的狀況下，locale port是怎樣給消耗光的，nginx+apache+php見上面的配置
使用wrk工具對nginx進行壓力測試
wrk -t4 -c8 -d60s http://192.168.1.10:6001/hello.php
Running 1m test @ http://192.168.1.10:6001/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 13.02ms 89.80ms 1.00s 97.80%
Req/Sec 2.24k 1.00k 3.20k 82.52%
112423 requests in 1.00m, 17.06MB read
Socket errors: connect 0, read 0, write 76, timeout 41
Non-2xx or 3xx responses: 41
Requests/sec: 1871.76
Transfer/sec: 290.91KB
複製代碼
使用atop查看服務器的資源使用狀況
在測試到一半的時候再打開一個終端，測試一下服務器是否還有接受請求的能力，發現鏈接超時，使用top查看系統負載狀況，居然沒負載
curl http://192.168.1.10:6001/
curl: (7) Failed connect to 192.168.1.10:6001; 鏈接超時
複製代碼
1871次/秒的處理能力，還有timeout狀況，是否是懷疑nginx有問題，其實這不是nginx的問題，主要是nginx處理能力太強了，而apache跑php弱了，致使進程一直佔用socket port,咱們只須要作一下這樣的調整，服務器的處理能力就上來了
nginx與apache長鏈接通訊
upstream openapi{
server 192.168.1.10:8812
keepalive 1000000;
}
server {
listen 6001;
server_name 192.168.1.10;
location / {
proxy_pass http://openapi;
proxy_http_version 1.1; #nginx默認是http1.0協議，http1.0不支持長鏈接
proxy_set_header Connection "";
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
複製代碼
wrk -t4 -c8 -d60s http://192.168.1.10:6001/hello.php
Running 1m test @ http://192.168.1.10:6001/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.07ms 9.61ms 258.20ms 99.47%
Req/Sec 4.07k 267.78 5.77k 88.93%
969902 requests in 1.00m, 147.02MB read
Requests/sec: 16138.11
Transfer/sec: 2.45MB複製代碼
使用atop查看服務器的資源使用狀況
客戶端與nginx長鏈接通訊，nginx與apache長鏈接通訊
wrk -t4 -c8 -d60s http://192.168.1.10:6001/hello.php
Running 1m test @ http://192.168.1.10:6001/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 627.20us 2.94ms 115.11ms 99.32%
Req/Sec 4.18k 352.11 6.90k 81.97%
998513 requests in 1.00m, 151.41MB read
Requests/sec: 16614.20
Transfer/sec: 2.52MB
複製代碼
看上去數據變化不大，可是TIME_WAIT量明顯減小了
netstat -n | grep -i TIME_WAIT|wc -l
97
複製代碼
因爲nginx和apache是跑在同一個節點上，cpu互相爭用，因此併發數下來，若是跑在不一樣的機器上，nginx代理的損耗實際上是很是小的，看看下面的測試就會知道
nginx與apache長鏈接通訊（不一樣節點）
nginx位於應用服務器
apache位於數據庫服務器
wrk -t4 -c8 -d60s http://192.168.1.10:6001/hello.php
Running 1m test @ http://192.168.1.10:6001/hello.php
4 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 433.26us 1.32ms 54.39ms 99.11%
Req/Sec 5.92k 561.30 6.53k 90.67%
1414121 requests in 1.00m, 213.08MB read
Requests/sec: 23567.56
Transfer/sec: 3.55MB
複製代碼
# 架構 鏈接數 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 time_wait佔用數
1 apache短鏈接 12392 99 24.75% 149 0.3725 6000
2 apache長鏈接 24186 110 27.50% 245 0.6125 2500
3 apache全程長鏈接 25213 110 27.50% 227 0.5675 8
4 nginx+apache短鏈接 1871 2 0.50% 1 0.0025 6000
5 nginx+apache長鏈接 16138 115 28.75% 183 0.4575 4800
6 nginx長鏈接+apache長鏈接 16614 123 30.75% 196 0.49 97
複製代碼
從上面的測試數據來看，建議高併發簡單業務的接口採用第5種方案，若是是web網頁與接口混合使用的，使用第6種模式
4、業務測試
爲了測試更接近於實際業務場景，此次使用http_load工具，http_load使用單進程併發多個線程進行併發測試，訪問nginx時採用的是非長鏈接訪問，而且能夠設置每秒訪問接口次數，http_load測試特別說明
單進程限制每秒1000次訪問
參數爲-r 334（超過1000的三分之一）時，實際上能跑到500次/秒的訪問量
參數爲-r 501（超過1000的二分之一）時，測試端cpu會跑滿
因此跑每秒500次訪問時參數是-r 334, 跑每秒1000次訪問時啓用兩個-r 334 http_load進程來測試，依此類推
模擬每秒100次訪問，持續訪問300秒
http_load -r 100 -s 300 /home/ad/urls.txt複製代碼
模擬每秒500次訪問，持續訪問300秒
http_load -r 334 -s 300 /home/ad/urls.txt複製代碼
由於測試工具佔用cpu資源仍是比較大，須要另一臺主機上運行，這樣測試更準確
一、nginx+apache+php+pgsql
[root@cqs ~]# echo 'http://192.168.1.10:6001/goodslist.php?pool=0&offset=0'
> /home/ad/urls.txt
複製代碼
測試結果
每秒100次訪問
[root@cqs ~]# http_load -r 100 -s 300 /home/ad/urls.txt
29999 fetches, 96 max parallel, 4.42485e+07 bytes, in 300 seconds
1475 mean bytes/connection
99.9967 fetches/sec, 147495 bytes/sec
msecs/connect: 0.471398 mean, 2.057 max, 0.23 min
msecs/first-response: 12.5897 mean, 992.857 max, 7.751 min
HTTP response codes:
code 200 -- 29999
複製代碼
其它略，下面是測試結果對比表
數據庫服務器壓力對比
次數/秒 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 總使用量 總佔比
100 37 9.25% 35 8.75% 72 18.00%
200 73 18.25% 70 17.50% 143 35.75%
300 115 28.75% 104 26.00% 219 54.75%
400 148 37.00% 140 35.00% 288 72.00%
複製代碼
應用服務器壓力對比
次數/秒 time_wait佔用數 load average 502次數 佔比 locale port
100 6000 0.2 0
200 6000 0.2 0
300 6000 0.3 0
400 6000 0.5 20430 17.03% 消耗完
複製代碼
從上面的數據來看，qps爲400時數據庫服務器就出現了不穩定狀況，並且應用服務器的locale port會被消耗光。經過對數據的對比，發現數據庫服務器sys_cpu比user_cpu佔用量還要大，緣由與上面應用服務性能測試時一致，就是在高併發時，進程不斷鏈接和關閉過分消耗了cpu資源。應用服務器locale port給佔完，致使http請求失敗。得想辦法讓應用程序與pg服務鏈接進程能夠複用，減小數據庫服務器的cpu壓力才行，上pgbouncer鏈接池吧。
下面先說一下，怎樣查詢pg進程有沒複用，使用捉包工具tcpdump捉取兩次獨立請求時鏈接數據庫的local port ，如port一致則就是進程複用，以下所示
在數據庫服務器上的一個終端輸入下面命令
tcpdump -n -i em1 dst 192.168.1.6複製代碼
在測試機上連續輸入下面命令二次，非鏈接池鏈接
crul 'http://192.168.1.10:6001/goodslist.php?pool=0&offset=0'複製代碼
在tcpdump終端你會看到下面的信息，對應的locale port不一致
17:11:01.816414 IP 192.168.1.10.61048 > 192.168.1.6.pyrrho: Flags [.], ack 1505,
win 37, length 0
17:11:03.250386 IP 192.168.1.10.61053 > 192.168.1.6.pyrrho: Flags [S], seq 724980759,
win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
17:11:03.250594 IP 192.168.1.10.61053 > 192.168.1.6.pyrrho: Flags [.], ack 3440127706,
win 29, length 0
複製代碼
在測試機上連續輸入下面命令二次，鏈接池鏈接
crul 'http://192.168.1.10:6001/goodslist.php?pool=1&offset=0'
複製代碼
在tcpdump終端你會看到下面的信息，對應的locale port一致
17:14:35.184299 IP 192.168.1.10.61068 > 192.168.1.6.pyrrho: Flags [P.], seq 92:449,
ack 332, win 31, length 357
17:14:35.189180 IP 192.168.1.10.61068 > 192.168.1.6.pyrrho: Flags [P.], seq 449:466,
ack 1504, win 37, length 17
17:14:35.229312 IP 192.168.1.10.61068 > 192.168.1.6.pyrrho: Flags [.],
ack 1584, win 37, length 0
複製代碼
二、nginx+apache+php+pgbouncer+pgsql
[root@cqs ~]# echo 'http://192.168.1.10:6001/goodslist.php?pool=1&offset=0'
> /home/ad/urls.txt
複製代碼
每秒100次訪問
[root@cqs ~]# http_load -p 100 -r 100 -s 300 /home/ad/urls.txt
29999 fetches, 13 max parallel, 4.42485e+07 bytes, in 300.001 seconds
1475 mean bytes/connection
99.9962 fetches/sec, 147494 bytes/sec
msecs/connect: 0.546002 mean, 5.094 max, 0.244 min
msecs/first-response: 2.80047 mean, 129.88 max, 2.012 min
HTTP response codes:
code 200 -- 29999
複製代碼
其它略，下面是測試結果對比表
數據庫服務器壓力對比
次數/秒 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 總使用量 總佔比
100 1 0.25% 9 2.25% 10 2.50%
200 2 0.50% 20 5.00% 22 5.50%
300 2 0.50% 32 8.00% 34 8.50%
400 3 0.75% 49 12.25% 52 13.00%
複製代碼
應用服務器壓力對比
次數/秒 time_wait佔用數 load average 502次數 佔比 locale port
100 6000 0.1 0
200 6000 0.2 0
300 6000 0.4 0
400 6000 0.5 18487 15.41% 消耗完
複製代碼
從上面的數據來看，qps爲400時數據庫服務器壓力很是的小，但應用服務器與數據庫服務器的通訊效率過低，致使應用服務器的locale port被消耗光，http服務拒絕鏈接，瓶頸在應用與鏈接池的通訊效率上，只能水平擴展多一些應用服務器節點了，
下面看看雙應用服務器節點的性能是否是會提升
三、nginx負載雙節點(apache+php)+pgbouncer+pgsql
nginx.conf配置以下
首先在數據庫節點上也裝上apache/php/pgbouncer
接着修改應用節點上的nginx.conf配置，以下
upstream openapi{
server 192.168.1.10:8812 weight=6;
server 192.168.1.6:8812 weight=4;
keepalive 1000000;
}
複製代碼
重啓nginx服務
/home/ad/nginx/sbin/nginx -s reload複製代碼
測試開始
[root@cqs ~]# echo 'http://192.168.1.10:6001/goodslist.php?pool=1&offset=0' >
/home/ad/urls.txt
複製代碼
每秒100次訪問
[root@cqs ~]# http_load -r 100 -s 300 /home/ad/urls.txt
29999 fetches, 38 max parallel, 4.42485e+07 bytes, in 300 seconds
1475 mean bytes/connection
99.9967 fetches/sec, 147495 bytes/sec
msecs/connect: 0.681952 mean, 11.494 max, 0.258 min
msecs/first-response: 3.68105 mean, 403.703 max, 2.131 min
HTTP response codes:
code 200 -- 29999
複製代碼
其它略，下面是測試結果對比表
次數/秒 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 總使用量 總佔比
100 4 1.00% 12 3.00% 16 4.00%
200 6 1.50% 23 5.75% 29 7.25%
300 9 2.25% 34 8.50% 43 10.75%
400 13 3.25% 48 12.00% 61 15.25%
500 15 3.75% 60 15.00% 75 18.75%
600 20 5.00% 78 19.50% 98 24.50%
複製代碼
應用服務器壓力對比
次數/秒 time_wait佔用數 load average 502次數 佔比 locale port
100 4800 0.2 0
200 6000 0.2 0
300 6000 0.3 0
400 6000 0.4 0
500 6000 0.6 0
600 6000 0.6 2725 1.51% 消耗完
複製代碼
從上面的數據來看，應用服務器水平擴展以後，併發數也跟着上來了，並且數據庫服務器的壓力仍是在能夠接受的範圍以內，雖然知足了業務的初步請求，但仍是沒法對付峯值請求，若是想處理更大的併發量，要再也不水平擴展應用服務器，另外一個就是想辦法提升「應用程序與pg」的通訊效率，下面使用go來實現這些架構，看看是否是會提升。
四、基於go的後端服務架構
這是go的服務端程序
car_goods_matching.go
package main
import (
"fmt"
"github.com/valyala/fasthttp"
"github.com/jackc/pgx"
"os"
"strconv"
"encoding/json"
)
var pool *pgx.ConnPool
type Row struct {
Id int `json:"id"`
Createtime string `json:"createtime"`
Goods_name string `json:"goods_name"`
Nickname string `json:"nickname"`
Mobileno string `json:"mobileno"`
}
type Data struct {
Return_code string `json:"return_code"`
Rows []Row `json:"data"`
}
func httpHandle(w *fasthttp.RequestCtx) {
offset := string(w.QueryArgs().Peek("offset"))
if offset == "" {
offset = "0"
}
sql := `
SELECT
orders.id,orders.createtime::text,
orders.goods_name,
users.nickname,users.mobileno
FROM
orders
INNER JOIN users ON orders.users_id=users.id
ORDER BY
orders.id DESC
OFFSET
` + offset + `
LIMIT 10
`
rows, err := pool.Query(sql)
checkErr(err)
defer rows.Close()
w.SetContentType("text/html")
var data Data = Data{}
data.Rows = make([]Row,0)
data.Return_code="FAIL"
for rows.Next() {
var row Row
err = rows.Scan( &row.Id , &row.Createtime , &row.Goods_name , &row.Nickname , &row.Mobileno )
checkErr(err)
data.Rows = append(data.Rows,row)
}
if len(data.Rows)>0 {
data.Return_code="SUCCESS"
}
ret, _ := json.Marshal(data)
fmt.Fprintf(w,"%s",string(ret))
}
func main() {
var err error
poolnum,err := strconv.Atoi(os.Args[1])
checkErr(err)
connPoolConfig := pgx.ConnPoolConfig{
ConnConfig: pgx.ConnConfig{
Host: "192.168.1.6",
User: "postgres",
Password: "pgsql",
Database: "car_goods_matching",
Port: 9410,
},
MaxConnections: poolnum,
}
pool, err = pgx.NewConnPool(connPoolConfig)
checkErr(err)
if err := fasthttp.ListenAndServe("0.0.0.0:8091", httpHandle); err != nil {
fmt.Println("start fasthttp fail:", err.Error())
}
}
func checkErr(err error) {
if err != nil {
panic(err)
}
}
複製代碼
啓動服務，配置8個鏈接數
go run car_goods_matching.go 8 複製代碼
測試開始
[root@cqs ~]# echo 'http://192.168.1.10:8091/?offset=0' >/home/ad/urls.txt
複製代碼
每秒100次訪問
[root@cqs ~]# http_load -r 100 -s 300 /home/ad/urls.txt
29999 fetches, 6 max parallel, 4.57185e+07 bytes, in 300 seconds
1524 mean bytes/connection
99.9966 fetches/sec, 152395 bytes/sec
msecs/connect: 0.601967 mean, 7.028 max, 0.245 min
msecs/first-response: 2.2164 mean, 64.464 max, 1.707 min
HTTP response codes:
code 200 -- 29999
複製代碼
其它略，下面是測試結果對比表
數據庫服務器壓力對比
次數/秒 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 總使用量 總佔比
100 1 0.25% 8 2.00% 9 2.25%
200 2 0.50% 18 4.50% 20 5.00%
300 2 0.50% 26 6.50% 28 7.00%
400 2 0.50% 35 8.75% 37 9.25%
500 3 0.75% 42 10.50% 45 11.25%
600 3 0.75% 52 13.00% 55 13.75%
1000 8 2.00% 71 17.75% 79 19.75%
1500 8 2.00% 118 29.50% 126 31.50%
2000 11 2.75% 145 36.25% 156 39.00%
3000 17 4.25% 214 53.50% 231 57.75%
複製代碼
應用服務器壓力對比
次數/秒 time_wait佔用數 load average 502次數 佔比 socket佔用
100 5200 0.1 0
200 6000 0.1 0
300 6000 0.1 0
400 6000 0.2 0
500 6000 0.3 0
600 6000 0.3 0
1000 6000 0.3 0
1500 6000 0.3 0
2000 6000 0.6 0
3000 6000 0.6 0
複製代碼
從上面的測試數據咱們能夠看到基於go的服務端應用程序因爲每次處理業務時都不須要與應用程序進行通訊，也不須要與數據庫進行鏈接，因此其sys cpu消耗的極其的低，編譯型程序，執行效率也高，在併發到3000的qps時，數據庫的cpu負載才過一半。因而可知使用Go服務端應用來支撐業務簡單的高併發應用是很是適合的方案。
爲了更友好的對外通訊，統一api入口，咱們使用nginx作web服務入口，再代理跑各類應用，如今來看看nginx代理跑go性能是否也能知足
五、基於nginx+go的後端服務架構
nginx上的配置，記得配置nginx與go通訊採用長鏈接哦
#增長一個openapi_goodslist分組，最後的nginx.conf配置以下
user nginx nginx;
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;
error_log logs/error.log;
pid logs/nginx.pid;
events {
use epoll;
worker_connections 65535;
}
http {
include mime.types;
default_type application/octet-stream;
upstream openapi{
#ip_hash;
server 192.168.1.10:8812
#其它節點
keepalive 1000000;
}
# goodslist接口應用
upstream openapi_goodslist{
server 192.168.1.10:8091 ;
#其它節點
keepalive 1000000;
}
server {
listen 6001;
server_name 192.168.1.10;
#配置訪問路由
location /openapi/goodslist{
proxy_pass http://openapi_goodslist;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
location / {
proxy_pass http://openapi;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
複製代碼
下面是測試結果對比表
數據庫服務器壓力對比
次數/秒 系統cpu使用量 系統cpu佔比 用戶cpu使用量 用戶cpu佔比 總使用量 總佔比
100 1 0.25% 8 2.00% 9 2.25%
200 2 0.50% 18 4.50% 20 5.00%
300 2 0.50% 26 6.50% 28 7.00%
400 2 0.50% 35 8.75% 37 9.25%
500 3 0.75% 42 10.50% 45 11.25%
600 3 0.75% 52 13.00% 55 13.75%
1000 9 2.25% 68 17.00% 77 19.25%
1500 10 2.50% 112 28.00% 122 30.50%
2000 13 3.25% 141 35.25% 154 38.50%
3000 19 4.75% 210 52.50% 229 57.25%
複製代碼
應用服務器壓力對比
次數/秒 time_wait佔用數 load average 502次數 佔比 socket佔用
100 5200 0.1 0
200 6000 0.1 0
300 6000 0.1 0
400 6000 0.2 0
500 6000 0.3 0
600 6000 0.4 0
1000 6000 0.4 0
1500 6000 0.4 0
2000 6000 0.8 0
3000 6000 0.8 0
複製代碼
加了nginx代理以後對數據庫的性能沒影響，只是應用服務器的cpu開銷大了一點，這個損耗是在可接受範圍以內的，並且也能夠將nginx與應用服務節點進行分離到不一樣的節點上面。
5、測試結果對比
序號 項目 qps峯值 300次/秒cpu壓力
1 nginx+apache+php+pgsql 300 219
2 nginx+apache+php+pgbouncer+pgsql 300 34
3 nginx+apache+php+pgbouncer+pgsql雙節點 500 43
4 基於go框架的實現 3000 28
5 nginx+go 3000 28
複製代碼
各類框架處理qps峯值－－值越大越好
各類框架處理300qps時cpu壓力－－值越小越好
以上是對於高併發，業務極其簡單的接口在通訊架構上的一種優化方式，具體採用哪一種構架來搭建大家的應用，須要具體業務具體優化，靈活搭配就是，另外還要考慮運維的成本。
相關文章
- 1. Vue項目優化：從3.19MB到684KB的優化之路
- 2. LSTM 優化之路
- 3. bitcount優化之路
- 4. iOS優化之路
- 5. MySql優化之路
- 6. SQL優化之路
- 7. Webpack4優化之路
- 8. sparksql優化之路
- 9. Android之WebView優化之路
- 10. Android 優化之路(一)佈局優化
- 更多相關文章...
- • MySQL的優勢（優點） - MySQL教程
- • SEO - 搜索引擎優化 - 網站建設指南
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • 適用於PHP初學者的學習線路和建議
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Vue項目優化：從3.19MB到684KB的優化之路
- 2. LSTM 優化之路
- 3. bitcount優化之路
- 4. iOS優化之路
- 5. MySql優化之路
- 6. SQL優化之路
- 7. Webpack4優化之路
- 8. sparksql優化之路
- 9. Android之WebView優化之路
- 10. Android 優化之路(一)佈局優化