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循環處理大量數據,如何提高性能
優化循環 使用多線程處理