Joe Horn 的啟示錄

我利用前兩天的空閒時間寫了個 PHP 的小程式，運用 PHP 的 PDO 元件，對 MySQL 進行小測試。

Server 作業系統與硬體：

• 作業系統：FreeBSD 8.0-RELEASE
• CPU：Intel(R) Pentium(R) 4 CPU 3.00GHz (3042.62-MHz 686-class CPU)，Hyper-Threading 開啟
• RAM：2G DDR2 800
• 放資料庫的 HDD：WDC WD800JB-00JJA0，UDMA 100

MySQL 5.1.44 的設定（/etc/my.cnf）：

# defult setting (maybe changed)
key_buffer_size = 128M
max_allowed_packet = 4M
table_open_cache = 4096
sort_buffer_size = 1M
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

# added for tunning by Joe Horn
skip-name-resolve
connect_timeout = 60
join_buffer_size = 1M
max_connect_errors = 10000
max_connections = 100
max_heap_table_size = 1G
query_cache_size = 16M
slave_net_timeout = 30
sync_binlog=1
thread_cache_size = 512
thread_concurrency = 8
tmp_table_size = 1G
table_definition_cache = 512
# choose one ( depend on query amount )
#concurrent_insert=2
low_priority_updates=1

這台機器跑 Super Smack 的結果：

# super-smack -d mysql update-select.smack 80 1000
Query Barrel Report for client smacker
connect: max=14ms  min=1ms avg= 4ms from 80 clients
Query_type      num_queries  max_time  min_time  q_per_s
select_index    80000        101       6         717.91
update_index    80000        108       1         717.91

我用測試程式產生了一百萬筆資料的 MyISAM table，各種測試各循環 1000 次，產生如下的測試結果（後面的數字單位是秒）：

SELECT BY PK_COL WITH_QUERY_CACHE:              0.058
SELECT BY PK_COL WITHOUT_QUERY_CACHE:           0.062
SELECT BY PK_COL LIMIT WITH_QUERY_CACHE:        0.058
SELECT BY PK_COL LIMIT WITHOUT_QUERY_CACHE:     0.062
SELECT BY UNIQUE_COL WITH_QUERY_CACHE:          0.058
SELECT BY UNIQUE_COL WITHOUT_QUERY_CACHE:       0.062
SELECT BY UNIQUE_COL LIMIT WITH_QUERY_CACHE:    0.058
SELECT BY UNIQUE_COL LIMIT WITHOUT_QUERY_CACHE: 0.062
SELECT BY INDEX_COL WITH_QUERY_CACHE:           0.058
SELECT BY INDEX_COL WITHOUT_QUERY_CACHE:        0.061
SELECT BY INDEX_COL LIMIT WITH_QUERY_CACHE:     0.058
SELECT BY INDEX_COL LIMIT WITHOUT_QUERY_CACHE:  0.063
SELECT BY COL WITH_QUERY_CACHE:                 0.786
SELECT BY COL WITHOUT_QUERY_CACHE:              0.063
SELECT BY COL LIMIT WITH_QUERY_CACHE:           0.059
SELECT BY COL LIMIT WITHOUT_QUERY_CACHE:        0.062
UPDATE BY PK_COL WITH_QUERY_CACHE:              1.139
UPDATE BY PK_COL WITHOUT_QUERY_CACHE:           1.199
UPDATE BY PK_COL LIMIT WITH_QUERY_CACHE:        0.125
UPDATE BY PK_COL LIMIT WITHOUT_QUERY_CACHE:     0.142
UPDATE BY UNIQUE_COL WITH_QUERY_CACHE:          2.734
UPDATE BY UNIQUE_COL WITHOUT_QUERY_CACHE:       1.203
UPDATE BY UNIQUE_COL LIMIT WITH_QUERY_CACHE:    0.147
UPDATE BY UNIQUE_COL LIMIT WITHOUT_QUERY_CACHE: 0.163
UPDATE BY INDEX_COL WITH_QUERY_CACHE:           1.183
UPDATE BY INDEX_COL WITHOUT_QUERY_CACHE:        1.063
UPDATE BY INDEX_COL LIMIT WITH_QUERY_CACHE:     0.138
UPDATE BY INDEX_COL LIMIT WITHOUT_QUERY_CACHE:  0.154
UPDATE BY COL WITH_QUERY_CACHE:                 4704.859
UPDATE BY COL WITHOUT_QUERY_CACHE:              4641.191
UPDATE BY COL LIMIT WITH_QUERY_CACHE:           0.156
UPDATE BY COL LIMIT WITHOUT_QUERY_CACHE:        0.167

根據測試結果，大概可以看到出以下幾個要點：

1. 根據第 21 行與 22 行的差異看來，MySQL Query cache 還是有點用處，不過效用不大。
2. 根據第 13 行與第 29 行的結果看來，有沒有設定 Primary Key、UNIQUE、INDEX 的影響不小。
3. 根據 UPDATE 語法的測試結果看來，有沒有 LIMIT 頗重要。

Technorati Tags: FreeBSD, INDEX, LIMIT, MySQL, PDO, PHP, Primary Key, Query Cache, Super Smack, UNIQUE

我們在開發 PHP 專案時，時常會把一些常用變數放在某個 PHP 檔案，接著用 require()、require_once()、incluce()、include_once() 等函式將之引入。
若系統目錄很複雜，就會在很多檔案裡面看到類似這樣的語法：

require_once('../../Config.php');

然而，當這種系統必須變動目錄結構與檔案所在目錄時，開發人員就得額外多花些時間來更改上述之程式碼。

其實，PHP 的設定檔中，有個很少被注意到的變數，就是 auto_prepend_file 。

假設目前有個 PHP 專案，專案根目錄之系統絕對路徑為 /var/www/html/Project，
共用設定檔為 /var/www/html/Project/Config.php 。
我們可以在 /var/www/html/Project 下建立 .htaccess 檔案，內容如下：

php_value auto_prepend_file "/var/www/html/Project/Config.php"

而 /var/www/html/Project 目錄下所有的檔案，以及所有子目錄中的檔案都會自行引入 /var/www/html/Project/Config.php 。

PS. 由於 auto_prepend_file 的設定是透過 require() 來實作，使用這種方法要特別注意以下兩點：

1. 一旦設定了 auto_prepend_file ，該檔案就必須要存在，否則就會有 error ，導致該目錄下的所有 PHP 檔案無法正常執行。
2. include_path 會影響 auto_prepend_file。

Technorati Tags: auto_prepend_file, htaccess, include, include_once, PHP, php_value, require, require_once

以下是在 PTT 的 PHP 板看到某篇文章後的心得，以及小小的經驗分享。

對 Smarty 稍有經驗的人，應該都知道樣板內可使用 {include} 這個 tag 來嵌入其他 template file。
然而，因為 Smarty 內的變數都是全域變數，所以我對這個 tag 的看法是「能不用，就不用」。

用常見的網站論壇系統舉個簡單的例子：

• A 設計師負責開發顯示 HTML header 的 template，使用了 $title 變數作為 page title，ex：

  <html><head><title>$title</title></head>

• B 設計師負責開發顯示論壇文章內容的 template，恰巧也使用了 $title 作為文章標題。

若 B 設計師在其 template file 中使用了 {include} 來嵌入 A 設計師的 template file，就可能會產生預期之外的顯示結果。

當然，若是開發團隊已事先溝通好各項變數的命名，就不會有這種情況。
但為了減少此類風險，降低 debug 的難度，我們會選擇使用這種方式：

• 在系統全域共用的函式檔案中增加負責顯示 HTML header 的 function，例如 function page_header($title) { ...} ，並在 function 中 assign 變數，引入 A 設計師開發的 template file。
• 在論壇文章內容顯示的程式檔中，呼叫 page_header($title)，再 assign 文章標題的變數，引入 B 設計師開發的 template file。

當然，若嵌入的 template file 內沒有任何變數，就不須考量以上的狀況，開發/設計人員可以大膽地隨意使用。

Technorati Tags: include, PHP, Smarty

昨晚，有個學長透過 MSN 問我有無簡單好用的 PHP 圖形驗證碼，又讓我想到 reCAPTCHA。
上一次使用時，reCAPTCHA 僅提供顏色變更；如今，reCAPTCHA 已經開始支援多國語言了。

剛才稍微玩了一下，寫了這個簡單的網頁。
reCAPTCHA 的多國語言化相關資訊可以參考 這裡，而我使用的中文化程式碼片段為：

<script type="text/javascript">
	var RecaptchaOptions = {
		custom_translations : {
			visual_challenge : "取得圖形驗證碼",
			audio_challenge : "取得音效驗證碼",
			refresh_btn : "重新整理圖形",
			instructions_visual : "輸入兩個英文單字:",
			instructions_audio : "輸入您聽到的聲音:",
			help_btn : "獲得協助",
			play_again : "重新播放音效",
			cant_hear_this : "將音效下載為 MP3",
			incorrect_try_again : "錯誤！ 請再試一次"
		}
	};
</script>

Technorati Tags: CAPTCHA, il8n, localization, PHP, reCAPTCHA

這幾天接了一個 PHP 的系統要作，為了防止 Spambot，必須加入視覺驗證碼。

在眾多視覺驗證碼的 solution 中，我第一個想到的就是 reCAPTCHA 。

不過，根據以前用過的經驗，reCAPTCHA 還沒有多國語言支援的能力。

我看了一下他們給的 PHP library 跟 使用說明頁 。
很遺憾... 目前還是沒有支援多國語言。
在 reCAPTCHA 的 Forum 則是找到 這個討論串 。

雖然會擔心收到抱怨，不過依照目前的情況看來，只能先硬著頭皮上，然後靜待佳音了。
回覆 那個討論串 的文章催促一下，進度會不會比較快呀？

Technorati Tags: PHP, reCAPTCHA, translation

之前我在 這篇文章 說過某台機器還在使用 PHP 4.4.0 的原因.

當天 gaod 大長輩 聽到我的哭訴後, 很好心的找了台機器測 CPG 1.4.6 .
運作是正常的.

可是這台機器上面的 phpBB 規模不算小, 所以我也就先擱著.

幾天前跟小竹子問過他們的 PHP 版本, 也是停在 4.4.0 .
所以也還沒動.

直到今天凌晨, 我把 PHP 升上 4.4.2 ( 本來先想燒香的, 可是我這邊沒有... ) .
目前看來運作也都正常.

晚點通知小竹子好了.

Technorati Tags: Coppermine, PHP, phpBB

自從 上次的 PHP 地雷事件 後, 目前手上兩三台有裝 CPG 跟 phpBB 的機器一直停在 PHP 4.4.0 .

可是現在要用 ports 升級 phpMyAdmin 卻會失敗, 還噴這串出來 :

This port requires the Apache Module or the CGI version of PHP, but you have already installed a PHP port without them.
*** Error code 1

跑到 /usr/ports/lang/php4 底下用 make config 把 Apache module 加進去, 還是會噴上面這串...

目前 ports 裡面, PHP4 最新的版本是 4.4.2 , PHP5 是 5.1.4 , phpBB 的版本是 2.0.20 , CPG 是 1.4.6 .
麻煩有裝以上這些系統的好心的前輩提燈籠來指個路啊.

Technorati Tags: Coppermine, FreeBSD, PHP, phpBB

我只能說, 這個版本是顆大地雷.
除非系統是自己開發, 而且程式碼都寫得很漂亮, 不然用 4.4.0 還是比較好.

之前幫某台機器升級, 結果上面的 phpBB 就爛了... orz
Error message 長這個樣子:

PHP Fatal error: Cannot redeclare get_userdata() in xxx.php on line xxx

後來是靠 portdowngrade ( 在 /usr/ports/sysutils/portdowngrade ) 把版本換回 4.4.0 , 指令上大致上是這樣 :

cd /usr/ports/sysutils/portdowngrade
make install clean
rehash
portdowngrade -o -s \\
:pserver:anoncvs@anoncvs.at.FreeBSD.org:/home/ncvs lang/php4

然後會出現一些問題給你選, 弄好以後用 portupgrade -f 把已安裝的這兩種開頭的軟體全部洗一遍就好:

1. php4-*
2. pecl-*

Technorati Tags: FreeBSD, PHP, portdowngrade

繼昨天在 這篇 提到的問題之後.

我發現 phpBB 也有相同的問題, 而且還不只一個檔案爛掉...
( 是爛一團.... )

去官方的論壇找, 也是哀鴻遍野... orz
而官方的回答一律都是 "請改用 PHP 4" .

因為爛掉的檔案太多, 牽連範圍太大...
所以我把部分機器的 PHP 都降回來 4.4.0 了.......

看來 phpBB 要在 PHP5 上面跑的話, 可能得等 3 系列囉!?

Technorati Tags: PHP

剛剛 Solaris 叔叔 跟我說他的 Blog 消失了.

找了一下問題之後發現這串 log :

[Sun Sep 11 19:40:49 2005] [error] [client 59.104.45.15] PHP Fatal error: Only variables can be passed by reference in ###/wp-includes/gettext.php on line 66

我針對這段作了小修改 , 原先的這段 code :

return array_shift(unpack("V", $this->STREAM->read(4)));

改成這樣就恢復正常了 :

$read_int_tmp = unpack("V", $this->STREAM->read(4));
return array_shift($read_int_tmp);

因為昨天晚上我把 PHP 從 5.0.4 升級到 5.0.5 , 所以這應該是 5.0.5 才會遇到的問題吧!?

更詭異的是, 我這邊跟 R 董那邊 都沒發生這個問題.
( 所以應該說是 Solaris 叔叔 帶賽? )

Technorati Tags: PHP, WordPress