เคยมั้ย? ที่ต้องซื้อตั๋วแล้วล่ม…

แจ้งเพื่อทราบ: เนื้อหน้าต่อไปนี้ เป็นกรณีศึกษาที่เป็นการคาดเดาเหตุผลที่ทำไมถึงล่ม ซึ่งอยู่บนพื้นฐานข้อมูลจริงบางส่วน นำไปใช้อ้างอิงในเหตุการณ์จริงว่าระบบจะล่มเพราะสิ่งที่คาดการณ์นี้ไม่ได้ แต่เป็นเนื้อหา เพื่อใช้ศึกษาความเป็นไปได้จากประสบการณ์ของผู้เขียนเท่านั้น

จากกรณี เดี่ยว 10 ของโน้ส อุดมหยุดขายบัตรกะทันหันหลังระบบขายบัตรล่ม เลยเอามาตั้งโจทย์เล็กๆ ว่า

“มีร้านเซเว่นอีเลฟเว่นที่มีทั้งหมด 8,500 สาขา มีจุดขายเคาน์เตอร์เซอร์วิสรวม 20,000 จุด มีระบบรองรับธุรกรรมสูงสุดระดับ 1,000,000 รายการภายใน 1 วัน”

พูดง่ายๆ คือ มีระบบที่รองรับได้วินาทีละ 11.57 รายการ ตลอดทั้งวัน

จากข่าวต้นเรื่องและโจทย์ทำให้รู้ว่า มีการทดสอบระบบขายบัตร เดี่ยว 10 พร้อมกัน 600 สาขาก็สามารถรับมือได้ แต่ไม่ได้บอกว่ารองรับได้กี่รายการต่อวินาที แต่ผู้ทดสอบลืมไปหรือเปล่าวระบบต้องรองรับ 20,000 จุด ไม่ใช่ 600 จุด ซึ่งทำให้เห็นว่า คนทดสอบระบบกำลังทดสอบระบบที่อัตราความสามารถระบบที่เพียง 1 ใน 30 ของระบบที่กำลังจะต้องไปใช้งานจริงในอนาคต

ลองนึกภาพตามง่ายๆ ว่ามีเซเว่นอีเลฟเว่นและจุดขายเคาน์เตอร์เซอร์วิส กดปุ่มซื้อพร้อมกันในวินาทีเดียวกัน ตอนเปิดขายบัตร เกือบ 20,000 จุดทั่วประเทศ ระบบที่รองรับได้วินาทีละ 11.57 รายการจะรองรับไหวไหม? เพราะระบบที่จะรองรับการทำรายการแบบนี้ได้ต้องพูดว่า “ระบบรองรับธุรกรรมสูงสุดระดับ 1,728,000,000 รายการภายใน 1 วัน” มันถึงจะถูกมากกว่า วิธีการแก้ไขที่ดีอีกวิธีคือการเลี่ยงยิงระบบโดยเพิ่มระบบคิว แบบคล้ายๆ กับจองตั๋วของ AirAsia ก็เป็นการแก้ปัญหาที่ถือว่าโอเคระดับหนึ่ง แต่ก็ยังทำให้ระบบโดยรวมจองตั๋วไปได้ตลอดจนจบทุกๆ รายที่เข้าไปจอง ส่วนอีกแบบคือใช้พวก Cloud service เอาก็ได้นะ ถ้าระบบที่คาดการณ์ไว้แล้วมันไม่ไหวก็ scale เอาได้ทันที แต่ส่วนตัวคิดว่า วิธีคิดของผู้ใหญ่ที่ตัดสินใจคงยังยึดติดกับอะไรเดิมๆ ก็ได้แต่ยืนไว้อาลัย เช่นเรื่องความลับของข้อมูลอะไรพวกนี้ เพราะงานระดับใหญ่แบบนี้มักเลือก Cloud ระดับ Enterprise ที่ค่อนข้าง private และมี NDA Agreement ที่ค่อนข้างเชื่อถือได้อยู่แล้ว

เรากลับมาที่ส่วนการออกแบบ ส่วนตัวผมเชื่อว่าระบบออกแบบให้รองรับคนเยอะ มันก็รองรับได้นะ คือจากระบบที่ผมดูแลและยังคงปรับปรุงระบบอยู่เรื่อยๆ นั้น การรองรับการทำงานแบบวินาทีต่อวินาทีที่มีการกระหน่ำเข้ามาแบบนี้ ปัญหานี้ส่วนใหญ่ที่เจอคือ I/O ระหว่าง DB กับ App มันตันครับ ผมเจอเยอะที่ว่า CPU ทำงานยังไม่ถึง 10% เลย แต่ process มันไปค้างที่ I/O ที่กำลังอ่าน-เขียนกันอยู่ โดยผมลอง top ดูรายการของ process จะเห็นเลยว่า process ฝั่ง App ถูก fork เป็นพันตัว แต่โดน waiting เพียบ เพราะมันไป waiting ข้อมูลที่รอจากฝั่ง DB ซึ่ง DB มันก็กำลังปิดงานที่กำลัง process อยู่เรื่อยๆ ซึ่งในระดับของ DB มันมีคิวอยู่แล้ว มันค่อยๆ ทำไปตามสภาพและความสามารถของ H/W ที่มีอยู่ แต่เมื่อคิวมันเริ่มตัน มันทำงานช้าจนไม่พอที่จะตอบสนองได้ทุก process ที่กำลังกระหน่ำเข้ามา มันเลยพาลทำล่มหมดเพราะหน่วยความจำไม่พอที่จะให้ process ของ App มันไปรอ waiting ได้ทุกตัวครับ

วิธีการแก้ของพวกนี้คือทำยังไงก็ได้ให้ I/O ฝั่ง DB มันทำงานให้ตอบหนองทันกับ process ฝั่ง App ให้ได้ เพื่อไม่ให้เกิด waiting ค้างในระบบนานจนล้นกว่าหน่วยความจำที่มีน่ะครับ เดี่ยวนี้ที่เจอๆ ก็มีหลายแบบนะ คือจับ DB ใช้ SSD ตัวแรงสุด ก็ช่วยได้มาก หรือเอา DB ใส่พวก MEMORY DB แทน ก็ทำงานได้เร็วมากๆ (แต่ตัวหลังไฟดับทีนี่งานเข้าเลยนะ) หรือจะแบ่งโหลดไปเลยก็ได้นะ โดยมี App จัดนึงในการคิวขั้นกลางว่า DB ตัวไหนรับโหลดของ process ID อะไรแบบนั้น ซึ่งถ้าเป็นแบบจองตั๋วแบบนี้แบ่งไปเป็น farm server เอาก็ได้นะ ตัวเลือกรอบการแสดง ก็รู้แล้วว่า farm server ตัวไหนจะรับโหลดรอบไหนไปแทน หรือจะให้ละเอียดกว่านั้นก็คือกระจายระดับ zone ของแต่ละรอบก็ทำให้ระบบโดนกระจายโหลดไปได้มาก ไม่ได้กระหน่ำเข้ามาที่ระบบตัวเดียว แล้วพาลทำล่มทั้งระบบ

คือวิธีการแก้ไขหรือวางแผนมีหลายรูปแบบมากๆ อยู่ที่ว่าตอนทดสอบระบบคิดถึงระดับความเลวร้ายที่สุดที่ระบบจะรองรับได้หรือไม่มากกว่า งานนี้คนทดสอบระบบโลกสวยเกินไปหน่อย  (╯°□°)╯︵ ┻━┻)

ความหมาย uptime guarantee ของ 99%, 99.9% หรือ 99.99%

ใน 100% ของ uptime guarantee ของทางด้าน computer system/network นั้นหมายถึง 1 ปี (คิดที่ 518,400 นาที หรือ 43,200 นาทีต่อเดือน)

ในทุกๆ 0.1% ของ downtime ทางด้าน computer system/network มีค่าเท่ากับ 8-9 ชั่วโมงต่อปี

เพราะฉะนั้นใน 1 ปีนั้น
– 99% หมายถึง ยอมให้ downtime ได้ 86.4 ชั่วโมง (หรือ 3 วัน 6 ชั่วโมง)
– 99.9% หมายถึง ยอมให้ downtime ได้ 9 ชั่วโมง
– 99.99% หมายถึง ยอมให้ downtime ได้ 52 นาที (หรือประมาณ 1 ชั่วโมง)

ในองค์กรทั่วไปมักใช้ 99% เป็นหลัก เพราะมักมีช่วงเวลาที่แน่นอนที่สามารถปิดระบบเพื่อทำ System Maintenance ได้ชัดเจนและยาวนาน ซึ่งไม่กระทบต่อการให้บริการอื่นๆ โดยมักทำในช่วงวันหยุดนอกเวลาทำงานปรกติ

ส่วนที่มักใช้ 99.9% นั้นจะเป็น Web hosting หรือบริการ Online โดยทั่วไป เพราะมักใช้ตอน System Maintenance ที่อาจจะทำตอนช่วงคนใช้งานน้อยเพื่อนำไปปรับปรุงระบบ หรือเปลี่ยนแปลงตัว hardware บางส่วนที่เสียหาย

สำหรับ 99.99% มักใช้ในงานด้าน Cloud/CDN services ที่มีการเข้าถึงได้จากทั่วโลกและมักจะไม่มีช่วงที่มีการใช้งานน้อยให้สามารถหยุดการ System Maintenance ได้บ่อยครั้งและนานมากนัก เพราะฉะนั้นจึงมีการใช้ตัวเลขตรงนี้ แต่นั้นหมายถึงราคาที่แพงมากขึ้น เพราะต้องคัดตัว hardware ที่สามารถรองรับการแก้ไขปัญหาโดยที่ไม่ต้องปิดระบบทั้งหมดรวมไปถึงระบบที่รองรับการล่มแล้วสลับไปใช้งานระบบอื่นๆ ได้เกือบจะในทันที

ตัวอย่างเช่น SLA ของ Google Apps for Business นั้นระบุ uptime ที่ 99.9% (อ้างอิง http://www.google.com/apps/intl/th/terms/sla.html ข้อมูล ณ วันที่ 24 ม.ค. 2013)

โดยจากรายงานของ blog ของ google แจ้งว่าในปี 2010 Gmail มี uptime ที่ 99.984% ใกล้เคียง 99.99% uptime มากๆ (อ้างอิง Official Google Enterprise Blog: Destination: Dial Tone — Getting Google Apps to 99.99%)

โดยใน SLA ของ Google Apps for Business นั้นยังมีการระบุระยะเวลาที่ชดเชยถ้า uptime น้อยกว่าที่กำหนดไว้ตามสัดส่วนดังนี้

น้อยกว่า 99.9% ถึง 99.0% ชดเชย 3 วัน
น้อยกว่า 99.0% ถึง 95.0% ชดเชย 7 วัน
น้อยกว่า 95.0% ชดเชย 15 วัน

การทำ Google Apps Zone file สำหรับ Bind9 และแก้ไขปัญหาอีเมลโดเมนตัวเองส่งเข้า Gmail (ที่ใช้ Google App) ไม่ได้

ตัว zone file ใช้แบบนี้ครับ

$TTL 86400
@       IN      SOA     ns.thinkpad.in.th. root.thinkpad.in.th. (
; dmn [thinkpad.in.th] timestamp entry BEGIN.
2009021300
; dmn [thinkpad.in.th] timestamp entry END.
8H
2H
4W
1D )
IN NS   ns.thinkpad.in.th.

@                   IN TXT  "v=spf1 ip4:222.222.222.222 include:gmail.com~all include:thinkpad.in.th~all ~all"
@                   IN MX   1 aspmx.l.google.com.
@                   IN MX   3 alt1.aspmx.l.google.com.
@                   IN MX   3 alt2.aspmx.l.google.com.
@                   IN MX   5 aspmx2.googlemail.com.
@                   IN MX   5 aspmx3.googlemail.com.
@                   IN MX   5 aspmx4.googlemail.com.
@                   IN MX   5 aspmx5.googlemail.com.

_xmpp-server._tcp   IN SRV  5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp   IN SRV 20 0 5269 xmpp-server4.l.google.com.

_jabber._tcp        IN SRV  5 0 5269 xmpp-server.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server1.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server2.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server3.l.google.com.
_jabber._tcp        IN SRV 20 0 5269 xmpp-server4.l.google.com.

thinkpad.in.th.         A       222.222.222.222
ns              IN      A       222.222.222.222
mail            IN      CNAME   ghs.google.com.
www             CNAME           thinkpad.in.th.
ftp             CNAME           thinkpad.in.th.

ส่วนการแก้ไขปัญหาการที่อีเมลโดเมนตัวเองส่งเข้า Gmail (ที่ใช้ Google App) ไม่ได้  แต่ส่งเข้ากล่องเมลในเครื่อง Server ตัวเองแทน โดยผมใช้ Postfix เป็นตัวจัดการอีเมล ซึ่งต้องไปดู virtual_mailbox_domains (ของผมอยู่ที่ /etc/postfix/domains) ว่ามี domain ของเราอยู่ใน MTA list หรือไม่  ถ้ามีให้ลบออกไปครับ ไม่งั้นมันก็จะส่งอีเมลทั้งหมดของโดเมนดังกล่าวเข้าเครื่องตัวเองอยู่แบบนั้น เช่นเดียวกับบัญชีอีเมลด้วย โดยให้ดูว่าในบัญชีอีเมลของเรามีชื่ออีเมลในเครื่อง Server เราหรือเปล่า ถ้ามีก็ลบออกไปด้วยเช่นกัน ไม่งั้นมันก็จะส่งเข้าบัญชีอีเมลในเครื่องตัวเองเช่นกันครับ
ลองทำกันดูครับไม่ยาก ;P
งานนี้ต้องขอบคุณ @sugree มาก ๆ ครับ ไม่ได้อาจารย์นี่มึนไปอีกอาทิตย์แน่ ๆ

ติดตั้ง SVN Server บน Windows ภายใน 10 นาที

เป็น entry ที่อยู่ใน Draft นานเป็นอันดับต้น ๆ (เกิน 1 ปีแน่  ๆ) แต่จนแล้วจนรอด มันรกหูรกตาเลยเอามาปัดฝุ่นเขียนเพิ่มเติม และเอาออกมาสักทีนึง

ใครไม่รู้ว่า SVN คืออะไรก็ตามไปอ่าน entry เก่าได้ที่นี่

สิ่งที่ต้องเตรียมก่อนในการติดตั้ง (เวลาดาวน์โหลดไม่นับรวมเวลาในการติดตั้ง) คือ SVN Server ซึ่งเป็นตัวจัดการไฟล์ที่เรานำมาใส่ใน Store ของมัน และ SVN Service เป็นโปรแกรมเล็ก ๆ ที่นำ SVN Server เข้าไปอยู่ใน Services list ของ Windows เพื่อให้ตัว SVN Server ทำงานในระดับ Background Application และสามารถสั่งให้ SVN Server ทำการเริ่มการทำงานทั้งแต่เปิดเครื่องผ่าน Services ของ Windows เองได้อย่างง่าย ๆ

SVN Service

Summary : Runs svnserve as a Windows service (requires .NET Framework 1.1)

Category : libraries

License : GNU General Public License

Owner(s) : ricos, sclerose

การติดตั้งทั้งหมดอ้างอิงบน Windows XP Professional

  1. ดาวน์โหลด SVN Server ได้จาก http://subversion.tigris.org/ และดาวน์โหลดตัว SVN Service จาก http://svnservice.tigris.org/ 
  2. ติดตั้ง SVN ลงใน c:\svn\ หรือ directory ใด ๆ ที่ต้องการก็ได้ (ใน entry นี้อ้างอิง c:\svn\ ครับ)
  3. ทดสอบว่ามันจะทำงานได้หรือเปล่าก็เปิด Commnand Prompt(พิมพ์ cmd ที่ Start > Run)
  4. ไปที่ c:\svn\bin (พิมพ์ cd c:\svn\bin)
  5. พิมพ์ svnadmin เพื่อทดสอบดู
    ถ้าขึ้นว่า “svnadmin.exe – Unable To Locate DLL”
    ให้ติดตั้ง Visual C++ 6.0 VCREDIST.exe โดยดาวน์โหลดได้ที่นี่ ถ้าสั่งให้ทำงานแล้วไม่มีปัญหา ก็ทำการทดสอบส่วนของ svnserve.exe เพื่อทดสอบว่าสามารถสั่งให้ SVN Server ทำงานได้หรือไม่
  6. พิมพ์ svnserve -r d:\svndatarootdir
    โดยที่ svndatarootdir คือ directory ที่ใช้สำหรับเก็บ repository ทั้งหมดของ svn ของเรา
  7. ถ้าใช้คำสั่งในข้อ 6 แล้วไม่มีปัญหา ให้ปิด Commnand Prompt แล้วติดตั้ง SVN Service
  8. ทำการเรียก SVNService Administration

    2007-12-08_052919

  9. แล้วทำการตั้งค่าดังนี้

    2007-12-08_051949 
    – ช่อง SVN Binary Path ให้ชี้ไปที่ c:\svn\bin ที่เก็บตัว binary file ของ svnserve.exe
    – ช่อง Repository Path ให้ชี้ไปที่ svndatarootdir หรือที่เก็บ directory ของ repository ทั้งหมด (ในตัวอย่างเป็น d:\svn)
    – Listen Host อันนี้กำหนด IP หรือ Hostname สำหรับใช้ติดต่อเข้ามา ซึ่งถ้าใช้คนเดียวก็กำหนดเป็น localhost ไปครับ
    – Listen Port กำหนด Port ที่เข้าใช้ SVN Server แนะนำให้ใช้ Port 3690 ไปเลยครับผม เพราะเป็น Port มาตรฐานของ SVN Server อยู่แล้ว
    – กด Save และ Close ปิดไปครับ

  10. เข้าไปทั้งค่า Service เพิ่มเติมที่ Service ของ Windows ได้ที่ Administrative Tools (ถ้าหาใน Start ไม่เจอให้ไปที่ Control Panel และไปที่ Administrative Tools ก็ได้)

    2007-12-08_053608

  11. ไปหา Name ที่ชื่อว่า SVNService แล้วดับเบิ้ลคลิ้กเรียก SVNService Properties ขึ้นมา

    2007-12-08_053739

  12. แล้วตั้งค่าที่ Startup type เป็น Automatic เพื่อให้เมื่อเปิดเครื่องมาให้ SVNService ทำงาน แล้วตัว SVNService จะไปเรียก svnserve พร้อมตั้งค่าตามที่เราตั้งไว้ใน SVNService Administration มาให้ แล้วกดปุ่ม Start เพื่อให้ SVNService ทำงาน

    2007-12-08_053928

  13. ถ้าทุกอย่างราบรื่น ตอนนี้เราก็จะได้ SVN Server ขึ้นมาทำงานแล้ว

ต่อไปเป็นส่วนของการทดสอบ และตั้งค่า Repository และ SVN Server ที่เราติดตั้งว่าทำงานปกติหรือไม่

  1. ให้ดาวน์โหลด TortoiseSVN (A Subversion client, implemented as a windows shell extension.) มาติดตั้ง
  2. สร้าง directory ใหม่ใน d:\svn หรือที่เก็บ repository ทั้งหมด

    2007-12-08_054836 

  3. ทำการสร้าง Repository ใหม่

    2007-12-08_054927

  4. แล้วเลือก Native filesystem

    2007-12-08_055011

    2007-12-08_055035

  5. เราจะได้โครงสร้าง Directory ทั้งหมดภายใน d:\svn\test ดังภาพนี้

    2007-12-08_055133

  6. ทดสอบว่า test repository ของเราทำงานได้หรือไม่ก่อน
  7. คลิ้กขวาที่ Desktop แล้วเลือก TortoiseSVN แล้วเลือก Repo-browser

    2007-12-08_054536 

  8. แล้วพิมพ์ URL ดังรูปนี้

    2007-12-08_055623
     

  9. แล้วเราจะได้หน้าต่างของข้อมูลภายใน test repository แบบด้านล่าง (ว่าง ๆ เพราะไม่มีอะไรอยู่ภายใน) ถ้าได้ดังรูปด้านล่างนี้และ expanded ตัว list ออกมาได้โดยไม่มีการแจ้ง error ใด ๆ ถือว่า SVN Server ทำงานได้สมบูรณ์แล้ว

    2007-12-08_055641

สำหรับตอนต่อไป (คราวนี้สัญญาว่าจะลงให้เร็วที่สุดแน่ ๆ) จะเป็นการกำหนดค่า ต่าง ๆ ในการเข้าใช้งานเช่น username/password สำหรับเข้าถึงข้อมูล รวมไปถึงระบบสิทธิ์การเข้าถึงแต่ละ user ที่เข้ามาใช้ด้วยครับ

วันนี้ขอไปนอนก่อนหล่ะครับ ;)

[Update 11/12/2007]

อ้างอิงจาก

หลักการทำ Web Server ที่ดี เอาไปใช้ประยุกต์กับ Server แบบอื่นๆได้

  1. ซึ่งโดยทั่วไปก็คือ บริหาร IO ดีๆ ใส่ RAM เยอะๆ
  2. CPU แรงๆ ไม่มีค่อยมีผลต่างกันมากมายเท่ากับ Resouce ที่มีให้ใช้ครับ นอกจากว่าเป็นการทำงานในลักษณะประมวลผลทางด้าน CGI มากๆ ควรให้ความสำคัญด้านนี้ด้วย แต่ไม่มากเท่า RAM และ CPU ในความเร็วใกล้เคียงกัน แทบจะไม่มีผลแตกต่างกันมาก (ช่วยได้ไม่ถึง 10%) เพราะงานหลักของ httpd เน้นการบริหาร resouce ไม่ได้เน้นการคำนวณคณิตศาสตร์ CPU จึงหนักไปทางบริหาร process ของ OS มากกว่า และถ้า CPU ยัง มี usage ไม่ถึง 100% (หรือใกล้เคียง) ก็แปลว่า มันยังทำงานไหวครับ เพราะการที่ CPU ทำงานมาก แสดงว่า ต้องคำนวณมาก แต่มีผลน้อยกว่า IO ทำงานหนักครับ
  3. RAM ควรมีอย่างต่ำ 512 MBขึ้นไป แต่ว่าผมแนะนำ ที่ 1 GB อยากให้ยอมลด CPU เพื่อแรม ว่างั้นเถอะ เพราะเราทำให้ขั้นตอนประมวลผลทำงานได้เร็วขึ้นข้อมูลไม่คับคั้งมากจนเกินไป พร้อมที่จะดึงข้อมูลที่ใช้บ่อยๆ ก็เก็บใน RAM มาใช้ได้เร็วกว่า HD มาก ทำให้ระบบโดยรวมเสถียร์มากขึ้น การทำระบบ SWAP ต่างๆ ไม่ควรเกิน กว่า 60% จาก ความจุแรมเพราะไม่เสถียรและเปลี่ยงพื้นที่ HD โดยไม่จำเป็น
  4. HD ควรเป็น Ultrawide SCSI 10000 rpm ขึ้นไป ควรใช้ SCSI ครับ คนทำงานเป็น admin ชอบ SCSI เพราะมันไม่ค่อยเกเร และไม่ค่อยมีปัญหา + ทนทาน + ตอบสนองเร็ว + เหมาะกับระบบ multi user ถ้ามีงบน้อย จะใช้ HD IDE ผมก็แนะนำให้ใช้ HD IDE 2 ตัวขึ้นไป สำหรับ กระจายงาน + backup กันเอง โดยทั่วไป ระบบที่เน้นความสเถียรภาพสูงๆ มักจะต้องทำ raid ด้วย เพราะข้อมูลสำคัญมากๆ พังไม่ได้เด็ดขาด
  5. Network Card ก็ควรใช้ของดีๆ โดยทั่วไป นิยมของดังๆ เช่น Intel, 3COM เอาแบบ 100 MBit ไปเลยครับ
  6. Apache ก็ลง mod เท่าที่จำเป็น เพราะจะได้ไม่อ้วนมาก เวลาแตก process เยอะๆ
  7. Optimized WebserServer เท่าที่จะทำได้เช่น ลง Zend Optimizer/Accerator , mod_gzip, phpa (Cache), etc
  8. หมั่น Upgrade Apache บ่อยๆ เพราะรุ่นใหม่ๆ มักจะทำงานและมี security ดีกว่ารุ่นก่าๆ
  9. อย่าลืมว่า mysql (database server) ก็กินแรงเครื่องค่อนข้างเยอะเหมือนกัน ถ้ามีงบพอ อาจจะแยกเป็น database server ต่างหาก ลงแต่ mysql อย่างเดียวไปเลย (spec เครื่องปานกลาง)
  10. mysql บางรุ่น มีปัญหา+bug เช่น connection เต็มบ่อย และไม่คืนให้ ต้อง reboot เครื่องบ่อย ดังนั้น ต้องหมั่น upgrade อีก
  11. บริหาร logs ไฟล์ ให้ดี โดยแยกให้เขียนลงคนละ mount volume หรือคนละ HD กัน เพราะลดการทำงานของ IO และ หมั่นลบ หรือ rotate log ไฟล์ เพราะถ้า logไฟล์โตมากๆ จะทำให้การอ่านเขียนช้าลงไปเยอะ ส่งผลต่อความเร็วโดยรวม ซึ่งส่งผลให้การทำงานหลักๆ ล่มได้ง่าย
  12. โดยหน้าที่ของ web admin/system admin คือ หมั่นศึกษา สังเกตุ และหาความรู้ในเรื่องที่เกี่ยวข้องอยู่เสมอ เพื่อให้ระบบทำงานได้เต็มประสิทธิภาพ และ มีปัญหาน้อยๆ
  13. ควร ติดตามข่าวสาร และ upgrade ระบบบ่อยๆ โดยเฉพาะปัญหา security
  14. email server ให้ระวังการโดนแอบใช้เป็น spam gateway และพยายามหลีกเลี่ยงการให้บริการ smtp แก่บุคคลภายนอก ซึ่งอาจทำได้ โดยการ lock ip หรือ ใช้การทำการตรวจสอบ password ก่อนส่ง
  15. กำหนด Firewalls ป้องกันการกระหน่ำ ping icmp /DDOS ซึ่งทำให้ระบบล่มได้

สาเหตุที่ webserver ทั่วไปๆ จะทำงานช้า อืด ไม่ได้ดังใจเจ้าของเวปทั้งหลาย ก็มีสาเหตุหลักๆ ไม่กี่อย่าง คือ

  1. webserver ตอบสนองไม่ทัน request process และ มี process ค้างในระบบมากมาย ทำให้ process ใหม่ๆ ที่ร้องขอเข้ามา ต้องรอเข้าคิว (ทำให้รู้สึกช้า) เพราะ server ระบายงานไม่ทัน
    • ถ้าพูดถึง load หนักๆ แน่นอนว่า อุปกรณ์ที่ใช้ ก็ต้องทนทานอย่างหนาตราช้าง ไม่งั้น ไม่กี่ยกก็จอดครับ โดยเฉพาะ harddisk และไฟล์ขนาดใหญ่ ควรจะหนัก harddisk มากกว่านะครับ เพราะ cpu ทำหน้าที่คำนวณ ไม่ได้ทำหน้าที่เขียนอ่านไฟล์
    • หน่วยความจำที่ต้องเผื่อไว้สำหรับ process httpd จำนวนมากๆ นั้น ต้องมีให้เพียงพอ ผมไม่เคยเห็น webserver ที่รองรับงานหนักๆ ตัวไหน มีแรมน้อยกว่า 512 MB นอกจากว่า เวปนั้น จะมี "hello" คำเดียว แบบนั้นเอาแรม แค่ 64 MB ก็พอไหวครับ เร็วสุดยอด ไม่เชื่อลองดู 555
    • การที่มี process ล้นระบบ พวก script ไม่ทำการย่อ code เลย
    • การใช้ process จนหน่วยความจำไม่พอ (ต้องรอ process เก่าๆ เสร็จงานก่อน)
    • แต่ละ process กินเวลานาน อาจเป็นเพราะ scritp ทำงานเยอะ+ช้า และ ไม่ optimized code ทางออกคือ ปรับเปลียน script ให้ทำงานได้เร็วขึ้น เช่น เปลี่ยน compiler เป็น php, servlet , etc (perl ไม่เหมาะกับงานหนักๆ เยอะๆ ยกเว้น mod_perl อันนี้เร็วสุดยอด แต่เขียนยาก) ควบคู่ไปกับการบริหารหน่วยความจำในข้อ1เพราะ cgi script ทั้งหลาย ที่คือ ตัวดี ที่ทำให้ CPU ทำงานมาก และเมื่อมีการ execute script มากๆ ระบบก็ทำงานหนักมากขึ้น ทั้ง cpu, ram , harddisk , io  และ script สองสามบรรทัด ที่เขียนผิดพลาดหรือจงใจก็แล้วแต่ ก็ทำให้ server  อืดได้นะครับ อย่าประมาท มีตัวอย่างให้เห็นมาบ่อยๆ  ใครยังจำได้ว่า สมัยที่มีคนแกะ script 152 และดันเขียน loop พลาด ทำเอา server ตัวเองล่มกันมาเยอะแล้ว
    • optimized การใช้งานฐานข้อมูล งานบางอย่าง ถ้า insert ฐานข้อมูลหนักๆ ถี่ๆ ก็ทำให้ระบบช้าลงมากก และระบบรวนไปเลยก็มี ดังนั้น ถ้านำ text ไฟล์มาช่วยเบาภาระได้บ้าง ก็จะดีขึ้นมาก
    • เร่งความเร็วของ script โดยใช้ engine ช่วย เช่น mod_perl, Zend Engine, Cache Engine, etc
  2. internet link ความเร็วต่ำ ระบาย bandwidth ได้น้อย จึงทำให้เกิดความคับคั่งของจราจรข้อมูล (รถติดนั่นแหละ) อันนี้เป็นปัญหาโลกแตก แก้ยาก และเปลืองเงินมาก นอกจากจะย้ายไปอยู่กับ data center ที่มี bandwidth มากๆ แทน
    • แก้ปัญหาเบื้องต้นในระบบเดิม ด้วยตนเอง โดยการบีบอัดข้อมูล เช่น ติดตั้ง mod_gzip เพื่อบับอีด text/html ได้ถึง 80% เพื่อให้กิน bandwidth น้อยลง และจะทำให้ client รู้สึกว่าเร็วขึ้นมาก เนื่องจากความคับคั่งของจราจรลดลง
    • เพิ่ม link bandwidth หรือ ย้าย ISP หรือ data center อันนี้ งบใครงบมันครับ แต่จะบอกว่า ต่อให้ server แรงสุดยอดแค่ไหน ถ้า link ช้า ทำยังไง ก็ไม่เร็วครับ เพราะมันคอขวดอยู่ตรงนั้น เหมือนเอา รถ F1 ไปติดแหงก อยู่บนถนน นะแหละครับ
  3. เวปเพจมีขนาดใหญ่ เนื่องจากภาพกราฟิกเยอะ ทำให้ต้องส่งข้อมูลจำนวนมหาศาลเมื่อมี process ร้องขอมากๆ จึงเป็นสาเหตุหนึ่งที่ทำให้ระบบตอบสนองได้ช้าา ทางแก้คือ ต้องลดๆ + บีบอัด กราฟิกกันหน่อย และการเขียนอ่าน IO มากๆ มีผลทำให้ harddisk ตอบสนองได้ช้า โดยเฉพาะการ write ดังนั้น ถ้า IO ไม่ตอบสนอง ได้ดีพอ ก็มีผลต่อความเร็วโดยรวม และ อายุการใช้งานก็สั้นลงด้วยครับ

อ้างอิงมาจาก : http://www.cgitop.com/phpBB2/viewtopic.php?t=602