php的phpize做了什麼,phpize報錯

本文目錄一覽:

xhprof安裝 phpize是什麼命令

一、前言有用的東西還是記錄下來吧,也方便以後的查詢;這次記錄一下xhprof的安裝使用;xhprof是facebook開源出來的一個php輕量級的性能分析工具,跟Xdebug類似,但性能開銷更低,還可以用在生產環境中,也可以由程序開 關來控制是否進行profile。二、安裝wget pecl/get/xhprof-0.9.3.tgz tar zxf xhprof-0.9.3.tgz cd xhprof-0.9.3/extension /usr/bin/phpize (php版本安裝後生成的phpize文件,可根據phpinfo查看,所以php版本不同,生成的phpize也不同,此步驟主要生成configure文件) ./configure –with-php-config=/usr/bin/php-config (php-config的路徑,也是php安裝後生成的文件) make sudo make install (會自動將生成的擴展文件拷貝到擴展目錄中/usr/lib64/php/modules)當然具體的php文件的目錄,每個人不盡相同,可根據phpinfo查詢三、php.ini配置根據phpinfo找到 extension_dir的目錄(/etc/php.d/xhprof.ini)添加一下內容:extension=xhprof.so xhprof.output_dir=/tmp/xhprof //xhprof的分析日誌 四、重啟服務sudo /etc/init.d/http restart 查看phpinfo是否安裝成功五、使用方法開頭: xhprof_enable(); //開啟監測 //xhprof_enable(XHPROF_FLAGS_NO_BUILTINS); 不記錄內置的函數 //xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); 同時分析CPU和Mem的開銷 //要測試的代碼 … … … 結尾: $xhprof_data = xhprof_disable(); //停止監測,返回運行數據 $xhprof_root = ‘/(xhprof的虛擬主機目錄)/’; //引入當初安裝到xhprof虛擬主機目錄中的文件 include_once $xhprof_root.”xhprof_lib/utils/xhprof_lib.php”; include_once $xhprof_root.”xhprof_lib/utils/xhprof_runs.php”; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs-save_run($xhprof_data, “xhprof”); echo ‘a href=”(xhprof的虛擬主機域名)/xhprof_html/index.php?run=’.$run_id.’source=xhprof” target=”_blank”xhprof統計/a’; 上邊的代碼使用了,給xhprof設置虛擬主機的方法。把源碼包中的 xhprof_html 和 xhprof_lib 文件夾拷貝到自己建立的虛擬目錄中cp -r xhprof_html xhprof_lib /xxx/xhprof/ (此處目的是建立數據分析目錄,可將此目錄配置成虛擬主機訪問)運行後,統計點擊返回的 xhprof統計 鏈接,即可。六、注意問題以及名詞解釋在顯示的統計頁面中,點[View Full Callgraph]圖形化顯示(最大的性能問題會用紅色標出,其次是黃色);點擊後,可能提示錯誤消息,執行以下命令即可yum install -y graphviz yum install graphviz-gd 名詞解釋Function Name 函數名 Calls 調用次數 Calls% 調用百分比 Incl. Wall Time (microsec) 調用的包括子函數所有花費時間 以微秒算(一百萬分之一秒) IWall% 調用的包括子函數所有花費時間的百分比 Excl. Wall Time (microsec) 函數執行本身花費的時間,不包括子樹執行時間,以微秒算(一百萬分之一秒) EWall% 函數執行本身花費的時間的百分比,不包括子樹執行時間 Incl. CPU(microsecs) 調用的包括子函數所有花費的cpu時間。減Incl. Wall Time即為等待cpu的時間 減Excl. Wall Time即為等待cpu的時間 ICpu% Incl. CPU(microsecs)的百分比 Excl. CPU(microsec) 函數執行本身花費的cpu時間,不包括子樹執行時間,以微秒算(一百萬分之一秒)。 ECPU% Excl. CPU(microsec)的百分比 Incl.MemUse(bytes) 包括子函數執行使用的內存。 IMemUse% Incl.MemUse(bytes)的百分比 Excl.MemUse(bytes) 函數執行本身內存,以字節算 EMemUse% Excl.MemUse(bytes)的百分比 Incl.PeakMemUse(bytes) Incl.MemUse的峰值 IPeakMemUse% Incl.PeakMemUse(bytes) 的峰值百分比 Excl.PeakMemUse(bytes) Excl.MemUse的峰值 EPeakMemUse% EMemUse% 峰值百分比 xhprof的安裝與簡易用法xhprof是Facebook開源的輕量級PHP性能分析工具,Linux環境下可以通過pecl直接安裝,比如在Ubuntu下僅需3行指令pecl install xhprof-beta echo “extension=xhprof.so” /etc/php5/fpm/conf.d/xhprof.ini service php5-fpm restart 之後可以通過phpinfo()檢查擴展是否已經加載。具體如何使用呢,xhprof項目中已經提供了示例以及簡易的UI,下載xhprof項目到web服務器,假設可以通過localhost/xhprof/訪問,那麼訪問localhost/xhprof/examples/sample.php可以看到一些輸出,並且提示通過訪問xhprof-ui-address/index.php?run=XXXsource=xhprof_foo查看結果。接下來訪問localhost/xhprof/xhprof_html/就可以看到已經保存的結果,列出了所有函數的調用以及所消耗的時間。分析一下示例代碼sample.php,關鍵部分只有2行://開啟xhprof並開始記錄 xhprof_enable(); //運行一些函數 foo(); //停止記錄並取到結果 $xhprof_data = xhprof_disable(); $xhprof_data中記錄了程序單步運行過程中所有的函數調用時間及CPU內存消耗等,具體記錄哪些指標可以通過xhprof_enable的入口參數控制,之後的處理已經與xhprof擴展無關,大致是編寫了一個存儲類XHProfRuns_Default,將$xhprof_data序列化並保存到某個目錄,可以通過XHProfRuns_Default(__DIR__)將結果輸出到當前目錄,如果不指定則會讀取php.ini配置文件中的xhprof.output_dir,仍然沒有指定則會輸出到/tmp。xhprof_html/index.php將記錄的結果整理並可視化,默認的UI里列出了:•funciton name : 函數名•calls: 調用次數•Incl. Wall Time (microsec): 函數運行時間(包括子函數)•IWall%:函數運行時間(包括子函數)佔比•Excl. Wall Time(microsec):函數運行時間(不包括子函數)•EWall%:函數運行時間(不包括子函數)每一項應該不難理解,以項目自帶的sample.php為例,示例中編寫了一個main()函數,main()函數中調用foo()、bar()等一些子函數進行了一點字符處理。整個程序運行過程中,main()函數只運行了一次,並且由於main()函數中包括了所有的邏輯,所以main()函數的IWall%佔比為100%,但是由於main()函數的功能都是由子函數實現的,因此main()函數的EWall%只有0.3%,而foo()函數完成了主要的工作,EWall%有98.1%。因此在分析更大型的程序時,往往需要根據這幾項指標分別排序,從不同的角度審視性能消耗。在xhprof_html/index.php中還可以看到[View Full Callgraph]鏈接,點擊後可以繪製出一張可視化的性能分析圖,如果點擊後報錯的話,可能是缺少依賴graphviz,ubuntu可以通過apt安裝apt-get install graphviz更好的注入方式了解了上面這些,其實就已經可以將xhprof整合到任何我們已有的項目中去了。目前大部分MVC框架都有唯一的入口文件,只需要在入口文件的開始處注入xhprof的邏輯//開啟xhprof xhprof_enable(XHPROF_FLAGS_MEMORY XHPROF_FLAGS_CPU); //在程序結束後收集數據 register_shutdown_function(function() { $xhprof_data = xhprof_disable(); //讓數據收集程序在後台運行 if (function_exists(‘fastcgi_finish_request’)) { fastcgi_finish_request(); } //保存xhprof數據 … }); 但是這樣免不了要修改項目的源代碼,其實php本身就提供了更好的注入方式,比如將上述邏輯保存為/opt/inject.php,然後修改php fpm配置文件vi /etc/php5/fpm/php.ini 修改auto_prepend_file配置auto_prepend_file = /opt/inject.php 這樣所有的php-fpm請求的php文件前都會自動注入/opt/inject.php文件如果使用Nginx的話,還可以通過Nginx的配置文件設置,這樣侵入性更小,並且可以實現基於站點的注入。fastcgi_param PHP_VALUE “auto_prepend_file=/opt/inject.php”;

php中的phpize是什麼作用的文件

進入php源程序目錄中的ext目錄中,這裡存放着各個擴展模塊的源代碼,選擇你需要的模塊,比如curl模塊:cd curl

執行phpize生成編譯文件,phpize在PHP安裝目錄的bin目錄下

/usr/local/php5/bin/phpize

運行時,可能會報錯:Cannot find autoconf. Please check your autoconf installation and

the $PHP_AUTOCONF

environment variable is set correctly and then rerun this

script.,需要安裝autoconf:

yum install autoconf(RedHat或者CentOS)、apt-get install

autoconf(Ubuntu Linux)

/usr/local/php5/bin/php -v

執行這個命令時,php會去檢查配置文件是否正確,如果有配置錯誤,

這裡會報錯,可以根據錯誤信息去排查!

PHP7.0怎麼通過打開擴展功能和mysql相連?

第一步:進入php源碼中的”ext/mysql”目錄下

第二步:在當前目錄下運行phpize命令:/usr/local/php524/bin/phpize

phpize的規則:去哪個目錄下運行phpize文件,那麼就會在該目錄下生成一個configure文件。

第三步:運行剛才生成的configure文件

命令: ./configure –with-php-config=/usr/local/php524/bin/php-config –with-mysql=/usr/local/mysql/

這裡最關鍵的是通過–with-mysql參數告訴mysql客戶端的位置。這樣才能生成mysql.so。

實驗的時候,沒有加這個參數,結果錯誤:

./configure –with-php-config=/usr/local/php524/bin/php-config

第四步:編譯生成.so文件

第五步:配置php引擎加載該擴展。

補充一下:就是去php.ini文件中修改一下配置,加載mysql.so這個擴展(這個擴展文件要放到php指定的擴展目錄下面去)

第六步:測試php引擎是否成功加載該擴展編寫文件phpinfo.php,內容是:?php ehco phpinfo(); ?

運行後,可以看到有如下信息顯示:mysqlMySQLSupport    enabledActive PersistentLinks     0

Active Links     0

Client API version     5.1.55

MYSQL_MODULE_TYPE     no value

MYSQL_SOCKET     /tmp/mysql.sock

MYSQL_INCLUDE     no value

MYSQL_LIBS     no value

通過這樣的方式可以確認,php引擎已經成功加載了mysql.so擴展。

第七步:已經生成的mysql.so。編寫php代碼測試是否能連接mysql。

一、為什麼書中一般是常常是這樣的順序安裝。

先安裝mysql,然後再安裝php,很少看到先安裝php,後安裝mysql?

這樣做。是基於下面原因:安裝好mysql後。mysql.so這個模塊才能生成。記得一個細節:在安裝php的時候,需要提供mysql的路徑。由php幫助編譯生成mysql.so模塊。mysql.so這個模塊是在安裝好php的時候生成的。

生成這個模塊需要用到一個東西:mysql客戶端。如果先安裝php,後安裝mysql。那麼無法按照原來的方式(由php幫助生成mysql.so模塊)掛接mysql.so。通過實踐,發現使用phpize工具生成mysql.so可以解決這個問題。

二、實踐生成mysql.so的過程。

大體思路:需要用到php的源碼包才行。通過源碼包中提供的phpize文件(一個專門掛接php擴展的工具)

使用 phpize 和 首次安裝編譯時有什麼區別嗎

phpize 主要負責生成擴展的配置文件和Makefile,首次編譯php,zend extenion擴展會生成動態庫文件.so,比如opcache 在編譯php時就會生成opcache.so,前提在configure 的時候加入–enable-opcache

我的php目錄下沒有phpize 沒有bin目錄

phpize是php用來編譯安裝擴展庫用的,windows的安裝包所有的擴展庫都差不多安裝好了

所以,沒有,你要是linux系統安裝的php就會喲的

如何利用phpize在生產環境中為php添加新的擴展php-bcmath

當服務器上PHP已經安裝好,需要額外添加PHP擴展時怎麼辦?不需要重新安裝PHP,有了phpize我們可以在原有的PHP基礎之上直接安裝擴展庫。 這次編譯僅僅只是單獨編譯PHP的擴展庫,接下來將編譯好的擴展庫加入到現在運行的php中,不對現在運行的php…

原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/190679.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
小藍的頭像小藍
上一篇 2024-11-30 09:06
下一篇 2024-11-30 09:06

相關推薦

  • java client.getacsresponse 編譯報錯解決方法

    java client.getacsresponse 編譯報錯是Java編程過程中常見的錯誤,常見的原因是代碼的語法錯誤、類庫依賴問題和編譯環境的配置問題。下面將從多個方面進行分析…

    編程 2025-04-29
  • PHP和Python哪個好找工作?

    PHP和Python都是非常流行的編程語言,它們被廣泛應用於不同領域的開發中。但是,在考慮擇業方向的時候,很多人都會有一個問題:PHP和Python哪個好找工作?這篇文章將從多個方…

    編程 2025-04-29
  • PHP怎麼接幣

    想要在自己的網站或應用中接受比特幣等加密貨幣的支付,就需要對該加密貨幣擁有一定的了解,並使用對應的API進行開發。本文將從多個方面詳細闡述如何使用PHP接受加密貨幣的支付。 一、環…

    編程 2025-04-29
  • Python運行不報錯又無任何結果輸出可能產生的原因以及解決方法

    在Python編程過程中,有時候會出現程序運行不報錯但卻沒有任何結果輸出的情況。本文將從多個方面解析這個問題,並提供相應的解決方法。 一、語法錯誤 語法錯誤是Python程序中最常…

    編程 2025-04-29
  • Java 監控接口返回信息報錯信息怎麼處理

    本文將從多個方面對 Java 監控接口返回信息報錯信息的處理方法進行詳細的闡述,其中包括如何捕獲異常、如何使用日誌輸出錯誤信息、以及如何通過異常處理機制解決報錯問題等等。以下是詳細…

    編程 2025-04-29
  • Python切片索引越界是否會報錯

    解答:當對一個字符串、列表、元組進行切片時,如果索引越界會返回空序列,不會報錯。 一、切片索引的概念 切片是指對序列進行操作,從其中一段截取一個新序列。序列可以是字符串、列表、元組…

    編程 2025-04-29
  • 如何解決Grid監控報錯prvg-1205

    Grid監控是Oracle RAC的重要組件,它可以幫助監視RAC集群的運行狀態和性能,對於集群管理非常關鍵。但是,如果在安裝過程中遇到報錯prvg-1205,將會導致安裝失敗,影…

    編程 2025-04-28
  • 使用PHP foreach遍歷有相同屬性的值

    本篇文章將介紹如何使用PHP foreach遍歷具有相同屬性的值,並給出相應的代碼示例。 一、基礎概念 在講解如何使用PHP foreach遍歷有相同屬性的值之前,我們需要先了解幾…

    編程 2025-04-28
  • PHP獲取301跳轉後的地址

    本文將為大家介紹如何使用PHP獲取301跳轉後的地址。301重定向是什麼呢?當我們訪問一個網頁A,但是它已經被遷移到了另一個地址B,此時若服務器端做了301重定向,那麼你的瀏覽器在…

    編程 2025-04-27
  • 如何解決Docker+k8s報錯413 Request Entity Too Large

    對於使用Docker容器和Kubernetes集群的開發人員,在處理HTTP請求時,常常會遇到413 Request Entity Too Large的報錯。這通常是由於請求的大小…

    編程 2025-04-27

發表回復

登錄後才能評論