php網站性能優化

1、如何優化PHP性能

如果一個方法能被靜態，那就聲明它為靜態的，速度可提高1/4，甚至我測試的時候，這個提高了近三倍。
當然了，這個測試方法需要在十萬級以上次執行，效果才明顯。
其實靜態方法和非靜態方法的效率主要區別在內存：靜態方法在程序開始時生成內存,實例方法在程序運行中生成內存，所以靜態方法可以直接調用,實例方法要先成生實例,通過實例調用方法，靜態速度很快，但是多了會占內存。
任何語言都是對內存和磁碟的操作,至於是否面向對象,只是軟體層的問題,底層都是一樣的,只是實現方法不同。靜態內存是連續的,因為是在程序開始時就生成了,而實例申請的是離散的空間,所以當然沒有靜態方法快。
靜態方法始終調用同一塊內存，其缺點就是不能自動進行銷毀，而是實例化可以銷毀。

2、PHP開發中如何提高系統的穩定性和可靠性

PHP 應用的高性優化，很多時候我們把業務代碼做一些優化，反而是簡單又高效的。

業務的非同步解耦，比如，我們把耗時的多個分表數據的排行榜，通過其他服務做分布統計，然後再綜合，最終輸出到redis list 中，那我們前端 PHP 在調用數據的時候，就不用實時計算了。

緩存的多級處理，業務復雜以後，經常看到一份相同的數據讀取 N 次，盡管是有緩存伺服器，但是讀取的時候也會有網路 I/O 的開銷，考慮到我們 PHP 一般使用場景下都是單進程，使用頻率高的，則應該優先使用進程內緩存。然後再本地緩存，然後再到網路緩存。

單例的運用，不要小看了對象的構造，很多時候我們在同一進程中，會發現同時構造了 N 多相同的對象。每一次的初始化都是一塊內存的開辟和 CPU 的消耗。

高性能，一個就是運行環境的優化，另一個是代碼本身的優化。

運行環境的優化，覆蓋面也很廣，包括系統層面的內核，文件系統類型，資料庫及緩存服務本身的性能優化，再到PHP解釋器的性能優化等等，PHP不同運行方式的差異（比如Apache模塊，還有PHP-FPM等等）。

代碼優化方面，我覺得可維護性和代碼可讀性的重要性大於高性能。代碼優化可以藉助profiling工具來分析，找到真實訪問條件下，處理瓶頸在哪裡，再去做針對性的優化。當然自己在初次設計和實現的時候，就需要做一定的整體考慮，例如怎麼設計能夠減少資料庫的查詢次數，如何減少重復的操作，了解同一問題的多種解決辦法哪一種效率更高（包括演算法上的差異，以及PHP的不同方式導致的差異等等），如何設計緩存來提高緩存命中率等等。有一些設計需要在體驗和效率上做個權衡。

保證穩定性，同樣也分運行環境和代碼本身。前者要對線上服務做完整的監控，這個有很多完善和強大的開源工具可以使用，保障基礎環境是穩定可控的，並且能夠及時發現問題，進行修復。至於代碼，除了盡量做完整的測試，開發的時候就需要考慮可能的問題。另外針對PHP，開發環境可以把error_reporting完全打開。還有需要知道常見的安全問題（XSS，SQL注入，CSRF，越權等），畢竟安全問題也是穩定的一部分。

3、如何設置寶塔面板優化php伺服器性能

1.定期釋放內存
2.添加swap
3.安裝php緩存擴展
4.php配置調整
5.php並發調整
6.php版本和mysql數據版本
7.卸載多餘擴展插件
8.搭配阿里雲存儲oss使用
以上純手打。只是列出個大概。具體還得自己慢慢優化。

4、如何對低硬體配置的中小型php網站進行性能優化

本人對php不熟悉，現在採用PHP的magento開源項目來做，在盡量少代碼修改的情況下讓頁面載入快些（期望日IP少於2,000，PV少於50,000，首頁打開3s以內）。網站是運行在Digital ocean的VPS（1GB 內存，30GB SSD硬碟）上的，不能做負載均衡。
這個站的圖片比較多，也比較大，但總體數據量在10GB以下。在chrome下監控了打開速度，發現首頁文件等待時間達到了5s，而接收時間為幾百毫秒。另外一些靜態文件（JS，CSS很大，並且都在head內）也block住了其他頁面元素的下載和頁面渲染。所以需要對頁面和伺服器同時進行優化。
我的想法是從以下幾個方面來做：
1.首先從架構上使用lanmp（偏向這個）或者lamp。
打算使用網上的一鍵安裝包，不太清楚這幾個之間最佳的版本組合是什麼樣的（都用最新版本？）? 是自己單獨編譯還是一鍵安裝好？
2.服務端優化，主要使用緩存手段
1）Zend Optimizer優化PHP
2）APC、eaccelerator或者XCache對PHP緩存以及最新出來的Opcache。哪個比較好？
3）Varnish配合Nginx進行緩存靜態資源緩存。相對於squid，哪個比較好？
4）memcached進行資料庫緩存
1-4項同時使用不知道會不會有沒有沖突？或者有沒有更好的方案。因為不想對代碼進行大改，所以服務端緩存最佳實踐這塊請重點給出意見。
3. 使用CDN加速靜態資源
4. 優化靜態資源，使用minify來合並壓縮CSS,JS這些靜態資源
5. 啟用gzip
6. 對圖片和JS等靜態資源增加Expires頭，這條應該算頁面優化吧，放到後面來。
參考了一些資料後發現優化方法有很多，用的太多方法（特別是緩存手段）隱患越大，有沒有優化的最佳策略或者方法論（而不僅僅從工具上）？

5、thinkphp百萬pv網站性能怎麼優化

提高網站相應速度首先要減少頁面當中的JS文件，其次要保證頁面的大小不超過60K為最好。這是在建站時的硬性要求。
也可以用百度、360這類雲加速，提高自己網站的響應速度。

6、關於php性能優化，網上看到這樣一句話：面向對象往往開銷很大，每個方法和調用都會消耗很多內存。請問

別太相信專家來，他說的面向源對象指的是 使用mvc模式，這是會有一定的開銷。但很大這個詞用不上，大這個也用不上，應該是很少。不過也得看你代碼的水平。你看一下好的框架。速度是杠杠的。為什麼面向對象框架這么受歡迎。就是因為他好用。每樣東西都有優缺點，但只要權衡輕重就行了。存在必然有其存在的道理。流行必然也是因為他好。。。

但換句話說，不是高手不用面向對象寫出來的代碼更差。而且沒法維護。

7、如何設置BT寶塔面板並優化php伺服器性能

設置寶塔面板需要安裝組件，然後參考寶塔面板優化 php 伺服器性能，按照裡面的設置，一項項的操作完畢，就差不多了。

寶塔面板把優化php已經變成一件很簡單的事情了。

8、php+mysql優化，百萬至千萬級快速分頁mysql性能到底能有多高

php+Mysql 優化，百萬至千萬級快速分頁

MySql 性能到底能有多高？用了php半年多，真正如此深入的去思考這個問題還是從前天開始。有過痛苦有過絕望，到現在充滿信心！MySql 這個資料庫絕對是適合dba級的高手去玩的，一般做一點1萬篇新聞的小型系統怎麼寫都可以，用xx框架可以實現快速開發。可是數據量到了10萬，百萬至千萬，他的性能還能那麼高嗎？一點小小的失誤，可能造成整個系統的改寫，甚至更本系統無法正常運行！好了，不那麼多廢話了。用事實說話，看例子：
數據表 collect ( id, title ,info ,vtype) 就這4個欄位，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往裡面填充數據，填充10萬篇新聞。
最後collect 為 10萬條記錄，資料庫表佔用硬碟1.6G。OK ,看下面這條sql語句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 從9萬條開始分頁，結果？
8-9秒完成，my god 哪出問題了？？？？其實要優化這條數據，網上找得到答案。看下面一條語句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。為什麼？因為用了id主鍵做索引當然快。網上的改法是：
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;
這就是用了id做索引的結果。可是問題復雜那麼一點點，就完了。看下面的語句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了這里我相信很多人會和我一樣，有崩潰感覺！vtype 做了索引了啊？怎麼會慢呢？vtype做了索引是不錯，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，從9萬開始，那就是0.05*90=4.5秒的速度了。和測試結果8-9秒到了一個數量級。從這里開始有人提出了分表的思路，這個和discuz 論壇是一樣的思路。思路如下：
建一個索引表： t (id,title,vtype) 並設置成定長，然後做分頁，分頁出結果再到 collect 裡面去找info 。 是否可行呢？實驗下就知道了。
10萬條記錄到 t(id,title,vtype) 里，數據表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。為什麼會這樣呢？我猜想是因為collect 數據太多，所以分頁要跑很長的路。limit 完全和數據表的大小有關的。其實這樣做還是全表掃描，只是因為數據量小，只有10萬才快。OK，來個瘋狂的實驗，加到100萬條，測試性能。
加了10倍的數據，馬上t表就到了200多M，而且是定長。還是剛才的查詢語句，時間是0.1-0.2秒完成！分表性能沒問題？錯！因為我們的limit還是9萬，所以快。給個大的，90萬開始
select id from t where vtype=1 order by id limit 900000,10; 看看結果，時間是1-2秒！
why 　 分表了時間還是這么長，非常之郁悶！有人說定長會提高limit的性能，開始我也以為，因為一條記錄的長度是固定的，mysql 應該可以算出90萬的位置才對啊？ 可是我們高估了mysql 的智能，他不是商務資料庫，事實證明定長和非定長對limit影響不大？怪不得有人說 discuz到了100萬條記錄就會很慢，我相信這是真的，這個和資料庫設計有關！
難道MySQL 無法突破100萬的限制嗎？？？到了100萬的分頁就真的到了極限？？？
答案是： NO !!!! 為什麼突破不了100萬是因為不會設計mysql造成的。下面介紹非分表法，來個瘋狂的測試！一張表搞定100萬記錄，並且10G 資料庫，如何快速分頁！
好了，我們的測試又回到 collect表，開始測試結論是： 30萬數據，用分表法可行，超過30萬他的速度會慢道你無法忍受！當然如果用分表+我這種方法，那是絕對完美的。但是用了我這種方法後，不用分表也可以完美解決！
答案就是：復合索引！有一次設計mysql索引的時候，無意中發現索引名字可以任取，可以選擇幾個欄位進來，這有什麼用呢？開始的select id from collect order by id limit 90000,10; 這么快就是因為走了索引，可是如果加了where 就不走索引了。抱著試試看的想法加了 search(vtype,id) 這樣的索引。然後測試
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再測試: select id ,title from collect where vtype=1 limit 90000,10; 非常遺憾，8-9秒，沒走search索引！
再測試：search(id,vtype)，還是select id 這個語句，也非常遺憾，0.5秒。
綜上：如果對於有where 條件，又想走索引用limit的，必須設計一個索引，將where 放第一位，limit用到的主鍵放第2位，而且只能select 主鍵！
完美解決了分頁問題了。可以快速返回id就有希望優化limit ， 按這樣的邏輯，百萬級的limit 應該在0.0x秒就可以分完。看來mysql 語句的優化和索引時非常重要的！
好了，回到原題，如何將上面的研究成功快速應用於開發呢？如果用復合查詢，我的輕量級框架就沒的用了。分頁字元串還得自己寫，那多麻煩？這里再看一個例子，思路就出來了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然對於in語句同樣有效！看來網上說in無法用索引是錯誤的！
有了這個結論，就可以很簡單的應用於輕量級框架了：
代碼如下：
$db=dblink();
$db->pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db->execute($sql);
$strpage=$db->strpage(); //將分頁字元串保存在臨時變數，方便輸出
while($rs=$db->fetch_array()){
　 $strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //構造出id字元串
$db->pagesize=0; //很關鍵，在不注銷類的情況下，將分頁清空，這樣只需要用一次資料庫連接，不需要再開；
$db->execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
< php while($rs=$db->fetch_array()): >
<tr>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['id']; $amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['url']; $amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['sTime']; $amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['gTime']; $amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['vtype']; $amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;<a act=show&id=< php echo $rs['id']; $amp;>quot;$ target="_blank"$amp;>amp;$lt; php echo $rs['title']; $amp;>amp;$lt;/a$amp;>amp;$lt;/td>
　 <td$amp;>amp;$amp;nbsp;< php echo $rs['tag']; $amp;>amp;$lt;/td>
</tr>
< php endwhile; >
</table>
< php
echo $strpage;
通過簡單的變換，其實思路很簡單：1）通過優化索引，找出id，並拼成 "123,90000,12000" 這樣的字元串。2）第2次查詢找出結果。
小小的索引+一點點的改動就使mysql 可以支持百萬甚至千萬級的高效分頁！
通過這里的例子，我反思了一點：對於大型系統，PHP千萬不能用框架，尤其是那種連sql語句都看不到的框架！因為開始對於我的輕量級框架都差點崩潰！只適合小型應用的快速開發，對於ERP,OA，大型網站，數據層包括邏輯層的東西都不能用框架。如果程序員失去了對sql語句的把控，那項目的風險將會成幾何級數增加！尤其是用mysql 的時候，mysql 一定需要專業的dba 才可以發揮他的最佳性能。一個索引所造成的性能差別可能是上千倍！
PS: 經過實際測試，到了100萬的數據，160萬數據，15G表，190M索引，就算走索引，limit都得0.49秒。所以分頁最好別讓別人看到10萬條以後的數據，要不然會很慢！就算用索引。經過這樣的優化，mysql到了百萬級分頁是個極限！但有這樣的成績已經很不錯，如果你是用sqlserver肯定卡死！而 160萬的數據用 id in (str) 很快，基本還是0秒。如果這樣，千萬級的數據，mysql應該也很容易應付。

9、php性能優化的幾個方法

面對一個性能問題是，第一步永遠是找到問題產生的原因，而不是去看技巧列表。搞明白產生瓶頸的原因，找到目標並且實施修復，然後再重新測試。查找瓶頸只是萬里長征的第一步，這里有些常用技巧，希望對最重要的第一步找到瓶頸能有所幫助。

使用監控方法（比如監控寶），進行benchmark和監控，網路，特別是網路狀況瞬息萬變，做得好的話5分鍾就可以找到瓶頸。

剖析代碼。必須了解那部分代碼耗時最多，在這些地方多多關注。

想找到瓶頸，請檢查每個資源請求（比如，網路、CPU、內存、共享內存、文件系統、進程管理、網路連接等等……）

先對迭代結構和復雜的代碼進行benchmark

在在真實負載下用真實數據進行真實測試，當然，如果可以最好用產品伺服器。

緩存
（Caching）

有些人認為緩存是解決性能問題最有效的辦法之一，試試這些：

使用OPCODE（操作碼）緩存，這樣腳本就不會在每次訪問時重新編譯一次。比如：啟用Windows平台上的windows緩存擴展。可以緩存opcode，文件，相對路徑，session數據和用戶數據。

考慮在多伺服器環境下使用分布式緩存

在調用imap_header()之前先調用imap_headers()

編譯
vs. 解釋（Compiling vs. Interpreting）

將PHP源碼編譯成機器碼。動態解釋執行同樣的編譯，但它是按行執行的。編譯為opcode是折中選擇，它可以將PHP源碼翻譯為opcode，之後opcode再轉為機器碼。以下為關於編譯與解釋的相關技巧：

上線之前將PHP代碼編譯為機器碼。opcode緩存盡管並不是最好的選擇，但依舊比解釋型來得強。或者，考慮將PHP代碼編譯成一個C擴展。

PHP的opcode編譯器（bcompiler)還不能在產品環境中使用

10、php循環處理大量數據，如何提高性能

優化循環 使用多線程處理