jQueryTips by Tee++; » performance

Hasing algorithm

Tee++; — Wed, 03 Jun 2009 16:09:12 +0000

วันนี้ขอพูดเรื่อง performance อีกสักที สำหรับคนที่เคยจับ application ที่ใหญ่ๆ หน่อย ที่มีจำนวน file upload มหาศาล หรือ เอาง่ายๆ แค่หลัก 2-3 หมื่นขึ้นไป ก็จะเห็นได้ว่า หลังจากนั้น application จะทำงาน ค่อยๆ ช้าลงๆๆๆ จนในที่สุด ก็ทะลุ node ที่เป็น limit ของ UNIX ไป (จำไม่ได้ 5 หรือ 6 หมื่นนี่ล่ะ)

วิธีแก้ที่ดีที่สุดก็คือการ ซอย folder ออกเป็น ย่อยๆ เพื่อไม่ให้ไฟล์ ไปรวมกันอยู่ที่เดียว เช่น

parent –
|- child1
|- child2

แบบนี้ไฟล์ก็จะไม่รวมอยู่ที่เดียวกัน แต่ จะมีปัญหาตามมาว่า แล้วเราจะ บริหารจัดการยังไง T_T

ตรงนี้แหละที่ ต้องมี hashing algorithm แบบต่างๆ ขึ้นมา ผมจะลอง ไล่ไปดูทีละแบบละกัน

แบบที่นึง hash ตัวเลข

function int_hash($no, $max=5000)
{
if (!is_numeric($no)) die(‘Value must be numeric’);
$p0 = ceil($no / ($max * $max));
$p1 = ceil($no % $max);
return $p0.‘/’.sprintf(‘%0′.strlen($max).‘d’, $p1);
}

แบบนี้จะเป็นการ hash 2 level ง่ายๆ แต่ว่า ได้ผลดีทีเดียว โดยที่ ชั้นแรกจะ hash ได้สูงสุดถึง 25 ล้าน ก่อนที่จะสร้าง folder ใหม่ นั่นก็คือ ค่าตั้งแต่

1 – 25000000 จะถูกเก็บเข้า Folder 1 ถ้ามากกว่า จะถูกสร้าง Folder 2 ขึ้นมา ส่วนในชั้นที่ 2 จะถูกสร้าง folder มาสูงสุดตามที่เรากำหนดค่า max ลงไป โดยในที่นี้ก็จะมี 0001 – 5000

จากนั้น data ที่ลงท้ายด้วย 1 ก็จะจัดเก็บเข้า folder 1 และ เป็นอย่างนี้เรื่อยไป

วิธีนี้เหมาะกับการ hash ค่าอะไรก็ตามที่เป็นตัวเลข เช่น auto increment หารทำงานจะค่อนข้างดีทีเดียว เพราะ data จะค่อยๆ หยอดไปทีละ 1 และมีขนาดพอๆ กันเกือบทุก folder แต่ว่า มัน hash ได้เฉพาะ ตัวเลข ลองมาดูวิธีต่อมากัน

แบบที่ 2 hash โดยใช้ crc32

function crc32_hash($key, $max=5000)
{
return (crc32($key) & 0×7fffffff) % $max;
}

วิธี hash แบบนี้สาารถนำไป hash string ได้ด้วย โดยอาศัย ความสามารถของ CRC32 ซึ่งเป็น algorithm hash ในรูปแบบ 32-bit checksum โดยค่าที่เหมือนกัน จะได้ค่าเดียวกันเสมอ จากนั้น เอามาเข้า สมการเพื่อให้ได้ folder ไม่เกินตามที่เรากำหนด เราก็จะได้ สูตรง่ายๆ มาแล้ว อันนี้เอาไว้ hash แบบชั้นเดียวง่ายๆ แต่ใครอยากไป เพิ่ม level ก็เขียนต่อเอาครับ

แล้วก็วิธีสุดท้ายที่ผมจะแนะนำ โดยอันนี้ผมแกะออกมาก จาก Zend Cache ในส่วนของการ hash level

โดยคราวนี้เราจะใช้ algorithm adler32

หลักการก็โครตจะแสนง่าย แต่ว่า ปะสิทธิภาพค่อนข้างจะดี

สมมุติผมมี string คำว่า ” I wanna be a star. ”

พอทำการ hash

hash(‘adler32′, ‘I wanna be a star.’);
// ค่าที่ได้คือ ef050538

จากนั้นผมก็มาคำนวน level โดยถ้า 1 level ผมก็จะทำการ ตัด string ที่ตำแหน่งแรกออกมาสร้าง dir ย่อย ก็จะได้ผลลัพธ์ ออกมาดังนี้

path: e/ef050538.hash

ถ้า 2 level ล่ะ

path: e/ef/ef050538.hash

และก็เป็นแบบนี้ไล่ๆ ไป ตามแต่ ที่เรากำหนด level

สำหรับวิธีนี้ node structure เราก็จะออกมาในรูปแบบ “สามเหลี่ยม” โดยยิ่งมี level มาก มันก็จะยิ่งซอยเยอะมาก แต่ว่า ถ้าเยอะมากไป มันก็เท่ากับว่า เราไม่ได้ hash อะไรเลย ดังนั้น สำหรับ application ระดับ กลาง – ใหญ่ ผมขอแนะนำที่ 2 level ก็พอครับ

สุดท้าย ผมเอา algorithm แบบที่ 3 มาเขียน ในรูปแบบ class เรียบร้อยแล้ว จะเอาไปใช้เลยก็ได้นะครับ โดยตัวอย่างที่ผมเอาไปใส่ไว้ ด้านล่างไฟล์ เป็นการทำ hash เพื่อ save text ธรรมดา ผมว่าเอาไป ประยุกต์ใช้งานกับระบบ cache หรือ file upload จะเห็นผลมากกว่า

/**
* Hashin library
* @Author Tee++;
* @Published 03/06/2009
*/
class Hashing {
var $parent_dir = ‘temp’;
var $prefix = "prefix_";
var $level = 2;
var $algorithm = ‘adler32′;
var $make_dir = TRUE;
// file tailer
var $show_file = TRUE;
var $extension = ‘hash’;
function do_hash($string)
{
$hashing = $this->hash_algorithm($string);
$path = $this->parent_dir;
if ($hash_dirs = $this->_path($hashing))
{
$path .= ‘/’.$hash_dirs;
if ($this->make_dir)
$this->_makePathRecursive($path);
}
if ($this->show_file)
{
$path .= ‘/’.$hashing.‘.’.$this->extension;
}
return $path;
}
function hash_algorithm($string)
{
return hash($this->algorithm, $string);
}
function _path($string)
{
if ($this->level <= 0)
{
return;
}
$directories = array();
for ($i=1; $i<=$this->level; $i++)
{
array_push($directories, $this->prefix.substr($string, 0, $i));
}
return implode(‘/’, $directories);
}
function _makePathRecursive($dir)
{
if (!is_dir($dir))
mkdir($dir, 0777, TRUE);
return TRUE;
}
}
/*
##### Example Usage #####
$string = "IWannaBeARockStar";
$hashing = new Hashing;
$path = $hashing->do_hash($string);
file_put_contents($path, $string);
*/
?>

MySQL::Merge Storage Engine

Tee++; — Wed, 27 May 2009 14:28:08 +0000

พักนี้เริ่มมั่วไปใหญ่ละ ตอนที่เปิดเว็บ มาตั้งใจว่าจะเขียนแต่เรื่อง jQuery กับ Javascript แต่พักนี้ไหง มีทุกเรื่องเลยก็ไม่รู้ กลายเป็น บล๊อกโปรแกรมมิ่ง ไปไม่รู้ตัว แต่ขออีกทีน่า คนมันอยากเขียนนี่หว่า เดี๋ยวครั้งหน้ากลับมา เขียนเรื่อง jQuery ต่อ

วันนี้ที่จะมาเขียนก็ฉีกแนวไปจากเดิมอีกละ จะมาพูดถึงเรื่อง Storage Engine ตัวนึงที่มี ใน MySQL 5.0 ขึ้นไป นั่นก็คือ merge storage engine (MRG_MyIsam) นั่นเอง เป็นการทำให้ table หลายๆ ตัว ถูก มองเห็นเป็นตัวเดียวกัน

ก่อนอื่นผมสร้าง DB ขึ้นมาทำการทดสอบชื่อว่า merge_test

จากนั้นผมสร้่าง table ขึ้นมา 2 ตัว ชื่อว่า table_a, table_b

CREATE TABLE `merge_test`.`table_a` (
`id` INT( 10 ) NOT NULL AUTO_INCREMENT ,
`data` VARCHAR( 25 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = MYISAM ;
CREATE TABLE `merge_test`.`table_b` (
`id` INT( 10 ) NOT NULL AUTO_INCREMENT ,
`data` VARCHAR( 25 ) NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = MYISAM ;

Engine ต้องเป็น MyIsam เท่านั้นนะครับ

จากนั้นผม ก็ทำการ ทดสอบ insert ข้อมูล ลงไปใน table_a ก่อน ดังนี้

INSERT INTO `merge_test`.`table_a` (`id`, `data`) VALUES (NULL, ‘data for table a’);

แล้วต่อมาอีก ผมก็สร้าง merage table มามีชื่อว่า table_all

CREATE TABLE `table_all` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`data` varchar(25) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MERGE UNION=(table_a,table_b) INSERT_METHOD=LAST

โดยต้องมี Structure เหมือนกับ 2 table ด้านบนไม่ผิดเพี้ยน จากนั้นกำำหนด Engine เป็น merge ซะ และใช้คำสั่ง Union ในการเลืกว่าจพ เชื่อม table ไหน จากนั้น กำหนด ให้ data insert อยู่ที่ last table นั่นก็คือ table_b นั่นเอง

จากนั้นมาลอง insert ข้อมูลลง table_all

INSERT INTO `merge_test`.`table_all` (`id`, `data`) VALUES (NULL, ‘555 test’);

จะเห็นได้ว่า table_all จะเอา data ของ ทั้ง 2 table มาอยู่ในตัวเอง ดังภาพด้านล่าง

table_a

table_b

table_all

จากภาพเราก็จะเห็นได้ว่า data ที่เรา insert table_all จะไป ตกอยู่ที่ table_b ด้วย โดยที่ auto increment ไม่ผิดเพี้ยนไป

ก็คือ table_all จะเป็นตัว map data เท่านั้น โดยที่ ไม่ได้ทำหน้าที่เป็นตัวจัดเก็บจริงๆ
*** ถ้ามี data เยอะๆ ไปลองสังเกตุไฟล์ table_all.frm ได้ว่า ไม่มีขนาดเพิ่มขึ้นตามจำนวน data ***

ทีนี้ เราก็จะสามารถบริหาร select, insert, delete, update โดยใช้ table_all เท่านั้น โดยไม่ต้องไปสนใจว่า data จะอยู่ที่ table_a หรือ table_b

วิธีนี้ไม่เหมือนกับการทำ Partition นะครับ เพราะว่า Data ไม่สามารถกำหนดในลักษณะั hasing ได้ ต้องเลือกเอาเลย ว่าจะ insert ลง table ไป “Last or First”

เท่าที่ลองหาข้อมูลมา วิธีนี้ไม่ได้ช่วยเรื่อง performance เท่าไหร่ แต่ว่า เป็นการ merge table เพื่อนำมาวิเคราะห์ข้อมูลมากกว่า แตกต่างจาก partition อย่าสับสนกันนะครับ

เอาล่ะ จบ เรื่อง MySQL เดี๋ยวครั้งแน่ jQuery แน่ๆ 555+

[CI Day 9] Query Caching Modify

Tee++; — Fri, 23 Jan 2009 08:36:05 +0000

สวัสดีมาต่อเรื่อง CI กันแล้วครับ ตอนนี้ผมตัดสินใจละ ว่าจะเขียนถึง Day 10 เท่านั้นแล้วก็จะกลับเข้ามาสู่ ภาคของ jQuery ต่อ เพราะว่าตั้งแต่ jQuery ออก V.1.3 ผมก็ไม่ได้อัพเดท อะไรเลย ทั้งๆ ที่มีของเล่นใหม่ๆ เพิ่มมาพอสมควร และที่สำคัญ ผมขี้เกียจเขียนเรื่อง CI ละ มันต้องอธิบาย กันลึกเกิน ไปซึ่งผม ก็เขียนอธิบาย ไม่ค่อยเก่งเสียด้วย แต่ถ้ามีอะไรก็ถามกันเข้ามาได้ครับ

เออ ช่วงนี้เห็นหลายคนขอ M ผมเข้ามาเยอะเหลือเกิน ยังไงผมก็จะให้ไว้ในกระทู้นี้ละกัน d n a b o a r d @ g m a i l . c o m ยังไงแวะเวียนมาแลกเปลี่ยนความรู้กันได้เลย

วันนี้เรื่องที่จะมาเล่า คือเรื่องการทำ Caching ของ CI ครับ แน่นอนครับ ทำเวบสมัยนี้ มันไม่เหมือนเมื่อก่อนแล้ว มันมีเทคนิคที่ พัฒนาไปมาก ในการทำเวบ เรื่องที่ผมใส่ใจมากเป็นพิเศษ นอกเหนือจาก Structure แล้วก็คือ Performance นี่ล่ะครับ และสิ่งที่ Developer ทำกันมากที่สุด ในการ Tuning Performance นั่นก็คือ การทำ Caching ครับ ผมยกตัวอย่างเช่น Facebook.com

รู้มั้ยครับ facebook เองเขียนด้วย PHP ส่วน DB ก็ยังใช้ MySQL นี่ล่ะ แต่ทำไม มันถึงรองรับ คนได้มากเหลือเกิน ซึ่งจะว่ากันไปจริงๆ แล้วมันมีหลายเรื่องทั้ง Load Balance, Reverse Proxy แล้วก็ องค์ประกอบของ Hardware แต่เรื่องที่ น่าสนใจคือ FB มีการ Access DB น้อยมาก ซึ่งเราเองรู้กันดีอยู่แล้วว่า MySQL เนี่ย มันไม่ค่อยจะดีนัก ต่อเวบที่มี คนเยอะๆ มันอ่อนแอเหลือเกิน

ดังนั้นแทนที่ FB จะทำการ Access เข้า DB ตรงๆ อยู่ตลอดเวลา ก็เปลี่ยนมาออกแบบให้ Access ป่าน Memcached ซึ่งเป็นการ Cached ใน Fast Memory (**Data จะหายเมื่อมีการ Reboot**) ด้วยวิธีนี้จะทำให้การ Access DB ลดน้อยลง จนเราแปลกใจ และเป็นสาเหตุหลักที่ทำให้เวบมี Down Time ต่ำมากๆ

อ้างอิง: Facebook Scalability

แต่ด้วยข้อจำกัดของ Server ที่เพื่อนๆ ใช้มันทำให้การที่ผมจะไปพูดถึง Cached ระดับ Memory เช่น APC, Memcached นั้น ดูจะแคบไปหน่อย ผมก็เลยขอเลี่ยงไปพูดถึง Cache ในระดับ Flat File แทน ซึ่งน่าจะทำกันได้ในทุกๆ Server อยู่แล้ว

(ผมไม่ขอพูดถึง Caching ทีมีใน CI นะครับ เพราะว่าผมไม่ปลื้มเท่าไหร่ ถ้าสนใจก็อ่านใน manual น่าจะเข้าใจได้ไม่ยาก)

เอาล่ะไม่รู้จะเกริ่นยาวไปถึงไหน มาเริ่มกันเลยดีกว่าครับ….

ในการออกแบบ Structure ของวันนี้เราจะพูดถึงเรื่องหลักๆ 2 เรื่องคือ
1. การออกแบบ Folder Structure (Node)
2. การออกแบบ Cache แบบ GZIP

เรื่องแรกก่อน (วันนี้สงสัยไม่จบง่ายๆ -*-)

เพื่อนๆ รู้มั้ยครับ การจัดเก็บไฟล์ลงใน Dir แต่ละ Dir นั้นก็มีข้อจำกัดเหมือนกัน ไม่ใช่เอะอะๆ ยัดเก็บ Dir เดียว พรวดๆ ถ้าทำแบบนั้นมันจะเกิดปัญหาในท้ายที่สุดคือ Node เต็ม ซึ่งตามที่เคยรู้มามันควรจะเป็นราวๆ 60,000 ต่อ 1 ชั้นราวๆ นี้มั้ง (จริงๆ ยัดลงไปได้อีกเยอะ แต่มันจะช้าลงเรื่อยๆ จนตายไปในที่สุด)

ตัวอย่างการจัดเก็บที่ดีก็คือ Flickr ลองไปสังเกตุ Path ของรูปดูสิครับ จะเห็นได้ว่า มีการแบ่งเป็น Farm และ Sup Path ไว้อย่างดีเลยทีเดียว

ทีนี้ผมจะมาลอง algorithm ง่ายๆก่อน โดยจะใช้แค่ Dir ขวางเพียงชั้นเดียว โดยทำ Hashing ด้วย CRC32

function crc32_hash($key, $max=5000)
{
return (crc32($key) & 0×7fffffff) % $max;
}

เขียนเท่านี้ล่ะ ผมไม่ขออธิบายถึง CRC32 Algorithm นะครับ แต่ว่าเพื่อนๆ ไปหาข้อมูลเพิ่มได้จากพี่ Goo นั่นล่ะ ผมจะขอบอกแค่ว่าจาก Function ด้านบนสิ่งที่เพื่อนๆจะได้กลับมาก็คือ ข้อมูล 1 ชุดที่เป็นตัวเลข ไม่เกิน 5,000 โดยเราเอาอะไรใส่เข้าไปก็ได้ เช่น

echo crc32_hash(‘Tee++;’);
// output 322

ตัวเลขที่ออกมานั่นล่ะครับ คือส่งที่ผมจะเอาไปสร้าง node
/main_dir/322/

เห็นมั้ยครับเท่านี้ผมก็จะได้ Dir มาขวาง 1 ชั้นแล้ว ไม่จำเป็นต้องเอาไปเก็บที่ main_dir อย่างเดียว โดยที่ Folder ในชั้นที่ขวางนี้จะมีไม่เกิน 5,000 เพราะผมตั้งเอาไว้แค่นั้น

นอกจากนี้ Algorithm ของการทำ Hashing Dir ยังมีอีกมากมายครับ ลองหาเอาจากใน Net ดูกันเอา ส่วนตอนี้ผมจะเข้าเรื่องที่ผมจะเขียนก่อนล่ะ

เรื่องที่สอง

มาเขียน lib caching เพื่อไป plug ใน CI กัน
[CI]/application/libraries/Caching.php

if ( ! defined(‘BASEPATH’)) exit(‘No direct script access allowed’);
class Caching {
var $CI;
var $_parent = ‘cache/’;
var $_maxDir = 5000;
var $_path;
function __construct()
{
$this->CI =& get_instance();
$this->CI->load->helper(‘node’);
}
function setParent($parent)
{
if (substr($parent, -1) != "/")
$parent = $parent.‘/’;
$this->_parent = $parent;
}
function setMaxDir($max)
{
$this->_maxDir = $max;
}
function setDir($subDir, $str=null)
{
if (is_null($str) || empty($str)) return;
$hash = ’server_’.crc32_hash($str, $this->_maxDir).‘/’;
$this->_path = APPPATH.$this->_parent.$subDir.‘/’.$hash;
}
#### end if use key as string #####
function store($key, $data, $ttl=86400)
{
if (!$key || !$data) return;
mkdirs(dirname($this->getFileName($key)));
$h = @gzopen($this->getFileName($key), ‘w’);
if (!$h) return;
$data = serialize(array(time() + $ttl, $data));
if (gzwrite($h, $data) === false) return;
gzclose($h);
}
function fetch($key)
{
if (!$key) return;
$filename = $this->getFileName($key);
if (!file_exists($filename) || !is_writeable($filename)) return false;
$h = @gzopen($filename, ‘r’);
if (!$h) return;
while (!gzeof($h))
$data .= gzread($h, 4096);
gzclose($h);
$data = unserialize($data);
if (!$data || time() > $data[0])
{
$this->delete($key);
return false;
}
return $data[1];
}
function delete($key)
{
if (!$key) return;
$filename = $this->getFileName($key);
if (file_exists($filename))
return unlink($filename);
else
return false;
}
function getFileName($key)
{
return $this->_path.md5($key).‘.gz’;
}
}
?>

เอาล่ะ ผมจะมาอธิบายว่าในแต่ละ method ทำหน้าที่อะไรกันบ้าง
1. construct
ใช้สำหรับเรียกค่าต่างๆ ของ CI เข้ามาใช้กันและทำการ load helper node มาใช้ พอดีไอ้ function ชุดแรกผมไปเขียนใน helper ที่ชื่อว่า node น่ะครับ

2. setParnet
เป็นตัวกำหนด Dir หลักที่จะ ทำการใส่ data cache ลงไป

3. setMaxDir
เป็นตัวกำหนดว่าจะ hash dir ย่อยทั้งหมดภายใต้ main dir กี่ folder

4. setDir
เป็นตัว hash dir ย่อยภายใต้ main dir อีกที โดยจะรับค่า string เข้ามาทำการ hash

5. strore
เป็นตัวเก็บข้อมูลเพื่อทำการ Caching โดยจะระบุ key, data, expiration โดยจะ write file เป็น .gz เพื่อบีบขนาดให้เล็กที่สุด ข้อมูลภายในจะถูกเก็บเป็น array โดย

index:0 จะเก็บ current time + expire time
index:1 data ในรูปแบบ data ที่เข้ามาปกติ โดย data จะอยู่ในรูปแบบใดก็ได้ เช่น string, array, object

จากนั้นจะทำการ Write ข้อมูลแบบ PHP Serialize เพื่อแปลง Array เป็น String ชุดเดียว

6. fetch
เป็นตัวดึงข้อมูลกลับออกมาจาก cache โดยระบุ key ค้นหาเข้าไป การดึงข้อมูลกลับ จะทำการเช็คที่ index:0 ก่อนคือ Expiration ถ้าหมดอายุก็จะทำการ delete cache ทิ้งและ return false กลับมา (miss cached) ถ้าไม่ใช่ก็จะคืน data ที่ cached เข้าไปกลับมา

7. delete
เป็นตัว ลบข้อมูลของ cached ตาม key index

8. getFileName
อันนี้จะถูกใช้แค่ระหว่าง method เป็นการ hash ชื่อไฟล์ที่จะ cache ด้วย md5 โดยจะ return กลับไปพร้อมๆ กับ path

เอาล่ะๆ จบแล้วสำหรับขั้นตอนการเขียน ตอนนี้มาดูขั้นตอนการใช้งานจริงๆ กันเลยดีกว่า ส่วนมาก caching นี้ผมจะเอามา cache Query ที่อยู่ใน model เสียเป็นส่วนใหญ่คือ ไม่ให้ดึง data จาก DB ตลอดเวลา แต่ให้ดึงเอาจาก cache ในกรณีที่ data ไม่มีการเปลี่ยนแปลง

สมมุติ ผมมี model::User_model->getUserData($user_id) เพื่อที่จะดึงข้อมูลของสมาชิก แทนที่ผมจะ Query db ตรงๆ ผมก็จะเขียนแบบนี้แทน

//สมมุติว่า load library caching ที่เขียนไว้มาแล้ว
$this->caching->setDir(‘user_dir’, $user_id)
/*****พอผ่านบรรทัดนี้แล้ว ผมก็จะได้ path ที่จะจัดเก็บหรือ ดึง data เรียบร้อยแล้ว****
อาจจะเป็น cache/user_dir/xxxx/ โดยที่ xxx คือการ hash ค่าของ $user_id ผ่าน algo CRC32 นั่นเอง*/
if (!$row = $this->caching->fetch($user_id))
{
$sql = "SELECT ……….";
$row = "ตรงนี้เป็นการเขียน mysql query ตามปกติ";
$this->caching->store($user_id, $row, 3600);
}
/* อันนี้เป็นการ fetch data ก่อนครับ โดยมีเงื่อนไขว่าถ้า data ใน cache ไม่มีแล้ว ให้ไป ทำการ query มาใหม่ แล้วค่อย เก็บ data ลง cache และระบุให้หมดอายุ ภายในอีก 3600 วินาทีข้างหน้า (1 ชั่วโมง) ดังนั้นในการ fetch ครั้งหน้่า เราก็จะได้ data จาก cache แล้ว */

เป็นอันจบครับสำหรับ lib:caching ที่เขียนเองขึ้นมา ส่วนการจัดการ cache ผมจะ ไกด์คร่าวๆ ว่ามันควรจะเป็นยังไงนะครับ มันมีผังการเดินทางของมันอยู่ ตัวอย่างเช่น

1. ถ้า fetch ข้อมูล จาก key เจอ จะ ใช้ data จาก cache
2. ถ้า fetch ข้อมูล จาก key ไม่เจอ ก็จะใช้ data สดๆ แต่ก็ทำ การ store cache ไปพร้อมๆกัน

3. ถ้ามีการ update data ก็จะทำการลบ cache ตาม key เพื่อให้ข้อมูลมีความสดใหม่ และวนกลับไปยังข้อ 2

สรุป method ใน model ที่ควรจะมีความเกี่ยวเนื่องกับระบบ cache มันก็ควรจะมีพวกเรื่อง

getData, updateData

อืมม์ เรื่องการ manage cache ให้ได้ข้อมูลสดอยู่ตลอดไม่ใช่เรื่องง่ายครับ แต่ผมคิดว่ามันคงไม่ยากเกินไปหรอกครับ และที่สำคัญ ถ้าเพื่อนๆ ทำความเข้าใจกับ lib:caching ที่ผมเขียนขึ้นมาตัวนี้ได้แล้ว จะเอา method ไปแก้ไขเป็น memcached หรือ apc อะไรก็ไม่ลำบากแล้วล่ะครับ

วันนี้เนื้อหาค่อนข้างหนักพอสมควร ผมเองก็ปวดหัวละ ขอพอก่อนละกัน สวัสดีครับ

บทความว่าด้วยการ optimize code ด้วยการทำ caching

Tee++; — Mon, 07 Apr 2008 15:40:09 +0000

ตัวผมเองนั้นมีประสบการณ์ไม่ดีกับปัญหา MySQL จนเกือบจะเลิกใช้มันไปแล้วครั้งนึง จนหาทาง optimize code แบบต่างๆออกมาซึ่งได้ผลดีบ้างน้อยบ้างตามแต่จะว่ากัน ดังนี้

1. query database I/O ธรรมดา
:ผลลัพธ์ คนเข้าเยอะ โฮสเดี้ยง เวบล่ม โดนด่า

2. ทำ index ให้กับ db
:ผลลัพธ์ สามารถใช้ได้แค่เป็นส่วนประกอบของการทำ optimize code เท่านั้น แต่ถือว่า “จำเป็น” เลยทีเดียว

3. ทำการ cache output ออกมาเป็น static (html)
:ผลลัพธ์ ดีทีเดียว แต่มีปัญหาเรื่องความสดของข้อมูล manage เรื่อง fresh content ยาก

4. ทำการเปลี่ยนเป็น flat db (text, xml, etc.)
:ผลลัพธ์ ใช้ได้เลย แต่มีปัญหาเรื่องการเขียนข้อมูลพร้อมกันทีละหลายคน lock ไม่ทัน ไฟล์ตาย ข้อมูล write มาไม่ครบ backup ลำบาก

จนมาถึงวิธีที่ผมใช้มาจนปัจจุบัน เหมาะมากๆกับการที่มีคนเข้าจำนวนหลัก หมื่น จนถึง หลักแสน

ซึ่งวิธีที่ดีที่สุดในตอนนี้คงหนีไม่พ้นการทำ cache ใส่ memory โดยตรงพวก โดยใช้ extensions พวก apc, memcache

ซึ่งการทำแบบนี้ให้ผลลัพธ์ที่ดีในระดับ “พระเจ้า” เวบจะเร็วขึ้นอย่างทันตาเห็น เพราะ cache จะถูกทำใน fast memory ซึ่งมีความเร็วเป็นทุนเดิมอยู่แล้ว และเมื่อขอ้มูลเต็มจะมีการ clear เอาของที่เก่าออกเอง

แต่ทว่า….

ข้อเสียคือต้องลงทุนไปตั้ง Server เองเพราะไม่มี share hosting ที่ไหนให้เรามา แชร์ ram มันหรอกจริงมั้ยครับ T_T

ฉะนั้นเราก็จะมาทำกันง่ายๆก่อนด้วยการทำ cache ในระดับ file

ซึ่งง่ายที่สุดประหยัดค่าใช้จ่ายที่สุด ที่สำคัญลงมือทำได้เลย

************************************
รูปแบบของcache จะแบ่งออกเป็น hit กับ miss ซึ่ง hit หมายถึง user เรียกข้อมูลใช้จาก cache ได้ทันทีซึ่งเป็น “ตัวดี” ส่วน miss คือ user ไม่สามารถเรียกใช้ cache ได้ในกรณีต่างๆ ซึ่งเป็น “ตัวไม่ดี”

ถ้าเราใช้ cache แบบ memory เราสามารถจะวัดผลได้เลยว่ามี hit กี่ % แต่ถ้าเป็น file ก็คงต้องให้ admin มา monitor กันละครับ เอาเป็นว่า ลืมไปก่อนละกัน อิอิ

แต่ว่าการเริ่ม cache ทุกครั้งจะต้องเริ่มจาก miss ก่อนเสมอ คือ

1. user เข้ามาครั้งแรกเรียกข้อมูลจาก cache ไม่เจอ
2. ดึงข้อมูลโดยตรงจาก db (miss)
3. ทำการสร้าง cache จากข้อมูลที่ user ดึง
4. user เข้ามาครั้งที่ 2 เรียกข้อมูลจาก cache เจอ เรียกใช้ได้ทันที (hit)

ทีเหลือต้องไป manage ความสดใหม่ของ cache เอาเอง เช่น

1. user ทำการอัพเดท profile ลบ cache ทิ้งรอให้ user สร้าง cache ด้วยตัวเอง ซึ่งแน่นอนจะเกิด miss อีก 1 ที

หรือจะทำงานหนักขึ้น (coding)

2. user ทำการอัพเดท profile แล้วเราอัพเดท cache ทันที ไม่รอให้เกิดการ miss

************************************
ลองมาดูตัวอย่างการทำ cache จากผลลัพธ์ การ query อย่างง่ายๆ กันก่อน

$cache = "cache/";
$key = "your_key";
if (!$data = file_get_contents($cache.$key)) {
$sql = "SELECT …….";
//…… query step …… (ละไว้ในฐานที่เข้าใจ)
$data = $results;
file_put_contents($cache.$key, $data); // php5 only!
}
print_r($data); // ทดสอบข้อมูล
?>

ตามโคดข้างบนจะเป็นการเรียกcache ถ้าไม่มีก็ให้ทำการสร้าง cache ซึ่งโคดตัวนี้ผมแค่เขียนเป็นแนวทางเพื่อให้เห็นภาพ แต่ว่ามันใช้ไม่ได้จริงๆ แหะๆ เพราะจุดอ่อนมากมายเช่นไม่มีการตั้ง cache expire ไม่มีการ lock ข้อมูลระหว่างเขียนไม่สามารลบ cache ออกได้เอง

ซึ่งตามปกติคนที่จะใช้ cache ในลักษณะนี้มักจะเขียน class ขึ้นมา 1 ตัวเพื่อทำหน้าที่ในส่วน

1. การ store ค่าลง cache พร้อมระบุเวลาหมดอายุ รวทั้ง key
2. การ fetch ค่าที่ยังไม่หมดอายุ จาก cache โดยใช้ key อ้างอิง
3. การ ลบค่า ออกจาก cache โดยการระบุ key
4. การ clear cache ทั้งหมด

ซึ่งลองดูตัวอย่างได้จากlink ด้านล่าง เอา class ไปใช้ได้เลยหรือจะปรับปรุงให้ดีขึ้นตามสไตล์ก็แล้วแต่ ในที่นี้ผมเห็นมี class ที่ทำงานกับ 3 แบบเลยคือ file,apc, memcache ลองดูแล้วกันครับ

http://www.rooftopsolutions.nl/article/107

************************************
ข้อพึงระวังในการทำ File Cache ก็คือพยายามอย่าเก็บไฟล์ cache ไว้ที่ folder เดียว เพราะมันจะมีปัญหาเรื่องการ seek ข้อมูลอีก -*-

โดยอาจจะใช้อัลกอลิทึ่มสักตัวมาคำนวนว่า cache นี้ควรจะเก็บไว้ที่โฟลเดอร์ไหน ตัวอย่าง

$cache = "cache/'; $key = "mykey"; $sub = (strlen($key)%9);

$cache.=$sub."/"; // ควรจะได้ค่าเป็น cache/5/

ซึ่งแบบนี้เท่ากับว่าเราจะมี cache/ เป็น directory ที่เก็บหลัก ข้างในยังแบ่งย่อยได้อีก 9 เพราะ mod 9

หรือจะใช้วิธีตัดตัวอักษรตัวแรก แล้วทำเป็นโฟลเดอร์ย่อย คือ 1-9 a-z รอไว้เลยก็ได้

แต่ถ้าวันไหนเกิดcache เต็มก็ลบออกไปหมด แล้วให้มัน built ใหม่ยังดีกว่าให้มัน fetch ค่าจาก db ที่เผลอๆ บางที join กัน 5-10 ตาราง ตรงๆ แน่นอน