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。

Continue reading…

jQuery 隱藏元件取得寬高

actual plugin

http://dreamerslab.com/blog/en/get-hidden-elements-width-and-height-with-jquery/

stack-overflow 的討論

http://stackoverflow.com/questions/2345784/jquery-get-height-of-hidden-element-in-jquery-1-4-2

jQuery 有 height , width , outerWidth , outerHeight 這些函式可以取得元件的面積資訊,

但是有時候有些元件是被隱藏(hidden)的,還是需要取得他的面積,所以上面兩篇文章都是在處理這方面的問題,

大都是修改元件隱藏的方式,來讓元件雖然是看不到的(假隱藏)但是還是可以取得寬高,

但是我自己的情況是…不是該元件被隱藏,而是他的老爸被隱藏,所以這些方法把他的隱藏方式修改…其實還是看不到…

所以想到另外一個概念,就是把他 clone 出來 body 好了,這樣應該不會看不到了,把資訊取完再砍掉吧…

如果該元素有其他 class 的 css 設定下可能會有不太準…只是至少我暫時解決了…


/**
 * @license jQuery Hawk 0.1
 *
 * Copyright 2011 mlwmlw
 * licensed under the MIT.
 */

(function($) {
	var supported = ['height', 'width', 'outerHeight', 'outerWidth', 'innerHeight', 'innerWidth'];
	var check = {};
	for(var i in supported) {
		check[supported[i]] = true;
	}

	var ref = {};

	var $target = $('body');
	$.fn.hawk = function(type) {
		if(typeof(check[supported[i]]) == 'undefined') {
			throw 'unsupported method';
		}
		var $clone = $(this).clone();
		$clone.css({'position':'absolute', 'visibility':'hidden', 'display':'block'}).appendTo($target);
		var result = null;

		if(typeof(ref[type]) != 'undefined') {
			result = ref[type].apply($clone,[]);
		}
		else {
			result = $clone[type]();
		}
		//alert($(this).attr('class') + ': '+ type + ': '+ result);
		$clone.remove();
		return result;
	}

	$.hawk = function(cmd, options) {

		if(cmd == 'install') {
			for(var i in supported) {
				ref[supported[i]] = $.fn[supported[i]];
				$.fn[supported[i]] = (function(type) {
					return (function() {
						return $(this).hawk(type);
					})
				})(supported[i]);
			}
		}
		else if(cmd == 'restore') {
			for(var i in supported) {
				$.fn[supported[i]] = ref[supported[i]];
			}
			ref = {};
		}
	}
})(jQuery);

api 是參考 actual 的設計…

$('xxx:hidden').hawk('width');
$('xxx:hidden').hawk('height');
$('xxx:hidden').hawk('innerWidth');
$('xxx:hidden').hawk('outerWidth');

只是因為我遇到得問題是其他的 plugin 在取的時候出錯,
也不太可能去把他的 source code 都改成這個 API 吧…太麻煩,之後更新也會有問題,
所以就額外寫了安裝這個 plugin 的函式:
$.hawk(‘install’)
這樣就會把上述那些取寬高資訊的函式預設成 jQuery 內建的,
例如 $(‘xx’).height 就會被換成 $(‘xx’).hawk(‘height’);
只是安裝了以後一直這樣取值效能會很差,這些函式會一直 clone dom,
所以安裝了以後,但是用完了就能用這函式移除這層關聯:
$.hawk(‘restore’); 這樣就沒事了…

資料庫擴展

MySQL Cluster 、HBase、Cassandra

該怎麼知道自己的應用適合什麼軟體,自行架設的環境是否有達到想像的能力呢?

那就自行架設測試環境來對這些細節做測試吧!

測試什麼?

硬碟 io、連線承受數、每秒讀取寫入數量。

sysstat:

系統狀況讀取軟體,內有附 iostat 可以測硬碟瞬間讀寫的速度。

MySQL:

http://mysqldatabaseadministration.blogspot.com/2006/08/mysql-benchmarking-1.html

使用 MySQL 5.1 之後內建的 mysqlslap 來模擬大量用戶連線。

./bin/mysqlslap –host=antslab.tw –user=user -p -a –auto-generate-sql-guid-primary –auto-generate-sql-load-type=mix –auto-generate-sql-unique-query-number=5 –auto-generate-sql-unique-write-number=6 –auto-generate-sql-secondary-indexes=4 –concurrency=100 –create-schema=test –auto-generate-sql-execute-number=10011

參數解釋 http://jingstory.com/tag/mysqlslap

 

Web 框架雜記

codeIgniter 將 控制器與模型 物件都定位在函式 的集合,比較接近靜態類別的函式集如 Math.abs ..Math.pie 。

django 則沒說明 控制器與模型 需要用物件來設計,給使用者自行抉擇的空間,都採用 module 內包含數 func 來實做, 但支援的 orm 可以讓存取資料表等同於物件的操作。

如果沒特別設計,依照兩個框架最原始的介紹與建議的基礎開發,兩者在控制器的差異不大,但 django 較沒有去解釋物件的用法,大都是用在各種工具元件的情況 如 Form , Session,因為原先物件導向的設計就比較偏向元件的重用,而不是函式的集合,所以 django 較符合原始意義。

那 codeIgniter 這樣設計有什麼好處呢?

將 PHP 按照順序執行的流程,整理成物件的生命週期,雖然異於物件導向原始的意義,但流程控制較容易掌控,在程式規模擴增時,也讓尋找程式碼實際檔案變的更加容易,且也提供 library 的方式來讓使用者擺放擴增的 classes。

但其 library 對於各式的 classes 的引入,不夠 friendly ,對檔案與類別名字有所限制。

整體來說,物件雖重用性不高,但對於限制程式擴增的模式來說,有良好的效果,如能搭配 modules 的概念,系統也能成長到一定的規模。

對於 php 還沒有支援命名空間的版本來說,當用 函式 來組織,很容易會有名稱的衝突,如果要退一步,就要用各種累贅的命名慣例,而透過多一層類別封裝函式,解決了這種情況,但遇到控制器與模型名稱衝突時,可能還是需要靠命名空間來解決,抑或是這種設計容易造成不具意義的物件(函式集),所以命名才會成為煩惱吧。

django 的彈性

….