由於我這的機器是跑在我 XP 上的 vm ，所以記憶體很有限…
想辦法讓 Apache,MySQL 不要把我記憶體吃完…
分類: Web
php configure fast cgi
php 與 apache 最常協同工作的方式是採用在 apache 上掛載 mod_php 模組，在執行 apache 的時候呼叫這個模組來編譯 php 網頁。所以接收工作與回應的模式大都是 apache 在控制(這邊指的是行程的數量…與生命週期等等)，預設情況 apache 會有一個 process pool 接到要求就從 pool 中叫一個起來工作，如果工作超過 pool 的 process 量的話則 fork 新 process 來處理，則會佔用大量的記憶體，尤其是 apache 是採用 process 不是 thread 的關係(一個 30M 200個 request 就需要 6G)。
common gateway interface 是一個讓網頁伺服器與程式銜接的介面，叫做 interface 就是代表各種語言只要實做了這個介面就能跟網頁伺服器溝通。而 fast cgi 則是 cgi 的擴展擁有許多更良好的特性，可以是一個不中斷程式持續的接收工作，而 apache 接到工作以後不是採用 php 模組的方式呼叫編譯，而是將要求轉送至已在運行的 fcgi 程式中。
透過 fast cgi 的方式運作與 spawn cgi 來管控數個設定如: php_cgi 行程的數量。透過管理 php_cgi 行程池，減低 apache 載入 php 模組所耗費的記憶體，應能加速 apache fork 行程的速度，因為少載入了一個肥大的 mod_php module。這樣的話假設實際環境使用者要求個網頁有 1個php 9個資源的情況，10個要求只有1個需要呼叫 php_cgi ，這樣 10 個 php_cgi 可以處理 100 個 apache process。
Web 框架雜記
codeIgniter 將 控制器與模型 物件都定位在函式 的集合，比較接近靜態類別的函式集如 Math.abs ..Math.pie 。
django 則沒說明 控制器與模型 需要用物件來設計，給使用者自行抉擇的空間，都採用 module 內包含數 func 來實做， 但支援的 orm 可以讓存取資料表等同於物件的操作。
如果沒特別設計，依照兩個框架最原始的介紹與建議的基礎開發，兩者在控制器的差異不大，但 django 較沒有去解釋物件的用法，大都是用在各種工具元件的情況 如 Form , Session，因為原先物件導向的設計就比較偏向元件的重用，而不是函式的集合，所以 django 較符合原始意義。
那 codeIgniter 這樣設計有什麼好處呢？
將 PHP 按照順序執行的流程，整理成物件的生命週期，雖然異於物件導向原始的意義，但流程控制較容易掌控，在程式規模擴增時，也讓尋找程式碼實際檔案變的更加容易，且也提供 library 的方式來讓使用者擺放擴增的 classes。
但其 library 對於各式的 classes 的引入，不夠 friendly ，對檔案與類別名字有所限制。
整體來說，物件雖重用性不高，但對於限制程式擴增的模式來說，有良好的效果，如能搭配 modules 的概念，系統也能成長到一定的規模。
對於 php 還沒有支援命名空間的版本來說，當用 函式 來組織，很容易會有名稱的衝突，如果要退一步，就要用各種累贅的命名慣例，而透過多一層類別封裝函式，解決了這種情況，但遇到控制器與模型名稱衝突時，可能還是需要靠命名空間來解決，抑或是這種設計容易造成不具意義的物件(函式集)，所以命名才會成為煩惱吧。
django 的彈性
….
reverse proxy
reverse proxy ，proxy 伺服器，可以將外部連線導入到內部網路的 web 伺服器，搭配 nat 可以隱藏內部網站，如果 load blancer 效果～
只是效能可能會卡在入口站的 網路 或 效能~
apache
<VirtualHost *:80>
ServerName apple.tw
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://192.168.8.10/
ProxyPassReverse / http://192.168.8.10/
</VirtualHost>
nginx
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_max_temp_file_size 0;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
server {
listen 80;
server_name apple.tw;
location / {
proxy_pass http://192.168.8.10/;
}
}
用 ab 實際測試 apache 跟 nginx 的差異 ，在我的環境下都超慢的，感覺是虛擬機的設定有問題，
只是在近端網路測就比較正常了，且在 -c Number of multiple requests to make 越高的情況下， nginx 的表現竟然反而比較好，在低的情況下就都差不多。
好像是 catch 設定的問題..每次測都有點不一樣。
jpgraph 2.2 中文支援
很久以前的一篇文章…庫存一下…
官方網站 http://www.aditus.nu/jpgraph/
使用2.2版 官方連結 http://hem.bredband.net/jpgraph2/jpgraph-2.2.tar.gz
src/jpgraph.php 內
6256行左右有 $txt = $this->langconv->Convert($txt,$this->font_family);
似乎是將簡體中文轉成 utf-8 而我網站內使用的是 utf-8 而且我用的是繁體中文，所以註解掉這行。
63行部份有定義字型的位置，我網站內使用的是Linux 而我又不是伺服器管理者動不到原先字型的目錄，所以將字型之置換於 jpgraph 安裝目錄下所以改成這樣。
if (!defined('TTF_DIR')) {
if (strstr( PHP_OS, 'WIN') ) {
$sroot = getenv('SystemRoot');
if( empty($sroot) ) {
$t = new ErrMsgText();
$msg = $t->Get(12,$file,$lineno);
die($msg);
}
else {
DEFINE('TTF_DIR', $sroot.'/fonts/'); //windows下的位置
}
} else {
DEFINE('TTF_DIR','/home/mlwmlw/www/jpgraph/'); //unix下的位置
}
}
JPG-CONFIG.INC
此檔控制一部分字型的選擇，內有此行定義繁體中文字型的字體
//JPG-CONFIG.INC
DEFINE('CHINESE_TTF_FONT','simhei.ttf');
可使用 FF_CHINESE aka FF_BIG5 不過這似乎此檔不是關鍵定義字型的部份，在網路上找到的文件選中文程式中設定都是 FF_SIMSUN,FS_BOLE
接著看 jpgraph_ttf.inc.php 注意此文件內的設定字體陣列，發現了 jpGraph 定義字型的關鍵程式，
我們要改的部份240行
//jpgraph_ttf.inc.php /* Chinese fonts */ FF_SIMSUN => array(FS_NORMAL =>'simsun.ttc', FS_BOLD =>'simhei.ttf', FS_ITALIC =>'', FS_BOLDITALIC =>'' ), FF_CHINESE => array(FS_NORMAL =>CHINESE_TTF_FONT, FS_BOLD =>'DFFN_M9.TTC', FS_ITALIC =>'', FS_BOLDITALIC =>'' ),
字型規則
FF_*** 選擇主要類別,FS 選擇字型，每個FF定義了每個字型的對應屬性，我將 CHINESE 內的 NORMAL 與 BOLD 放置了兩個我需要的字體，
之後程式在 SET_FONT 時就看要那個字體就應對著選擇 FF_CHINESE,[FS_NOMAL OR FS_BOLD]。
這樣在跑應該就能有中文了。