很多站長會發現把網站發布到服務器上后，網站訪問速度很慢。這個對網站來說是個致命傷，網站相應速度慢，即使網站做的很漂亮，內容很完整，客戶打開蝸牛一樣的也會失去耐心，可能直接關閉網站離開，這樣就導致用戶流失，最后發現網站每天都沒有人訪問了，另外還有一些網站做起來后流量越來越大，但是響應速度也越來越低，甚至有時候還會因并發請求太大而宕機。那么，對于這些問題，請求量大的網站，服務器該如何支撐?該如何提高網站速度呢？

通常情況下，我們會從下面幾點優化開始：1.要減少請求,對于開發人員----合并css,?背景圖片,?減少mysql查詢等.

2.對于運維?nginx的expires?,利用瀏覽器緩存等,減少查詢.

3.利用cdn來響應請求

4.最終剩下的,不可避免的請求----服務器集群+負載均衡來支撐.

所以,來到第4步后,就不要再考慮減少請求這個方向了.

而是思考如何更好的響應高并發請求.

大的認識-------既然響應是不可避免的,我們要做的是把工作內容”平均”分給每臺服務器.

最理想的狀態 每臺服務器的性能都被充分利用.

服務器介紹:服務器IP:

A??192.168.1.201

B??192.168.1.202

C?203

D?204

1臺?A

RAM:?2G

HD:?500G

3臺?B,?C,?D

RAM:?8G

Hd??:?200G

步驟:

1:A號服務器

1.1安裝?mysql

1.2并導入數據.

注意:先把表中的索引去掉,加快導入速度

2:?C號服務器:

2.1:?編譯PHP

注意:?enbale-fpm?,?with-mysql=mysqlnd???(編譯成獨立fpm進程,支持mysql,)

2.2:?下載第3方的memcached擴展?編譯進來

3:?D號服:

3.1?編譯?memcached

4:?B號服:

編譯nginx?,并配置

Cd?/app/pcre-8.12

./configure

Make?&&?make?install

Cd?nginx-1.2.7

./configure?--prefix=/usr/local/nginx?--add-module=/app/ngx_http_consistent_hash-master

注:紅線部分是nginx的第3方模塊,需要自己下載.

安裝統計模塊,便于觀察nginx的狀態

./configure?--prefix=/usr/local/nginx/?--add-module=/app/ngx_http_consistent_hash-master?--with-http_stub_status_module

Php 安裝配置1?tar?-xzvf??/path/’

2?cd?/path/

3?.configure?--prefix=/usr/local/php?--

服務器集群與負載均衡搭建完畢1:問題??C-->A?的mysql連接很慢

解決:?my.cnf中的[mysqld]節點中,添加

skip-name-resolve???//?這句話使mysql連接時忽略解析域名,在制定Mysql權限時,只能根據IP限制,不能根據域名限制.

2:?問題??當memcache中沒有相應的數據,從后臺回調數據時,

http的狀態碼是404,(雖然內容正常),這樣不利于SEO

解決:?nginx/conf/nginx.conf

error_page?404??=200?/callback.php;??//?這樣?404被改寫成200來響應中

壓力測試:模擬?前0-10萬是熱數據,

10-20萬是冷門數據

請求熱數據?0-10,請求9次

請求準予數據?請求1次,?????-----100萬次的請求.

優化思路:

nginx響應請求

1:建立socket連接

2:?打開文件,并沿socket返回.

排查問題,也要注意觀察這兩點,

主要從系統的dmesg?,和nginx的error.log來觀察

優化過程1:判斷nginx的瓶頸

1.1:?首先把ab測試端的性能提高,使之能高并發的請求.

易出問題:?too?many?open?files

原因?:??ab在壓力測試時,打開的socket過多

解決:?ulimit?-n?30000?(重啟失效)

觀察結果:?nginx?不需要特殊優化的情況下,?5000個連接,1秒內響應.

滿足要求,但?wating狀態的連接過多.

1.2:?解決waiting進程過多的問題.

解決辦法:?keepalive_timeout?=?0;

即:?請求結果后,不保留tcp連接.

在高并發的情況下,?keepalive會占據大量的socket連接.

結果:?waiting狀態的連接明顯減少.

1.3:?解決服務端?too?many?open?files

分析:?nginx要響應,

1是要建立socket連接,

2?是要讀本地文件

這兩個者限制.

由上圖可看出,nginx的問題容易出在2點上:1:?nginx接受的tcp連接多,能否建立起來?

2:?nginx響應過程,要打開許多文件?,能否打開?

第1個問題: 在內核層面(見下)

第2個問題 (見下)

系統內核層面:net.core.somaxconn?=?4096?允許等待中的監聽

net.ipv4.tcp_tw_recycle?=?1??tcp連接快速回收

net.ipv4.tcp_tw_reuse?=?1????tcp連接重用

net.ipv4.tcp_syncookies?=?0??不抵御洪水攻擊

ulimit?-n?30000

Nginx層面:解決:?nginx.conf?下面:?work_connection?加大

worker_connections??10240;

Worker_rlimit_nofiles?10000;

Keepalive_timeout?0;

Nginx---->php-fpm之間的優化

如上圖,在很多個nginx來訪問fpm時, fpm的進程要是不夠用, 會生成子進程.生成子進程需要內核來調度,比較耗時,

如果網站并發比較大,

我們可以用靜態方式一次性生成若干子進程,保持在內存中.方法?--?修改php-fpm.conf

Pm?=?static??讓fpm進程始終保持,不要動態生成

Pm.max_children=?32??始終保持的子進程數量

Php-mysql的優化Linux機器下?,php?通過IP連接其他mysql服務器時,容易出的問題

能ping能,但connect不到.

一般是由:mysql服務器的防火墻影響的. 并發1萬連接,響應時間過長.

優化思路: 同上的nginx1:?內核層面,加大連接數,并加快tcp回收

2:?mysql層面,增大連接數

3:?php層面,用長連接,節省連接數

4:?用memcached緩存,減輕mysql負擔

具體:1.1??,?PHP服務器增大?ulimint?-n選項

1.2?mysql服務器內核配置

添加或修改如下選項

net.ipv4.tcp_tw_recycle?=?1

net.ipv4.tcp_tw_reuse?=?1

net.ipv4.tcp_syncookies?=?0syscttl -p 使修改立即生效

2.1 修改mysql.cnfVi??/etc/my.conf

#?service?mysqld?restart?重啟mysql

3.1 PHP層面 ,用長連接Mysql_connect?--->?mysql_pconnect

注:?pconnect?在PHP以apache模塊的形式存在時,無效果.

Nginx+phjp+mysql+nginx

在引入memcached后,性能提升不明顯,甚至還略有下降

memcached使50%的請求變快了,但是一部分,反倒慢了.

原因在于--PHP->memcached也要建立tcp連接,代價挺高,

但緩存了數據之后,就省去了mysql的查詢時間.總結: memcached適合存復雜的sql,尤其是連接查詢/模糊查詢的sql結果

總結

以上是生活随笔為你收集整理的apache mysql php实现最大负载的方法_如何架设高性能nginx+php+mysql搭配的服务器，解决高并发问题...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。