1. mkdir /var/lib/mysql2/ ขึ้นมา หรืออาจ copy จาก db ปัจจุบันก็ได้ (ถ้าจะ copy ต้องปิด mysql ก่อน copy) หรือถ้าจะรันจาก backup ตรงๆ อย่างผมก็ไม่ต้องทำอะไร
2. chown -R mysql:mysql /path/to/ข้อ 1
3. copy my.cnf ที่ใช้รัน ตั้งชื่อใหม่เป็น my2.cnf (หรือถ้า debian ก็ทั้ง /etc/mysql เป็น /etc/mysql2)
4. edit my2.cnf ที่ copy มาดังนี้
   - port – แก้ 3306 เป็น 3307 (หรืออื่นๆ ที่ไม่ได้ใช้งาน)
   - datadir – path ที่เราสร้างในข้อ 1
   - socket – เปลี่ยนชื่อ mysql.sock เป็น mysql2.sock
   - innodb_data_home_dir - path ที่เราสร้างในข้อ 1
   -  innodb_log_group_home_dir – path ที่เราสร้างในข้อ 1
   -  innodb_buffer_pool_size – อันนี้จริงๆ ไม่ต้องแก้ก็ได้ แต่ถ้าเครื่อง ram น้อย แล้วไฟล์ my.cnf ต้นฉบับตั้งค่าไว้เยอะก็ลดลงไปหน่อยไม่ให้ล้น ram ที่มี
5. mysql_install_db –user=mysql –datadir=/path/to/ข้อ 1
6. mysqld_safe –defaults-file=/path/to/my2.cnf &
7. mysql -S /path/to/mysql2.sock -uroot -p
   เพื่อทดสอบการเชื่อมต่อ ถ้า login ได้แสดงว่าทำสำเร็จ แล้วใน config phpmyadmin (config.inc.php) ก็อาจไปเพิ่มบรรทัดนี้
   $cfg['Servers'][$i]['port'] = ’3307′;
   ก็จะเข้าไปดูข้อมูลหรือ export ข้อมูลแบบใช้ GUI ได้ตามสะดวกโยธิน
8. mysqladmin -S /path/to/mysqld2.sock shutdown เพื่อปิด instance เวลาเลิกใช้งาน

เปิด mysql ได้สอง Instance แล้วเรียบร้อย จะ copy ข้อมูลข้ามกันไปมายังไงก็ได้แล้ว ง่ายแค่นี้เอง

จุดเด่นของ NoSQL ส่วนใหญ่ (แต่ไม่ใช่ทุกอย่าง) คือความสามารถในการ write ข้อมูลได้เร็วกว่า MySQL เป็นอย่างมาก หากงานที่เราทำนั้นเน้นการ write ข้อมูลมากๆ เช่นต้องเก็บ Log แบบตลอดเวลาแบบ Real-time ทุกการกระทำ และข้อมูลมีขนาดใหญ่โตมาก การใช้งาน MongoDB ก็จะตอบโจทย์ได้เป็นอย่างดี

MongoDB เป็น database แบบ Document-Oriented โดยลักษณะข้อมูลที่ทำการเก็บจะคล้ายกับ JSON เป็นอย่างมาก มีข้อดีอย่างมากคือ Row แต่ละ Row ไม่จำเป็นต้องมีโครงสร้างข้อมูลเหมือนกัน เช่น คุณอาจจะมีข้อมูลปากกา 1 row ที่ระบุแค่สีแดง และอีก row เป็นข้อมูลปากกาที่ระบุว่าสีน้ำเงิน และอีก field ระบุว่าเป็นปากกาชนิดมีด้ามเสียบ ซึ่งมีข้อมูลมากกว่า 1 อย่าง ก็สามารถเก็บได้โดยไม่ต้องเปลี่ยน schema หากใครใช้ MySQL ทำงานกับข้อมูลมากๆ จะรู้ว่าการสั่ง ALTER TABLE เพื่อเปลี่ยนโครงสร้างตารางข้อมูลนั้นช้าเพียงใด (table โดน lock อีกตะหาก) และถ้า requrement จำเป็นต้องเพิ่ม field เข้าไปเรื่อยๆ แล้วละก็เรื่องใหญ่ทีเดียว

บางคนอาจเคยได้ยินว่า MongoDB จะกิน Memory ของเครื่องไปเรื่อยๆ จนกระทั่งหมด เรื่องนี้ไม่เป็นความจริง เพราะ Memory ใน MongoDB ที่มีการใช้งานนั้นจะมีการใช้งานเยอะขึ้นเรื่อยๆ จริง ถ้าดูจาก top แต่ถ้าดูจาก free -m จะทราบว่าจริงๆ Memory ที่ยังใช้งานได้ยังเหลืออีกเยอะ หากมี Process อื่นเกิดต้องการใช้ memory จำนวนมาก ตัว MongoDB จะ Memory ที่ใช้ให้โดยอัตโนมัติ เป็นเพราะ MongoDB ใช้ระบบเดียวกับ cached memory ใน linux ซึ่งจะปล่อยให้ OS เป็นคนจัดการ Memory ให้เลยหลอกตาเหมือนว่าจะกิน Memory เยอะ คล้ายกับเราเปิด top ขึ้นมาครั้งแรกแล้วเห็น free เหลืออยู่นิดเดียว แต่ memory ส่วน cached จะยังมีเหลืออยู่อีกมาก สำหรับรายละเอียดอ่านเหตุผลได้ที่เว็บนี้

ผมขอสรุปข้อดี-ข้อเสียของ MongoDB เป็นข้อๆ ดีกว่าครับ

ข้อดี

1. write to disk เร็วส์มากกกกก
2. ถ้าเน้นเอามา write อย่างเดียว ไม่มีการ read (เช่นเก็บ Log ไว้ให้ admin ดู) จะกินแรมน้อยมากกกกก CPU ก็กินน้อยสุดๆ เทียบกับ InnoDB ของ MySQL แล้วต่างกันราวฟ้ากับเหว
3. write แบบ asynchronous (คล้าย INSERT DELAYED ของ MyISAM ใน MySQL)  คือไม่ต้องรอ Insert เสร็จจริงก็ทำงานต่อได้
4. read อย่างเดียวก็เร็วกว่า MySQL มากเช่นกัน (ภายใต้ข้อจำกัดว่าข้อมูลของฐานข้อมูลที่เรียกใช้บ่อยๆ ต้องใส่ใน memory ที่เหลือได้พอดี)
5. มี Capped Collection ซึ่งจะทยอยลบข้อมูลเก่าที่เก็บไว้นานเกินไปแล้วเอาข้อมูลใหม่มาใส่แทนได้ เหมาะแก่การนำมาทำ Log มากเพราะจะ clear ข้อมูลที่เก็บมานานเกินไปไว้ให้อัตโนมัติ ข้อมูลไม่โตกว่าที่เรากำหนด ไม่ต้องมาสั่ง cron ให้คอยลบข้อมุล log ทุกๆ กี่วัน
6. Scaling เพิ่มเครื่องได้ง่ายกว่า MySQL มากๆๆๆๆ

ข้อเสีย

1. ถ้า project เก่าคุณมีการ JOIN กันซับซ้อนละก็ จะเปลี่ยนมาใช้ได้ยากมากทีเดียว
2. การใช้งานผ่านเว็บไม่ง่ายเท่า phpmyadmin เช่นการ query เรื่องวันที่ผ่านเว็บจะลำบากพอสมควร ต้องเขียนหน้า admin ใช้งานเอง และการค้นหาข้อมูลทั่วๆ ไปก็ยากเช่นกัน
3. กินพื้นที่การเก็บข้อมูลมากกว่า MySQL พอสมควร เหตุผลเพราะไม่มี schema ดังนั้น schema จริงๆ มันจะแอบอยู่ในทุก row ของฐานข้อมูล ทำให้ข้อมูลใหญ่กว่า MySQL
4. หากใช้งานจน disk เต็ม จะ clear พื้นที่ disk ให้ใช้งานต่อยาก เพราะการสั่ง delete row ไม่ทำให้ฐานข้อมูลเล็กลง!! ต้องสั่ง compact เองซึ่งต้องมีที่ว่างที่ disk อีกลูกมากพอๆ กับพื้นที่ข้อมุลที่ใช้อยู่ปัจจุบันเป็น buffer ในการลดขนาด (การลดขนาดจริงๆ คือการสร้างใหม่มาเลยอีกก้อน จึงต้องมี buffer เยอะมาก)
5. หากต้องการใช้งานเป็นฐานข้อมูลหลักแทน MySQL ควรมีเครื่องอย่างน้อย 3 เครื่องที่เป็น physical แยกกันทำ replication กัน เพื่อเพิ่ม durability ของข้อมูล เนื่องจากข้อมูลส่วนใหญ่ของ MongoDB จะเก็บใน Memory เป็นระยะเวลาหนึ่ง หากเครื่องดับไปเครื่อง ข้อมูลที่ยังค้างใน Memory แต่ยังไม่ write ลง disk จะสูญหายทันที

สำหรับผมตอนนี้ใช้งาน MongoDB แค่เพียงส่วนของ Log เนื่องจากยอมให้ durability ต่ำไปนิดหน่อยได้ครับ ส่วนอื่นๆ ยังคงใช้ MySQL ตามปกติ ขอให้โชคดีกับการ Scale ระบบของคุณนะครับ

ก่อนอื่นต้องอธิบายก่อนว่า Percona Server คือ MySQL เวอร์ชั่นปรับปรุงนั่นเอง โดยทางทีมพัฒนาได้นำเอา InnoDB Engine ไปพัฒนาและปรับปรุงประสิทธิภาพหลายๆ อย่าง และใส่ฟีเจอร์เด็ดๆ เพิ่มเข้ามามากมายจนสุดท้ายออกมาเป็น Percona Server ซึ่งเจ้านี่มีความเข้ากันได้กับ InnoDB Engine ตัวเดิมของ MySQL 100% ครับ ใช้แทน MySQL ได้ทุกประการ รวมไปถึง Tools ต่างๆ ที่เคยใช้กับ MySQL ได้ก็จะใช้กับ Percona Server ได้เช่นกัน (แม้จะเป็น MyISAM ก็สามารถใช้งานได้ปกติไม่มีปัญหาใดๆ ครับ แค่ performance จะยังคงเหมือน MySQL ไม่ได้ถูกปรับปรุงขึ้นตามด้วย)

ส่วน Tools ที่เราจะใช้สำหรับ Backup จริงๆ ชื่อ XtraBackup ครับ ซึ่งเป็นทีมพัฒนาทีมเดียวกับ Percona Server (และ Percona Data Recovery Tool for InnoDB จากบทความที่แล้วด้วยเช่นกัน) เจ้าตัว Xtrabackup นี้จริงๆ ใช้งานกับ mysql ธรรมดาที่ไม่ใช่ Percona Server ก็ได้แต่จะมีความสามารถบางอย่างที่ทำไม่ได้หากไม่ได้ใช้ Percona Server ครับ เช่น การ Backup/Restore ฐานข้อมูลเฉพาะตารางบางตารางที่เราต้องการ (เพื่อประหยัดเวลา/cpu ของ server) เป็นต้น ซึ่ง Tools ตัวนี้จะช่วย Backup แบบไม่ต้องปิด server (ไม่ต้อง Lock Table ระหว่างทำการ backup) ได้เฉพาะตารางที่ใช้งานฐานข้อมูลชนิด InnoDB เท่านั้น (จริงๆ MyISAM ก็ใช้ Tools ตัวนี้ช่วย backup ได้ครับ แค่จะยังติด lock อยู่เหมือนเดิม) นอกจากนี้หากเราใช้งานฐานข้อมูลบน VPS หรือ Cloud ที่ให้พื้นที่ใช้งานน้อยๆ ยังสามารถ Backup เป็นแบบ Incremental หรือส่งไฟล์ Backup เป็น stream ไปเข้า server ตัวอื่นที่มีพื้นที่เยอะกว่าได้อีกด้วย! (Amazing ไหมละ!) ซึ่งการ Backup โดยที่ Server ยังคงให้บริการได้ปกติแบบนี้เราจะเรียกว่า Hot Backup ครับ ส่วนการ Backup ที่จำเป็นต้องปิด Server ระหว่าง Backup เราจะเรียกว่า Cold Backup เอาละหลังจากติดตั้งเสร็จแล้ว (และต้องมี account root ของ OS ด้วยนะครับ) ลองมาดูวิธีใช้งานกันดีกว่าครับ (ทุกขั้นต้อนต้องทำขณะเป็น root ครับ)

ขั้นตอนการ Backup

1. innobackupex –user=DBUSER –password=DBUSERPASS –no-lock –defaults-file=/path/to/my.cnf /path/to/BACKUP-DIR/
   แก้ dbuser/dbuserpass ให้เรียบร้อย และ path นี้เป็น dir สำหรับเก็บ backup ที่ได้ออกมา รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ (ถ้าโปรแกรมฟ้องว่าหา datadir ไม่พบให้ไปแก้ my.cnf เติม datadir เข้าไปครับ ทั่วไป default จะอยู่ที่ /var/lib/mysql แต่ถ้ามี datadir แล้วยังฟ้อง แสดงว่าหาไฟล์ my.cnf ไม่เจอ ตรวจสอบไฟล์ my.cnf ให้ดีว่า path ที่ระบุถูกต้องหรือไม่)
2. innobackupex –apply-log /path/to/BACKUP-DIR/xxx
   โดยที่ xxx คือ dir ที่โปรแกรมสร้างขึ้นซึ่งมักจะเป็นชื่อวันที่ + เวลาที่ backup รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ (ถ้าโปรแกรมฟ้องว่า ibbackup เลือก binary ไม่ถูก ให้เติม option –ibbackup ตามด้วยชื่อในหน้านี้โดยเลือกให้ถูกต้องตามที่เขียนไว้ครับ)

ขั้นตอนการ Restore

1. เมื่อต้องการ Restore Backup ที่เก็บไว้ ให้สั่ง “service mysql stop” ลบข้อมูลใน datadir ทิ้งให้ว่างเปล่า (หรือจะแค่เปลี่ยนชื่อ ป้องกันความผิดพลาดก็ได้ครับ) แล้วสั่ง
   innobackupex –copy-back –default-file=/path/to/my.cnf  /path/to/BACKUP-DIR/xxx
   รอจนปรากฎคำว่า “innobackupex: completed OK!” ที่บรรทัดสุดท้าย แสดงว่าสำเร็จ ถ้าขึ้นว่า “Original data directory ‘./’ is not empty! at /opt/local/bin/innobackupex” แสดงว่าหาไฟล์ my.cnf ไม่เจอ
2. chown -R mysql:mysql /var/lib/mysql
   เพื่อเปลี่ยน permission จาก root (user ที่เราใช้อยู่) เป็น mysql แล้วสั่ง “service mysql start” เป็นอันเสร็จ ง่ายไหมล่ะครับ หุหุ

ขั้นตอนการทำ Replication

อันนี้เป็นของแถมครับ โดยปกติแล้วเราจะทำ Replication กันเราจะต้อง Backup ข้อมูลจากเครื่อง Master และสั่ง Lock Table ไม่ให้มีการเปลี่ยนแปลงข้อมูลได้จนกว่าจะ Setup Replication เสร็จ แต่นี่ไม่ต้องครับ ตัว Master ยังคงให้บริการได้ปกติและเราสามารถเพิ่มจำนวน Slave กี่ตัวก็ได้ในขณะนั้นตามต้องการ โดยให้ทำตามขั้นตอน Backup จนจบขั้นตอนที่ 2 แล้วต่อด้วยขั้นตอนด้านล่างต่อครับ

1. หลังได้ไฟล์ Backup ชื่อ xxx (เป็นเวลา backup) แล้วสั่ง
   tar -zcvf db.tar.gz xxx
   ให้เรียบร้อย โดย xxx คือ dir ที่เก็บ backup ของเราเอาไว้ (ที่ชื่อเป็นวัน-เวลา backup นั่นแหละครับ) เพื่อเตรียมโยนไปยัง server อีกตัวที่ต้องการจะทำ Slave ครับ
2. โยนไฟล์ db.tar.gz ที่บีบอัดไว้ไปยังเครื่อง Slave ด้วย rsync, scp ตามแต่สะดวกครับ หรือใครไม่ได้ลงไว้ ก็ใช้ tools มาตรฐานเลยครับ ssh ด้วยคำสั่ง
   ssh USER@SLAVE_IP cat < “/path/to/db.sql.gz” “>” “/path/to/save”
   ก็แก้ไข USER, SLAVE_IP, path ตัวแรก (เครื่องที่มี backup ไว้), path ที่ต้องการจะส่งไปให้ (เครื่อง slave) ให้ถูกต้องแล้วส่งไฟล์ได้เลยครับ
3. โยนไฟล์ my.cnf จากเครื่อง Master ไปยังเครื่อง Slave ด้วยคำสั่งเดียวกันกับข้อ 2 ครับ
4. mysql -uroot -p เข้าในเครื่อง Master ไปสร้าง user สำหรับเครื่อง Slave ดังนี้ครับ
   GRANT REPLICATION SLAVE ON *.*  TO ‘repl’@'$slaveip’ IDENTIFIED BY ‘$slavepass’;
   repl คือ user mysql ส่วน $slaveip, $slavepass ก็ตามชื่อเลยครับ
5. login เข้าเครื่อง Slave แล้ว untar ด้วย
   tar -zxvf db.tar.gz
   ที่ตำแหน่งที่เราเก็บไฟล์ไว้ตามคำสั่งในข้อ 2
6. service mysql stop ที่เครื่อง slave
7. copy dir xxx ที่ได้จากการแกะ tar ไปที่ datadir ของเครื่อง Slave ทับไปเลย (หรือจะ mv เปลี่ยนชื่อ datadir เดิมเก็บไว้ก่อนก็ได้เช่นเดิมครับ)
8. แก้ไฟล์ my.cnf ที่เครื่อง slave โดยบรรทัด server-id แก้เป็น
   server-id=2
9. ถ้าใช้ ubuntu หรือ debian ให้แก้ไฟล์ /etc/mysql/debian.cnf ซึ่งจะมี user debian-sys-maint อยู่ในนั้นด้วยครับ โดยแก้ password ให้เป็น password เดียวกับเครื่อง Master ไม่อย่างนั้น startup script “service mysql stop/start/restart” จะพังครับ
10. chown -R mysql:mysql datadir
    โดย datadir แก้เป็นตำแหน่งที่เก็บข้อมูล database ตามต้องการครับ (default คือ /var/lib/mysql)
11. เปิดไฟล์ xtrabackup_binlog_info ที่อยู่ใน datadir ที่เราพึ่ง copy มาจะพบเลขลักษณะประมาณนี้
    TheMaster-bin.000001 481
    ของคุณจะเป็นเลขอื่นที่ไม่ซ้ำกันกับผมแน่ๆ ครับ เป็นเลขตำแหน่ง log สุดท้ายของ database ที่เราต้องการจะ replicate นั่นเอง
12. mysql -uroot -p
    เข้า mysql เครื่อง Slave ครับแล้วพิมพ์

    CHANGE MASTER TO
    MASTER_HOST='$masterip',
    MASTER_USER='repl',
    MASTER_PASSWORD='$slavepass',
    MASTER_LOG_FILE='TheMaster-bin.000001',
    MASTER_LOG_POS=481;
    START SLAVE;
    แก้ข้อมูลให้ถูกต้องโดยตามข้อมูลที่สร้างที่ผ่านมา

13. ลองสั่ง SHOW SLAVE STATUS \G โดยยังไม่ออกจาก MySQL Console หากพบบรรทัดเหล่านี้แสดงว่าสำเร็จแล้ว

             ...
             Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
             ...

เป็นไงบ้าง เจ๋งใช่ไหมละครับ ลองเก็บไปใช้กันดูนะครับ

1. top เครื่องมือหากินที่มีติดมากับ server ทุกตัว ใช้ดู CPU, Memory ของแต่ละ process ได้ เพื่อสังเกตถึงความผิดปกติของ process และยังสั่ง kill process ได้อีกด้วย
2. prstat -Z ตัวนี้คล้าย top แต่เอาไว้ใช้บน Solaris ครับ จะให้ข้อมูลที่เที่ยงตรงกว่า top แต่ถ้าเป็น linux ตระกูลอื่นก็ใช้ top นั่นแหละ
3. ps -elf มี process อะไรรันอยู่บ้างด้วย command อะไร
4. uptime ตรวจสอบว่าเครื่องนี้รันมาโดยไม่ล่มเป็นเวลากี่วันแล้ว
5. df -h ใช้เช็คพื้นที่ harddisk ที่เหลือ เอาไว้ดูว่าเครื่อง server หรือเครื่อง database ของเราพื้นที่ใกล้เต็มหรือยัง
6. apachetop -f <access_log_path> ใช้เช็คว่ามี URL ไหนที่ถูกรันถี่เป็นพิเศษ หรือมีการส่งข้อมูลมากเป็นพิเศษในขณะนั้น อันนี้รวมไปถึงถ้าโดนใครยิงถล่ม server ก็สามารถ monitor ได้เช่นกันว่ายิงมาจาก IP ไหน
7. mysql -u<username> -p แม้แต่ตัวคำสั่ง mysql เองก็สามารถใช้ตรวจสอบสถานะของ Database ได้เช่นกัน หลังจากเราพิมพ์ mysql -uroot -p เข้ามาแล้ว สามารถรันคำสั่งต่างๆ ได้ เช่น
   1. SHOW PROCESSLIST; ใช้ดูสถานะ Query ของ mysql ในขณะนั้น ถ้า table โดน Lock บ่อยมากๆ เราจะเห็นสถานะ LOCK ค้างตอนรันคำสั่งนี้เป็นจำนวนมาก
   2. SHOW STATUS; ใช้ดูสถานะค่าต่างๆ ของ mysql ซึ่งมีอยู่มากมายมหาศาล อ่านรายละเอียดของค่าแต่ละตัวได้ที่นี่
8. mytop -u <username> -p <password> -d <database_name> เมื่อเรามี top ใน server ก็ต้องมี mytop ใน mysql ตัวนี้เอาไว้ monitor สถานะปัจจุบันของ mysql ได้ทั้ง Query per sec, mysql รันมากี่วัน กี่ชั่วโมงโดยที่ไม่ล่มแล้ว, มีปริมาณ Select/Insert/Update/Delete ในขณะนั้นมากน้อยเพียงใด, มี slow query ไหม, Bytes per sec ฯลฯ มีประโยชน์มากครับ
9. dtrace อันนี้มีเฉพาะใน Solaris แต่ขอบอกว่าเป็น Tools ที่เทพมากๆ ครับ โดยหากจะใช้เราควรไป Download Dtracetoolkit มา ถ้าใครเคยใช้ Firefox ก็คิอซะว่า Dtrace คือ greasemonkey และ Dtracetoolkit คือชุดของ script สำหรับรันจำนวนมากนั่นเอง ซึ่งภายใน toolkit จะมีหลากหลายภาษาการเขียนโปรแกรมมาให้เป็นจำนวนมาก วิธีใช้จะต้องลง extension ของภาษานั้นๆ เช่นจะใช้งาน dtrace สำหรับ php ต้องลง pecl install dtrace เสียก่อน จึงจะสามารถรัน script ที่ download มาได้ เมื่อรันแล้วจะมีข้อมูลหลายอย่างที่น่าสนใจเช่น function อะไรที่ class ไหนใช้เวลารันไปกี่วินาที รันไปกี่รอบ หรือแม้แต่กิน memory ไปเท่าไร ช่วยให้การหา bottleneck ของโปรแกรมว่าส่วนไหนของโปรแกรมทำงานช้าทำได้ง่ายมากๆ เพราะลงไปถึงระดับ function กันเลยทีเดียว อ่านรายละเอียดเพิ่มเติมได้ที่นี่

ก็ตามนี้ครับ list tools ช่วยตรวจสอบสถานะ server ใครมีปัญหาอะไรก็ลองรันดูเผื่อจะเจออะไรนะครับ tool ทุกตัวที่ผมแนะนำคิดว่าน่าจะมีอยู่ใน server อยู่แล้ว ไม่ต้องติดตั้งอะไรเพิ่มครับ ขอให้โชคดีครับ

Tools ที่ว่าตัวนี้คือ Newrelic ซึ่งจะช่วยตรวจสอบ server ของเราและรายงานผลออกมาเป็นกราฟอย่างสวยงาม เข้าตรวจสอบได้ผ่านเว็บไซต์ ใช้งานง่ายมาก ไม่ต้องทนดู shell ดำๆ อ่านยาก และนอกจากนี้ยังไม่กินที่ server เราอีกต่างหาก เพราะข้อมูลที่ได้จะถูกส่งไปยัง cloud server ของทาง newrelic และเมื่อเราต้องการตรวจดูข้อมูล ก็เพียงแค่ login เข้าไปตรวจสอบเท่านั้น ซึ่ง Tools ตัวนี้เราจะต้องทำการติดตั้งตัวดักจับข้อมูลที่ server ของเรา ซึ่ง support ทั้งตัวภาษา .NET, Java, Ruby, PHP และ OS ที่ support ก็ครอบคลุมตั้งแต่ Redhat, Centos, Ubuntu, Debian และ Linux ตัวอื่นๆ รวมไปถึง Solaris! php ที่ support มีทั้งเวอร์ชั่น 5.2 และ 5.3 ครอบคลุมมากทีเดียว

มาดูกันดีกว่าว่า Newrelic ทำอะไรได้บ้าง

กราฟโดยรวมของ server ของเรา

1. Monitor ทั่วไปโดยสังเกตที่แถบสีด้านล่างจะมีอยู่ 5 สีได้แก่
   • Request Queueing – คือมี Queue รอจะใช้งานอยู่มากหรือไม่ หากมีสูง แสดงว่า script เราทำงานช้าเกินไป หรือ apache config มีปัญหาทำให้เกิดการรอกันใช้งานระหว่างผู้ใช้มากเกินไป
   • PHP – เวลาที่ PHP ใช้งาน อันนี้ถ้าสูงมาก แสดงว่า script ที่เราเขียนมีปัญหาติดลูปหรือติดปัญหาบางอย่าง
   • Database – ตรงๆ ตัวครับ เวลาที่ใช้ไปกับ Database ถ้า Database ช้าถูสีกราฟตัวนี้จะเห็นชัดเลยทีเดียว
   • Memcache – เวลาที่ใช้ของ memcache ตรงนี้ผมยังไม่เคยเห็นค่าพุ่งสูงเลยแม้แต่น้อย ไม่เคยมีปัญหาครับ
   • All External – เวลาที่ใช้ในการดึงข้อมูลจากเว็บไซต์ภายนอกที่ไม่ใช่เว็บไซต์ของเรา เช่นมีการต่อ API twitter, Facebook ซึ่งพวกนี้แหละที่เป็นตัวกินเวลาทำให้เว็บของคุณช้าโดยที่ไม่รู้ตัว ทั้งๆ ที่คุณไม่ได้เขียนโค้ดแย่ซักหน่อย วิธีแก้คือลดการติดต่อกับเว็บภายนอกให้เหลือเฉพาะส่วนจำเป็นเท่านั้น อาจใช้ memcache เข้ามาช่วยตรงจุดนี้ได้เช่นกัน

   นอกจากนี้แล้ว ในหน้าแรกนี้ยังมีกราฟแสดง CPU, Memory, Apdex(คะแนนความพอใจของผู้ใช้), Throughput (ปริมาณข้อมูล) อีกด้วย

2. 

   URL ที่ช้า

   ส่วนนี้เป็นการแสดงว่าหน้าใดที่เป็นตัวการของปัญหาความช้า ซึ่งจะจัดเรียงให้เราเห็นชัดเจนเลยว่าปัญหาเกิดจากหน้าใดมากที่สุด นอกจากนี้ยังเลือกให้จัดเรียงตาม ค่าเฉลี่ย Response Time มากที่สุด, Apdex ห่วยสุด (คะแนนความพึงพอใจน้อยที่สุด), กินเวลามากที่สุด (ไม่จำเป็นต้องมี Response Time มากที่สุดเสมอไป อาจถูกเรียกบ่อยเกินไปก็เป็นได้), ปริมาณการส่งข้อมูลมากที่สุด และ เรียงตามค่ามาตรฐาน (Standard Deviation) ก็ได้

3. 

   กราฟ Database

   (สมาชิก Silver เท่านั้น) คล้ายกับข้อ 2 เพียงแต่เปลี่ยนจากหน้าเป็น Query ที่ช้าที่สุด มีรูปแบบการจัดเรียงให้เลือกเหมือนกัน และมีกราฟสรุปว่ามีอัตราการ INSERT, SELECT, UPDATE, DELETE อย่างไหร ตัวไหนกินเวลามากที่สุด

4. 

   หน้า Transaction Trace

   (สมาชิก Silver เท่านั้น) สรุปว่ามีหน้าอะไรบ้าง (เป็นรายครั้ง ไม่ใช่สรุปรวมเหมือนข้อ 2) ที่ทำงานช้า สามารถคลิกเข้าไปดูรายละเอียดเพิ่มเติมเป็นราย Query ได้ดังรูปด้านล่าง หากมี Query ไหนที่ทำงานช้าเกินไปสามารถคลิกเพื่อดูบรรทัดที่ script สั่งรัน query ตัวนั้นเพื่อตามหาต้นตอของความช้าได้อีกด้วย!

   

   หน้า Transaction Trace (ด้านใน)

5. 

   หน้า Scalability

   (สมาชิก Gold เท่านั้น) หน้านี้ไว้ใช้สำหรับดูการกระจายตัวของการใช้งาน CPU, Database, Response time ว่าช่วงเวลาใดมีการใช้งานหนักที่สุด สังเกตรการจุดสีของกราฟ ถ้ามีการกระจุกที่จุดใด จุดหนึ่ง ก็สรุปได้ว่าช่วงเวลานั้นมีการใช้งานหนัก

6. มี feature การทำงานเป็นทีม หากพบกราฟที่ผิดปกติ สามารถคลิก Add to note ไว้เพื่อให้สมาชิกในทีมคนอื่นมาดูต่อ และ discuss กันได้ แม้เวลาจะผ่านจากจุดนั้นไปแล้วนานแค่ไหนก็ตาม
7. ปกติแล้วถ้าแบบฟรีจะไม่สามารถดูข้อมูลย้อนหลังได้เกิน 30 นาที แต่ถ้าจ่ายตังหน่อยก็จะดูได้ตั้งแต่ 1 อาทิตย์ไปจนถึง 3 เดือน แต่ทั้งนี้และทั้งนั้น หากใครไม่อยากเสียตังก็สามารถใช้ API ดึงข้อมูลกราฟในแต่ละช่วงเวลามาเก็บที่ server ตัวเองได้ครับ ซึ่งทาง newrelic เปิด API ให้ดึงข้อมูลจากกราฟไปใช้ได้โดยตรงฟรีๆ

ด้วยข้อดีมหาศาลขนาดนี้ การ monitor server ของคุณจะง่ายขึ้นเป็นอย่างมากเลยทีเดียว แต่แน่นอนบาง feature ก็ต้องจ่ายเงินซื้อ แต่โดยส่วนตัวแล้วผมคิดว่าไม่แพงเกินไปหรอกครับ หากเว็บของเรามีคนเข้าเยอะจนต้องปรับ performance กันขนานใหญ่ขนาดนี้แล้ว ขอให้ทุกท่านโชคดีกับการดูแล server นะครับ