Concern สำคัญสำหรับ High Performance System

เกริ่นนำ
การออกแบบระบบที่ต้องมีคุณภาพด้าน ‘ประสิทธิภาพ’ (performance) มากๆ นั้น มีเป้าหมายสำคัญตามมุมมองของผู้ใช้ คือ ระบบต้องทำงานรวดเร็ว มีการตอบสนอง (response) ที่รวดเร็ว ส่งผลให้การจัดการคุณภาพด้านประสิทธิภาพต้องมีเป้าหมาย (architectural goal) หรือตัวชี้วัด (response measure) ที่สำคัญหลักคือ การทำให้ค่า latency time และ response time สั้นที่สุด ซึ่งในความเป็นจริงตัวชี้วัดด้านประสิทธิภาพสามารถมีได้มากกว่านี้อีก เช่น throughput (ปริมาณที่ได้รับต่อการประมวลผล), jitter (ความคลาดเคลื่อน), miss rate (อัตราการประมวลผลผิดพลาด), data loss (การสูญเสียข้อมูลระหว่างประมวลผล) เป็นต้น โดยหัวใจสำคัญในการจัดการประสิทธิภาพของระบบ คือ การมุ่งเน้นจัดการกับ 2 ประเด็นหลัก ได้แก่
1. จุดที่มีการประมวลผล
2. จุดที่มีการใช้ทรัพยากร

จุดที่มีการประมวลผล (Computation)
หมายถึงจุดต่างๆ ภายในบริบทของระบบ (system context) ที่สามารถเกิดการประมวลผลได้ทั้งระดับฮาร์ดแวร์และซอฟต์แวร์
– การประมวลผลของฮาร์ดแวร์ อาทิเช่น การประมวลผลการอ่านข้อมูลของดิสก์, การประมวลผลชุดคำสั่งของซีพียู, การประมวลผลการรับ-ส่งข้อมูลบนบัสภายในเครื่อง, การประมวลผลการจัดการ cache ในหน่วยความจำ, การประมวลผลการจัดเก็บและอ่านข้อมูลของหน่วยความจำ
– การประมวลผลของซอฟต์แวร์ อาทิเช่น การประมวลผล request และความปลอดภัยของไฟร์วอลล์, การประมวลผลการ dispatch request และ scheduling ของโหลดบาลานเซอร์, การประมวลผลการจัดการ request และ response ของเว็บเซิร์ฟเวอร์, การประมวลผลคำสั่ง SQL, locking และการจัดการเซสชั่นของดาต้าเบสเซิร์ฟเวอร์, การประมวลผลการ swap in-swap out ของระบบปฏิบัติการ, การประมวลผลทรานแซกชั่นของระบบ, การประมวลผล thread และการซิงโครไนซ์ของแอพพลิเคชั่นเซิร์ฟเวอร์, การประมวลผลของคอมโพเน้นต์และอ็อบเจ็คต์ต่างๆ ในระบบ ซึ่งเจาะลงลงไปถึงการประมวลผลของอัลกอริธึมในเมธอดในอ็อบเจ็คต์ หรือลึกถึงระดับ statement ของโค้ดเลยก็ยังได้

จุดที่มีการใช้ทรัพยากร (Resource Consumption)
หมายถึงจุดต่างๆ ภายในบริบทของระบบที่เมื่อเกิดการประมวลผลขึ้น ทำให้เกิดการใช้ทรัพยากรต่างๆ ตามมา
คุณลักษณะของ Resource คือ ประโยชน์ใช้สอย (utility), ปริมาณ (quantity) ที่แสดงถึงการมีอยู่ (availability) ของ resource และการถูกใช้ (consumption)
ในทางไอที resource คือ ทรัพยากรที่ถูกใช้ (consumption) โดยระบบหรือมีผลต่อคุณภาพของระบบ (impact)
Resource สามารถเป็นอะไรก็ได้มากมาย เช่น น้ำ, ไฟ, แอร์, ตู้แร็ก, ปลั๊กไฟ, เอกสาร, ไฟล์, คน, ซีพียู, หน่วยความจำ, I/O, ฮาร์ดดิสก์, อ็อบเจ็คต์, เครือข่าย, session, database, directory server, message queue server เป็นต้น

ประเภททรัพยากร (ขอจัดประเภทเพื่อให้เข้ากับงานไอที) มีดังนี้

  • IT Resources
    • Potential Resources – เช่น ซีพียู, หน่วยความจำ, I/O, ฮาร์ดดิสก์
    • Stock Resources – คือทรัพยากรที่มีการสำรองจัดเก็บไว้
    • Reserved Resources – คือทรัพยากรที่ถูกจองไว้ เช่น สำหรับระบบหรืออุปกรณ์ต่างๆ
    • Actual Resources – คือทรัพยากรที่มี(เหลือ)อยู่จริง ณ ขณะเวลานั้นๆ
    • Renewable Resources – คือทรัพยากรที่สร้างได้ใหม่ เช่น DB Connection
    • Non-Renewable Resources – คือทรัพยากรที่ใช้แล้วหมดไปสร้างใหม่หรือสร้างเพิ่มเติมไม่ได้ ในกรณียังไม่ได้อัพเกรด เช่น ซีพียู, หน่วยความจำ, DB Connection ที่มีปริมาณเต็มตามค่า maximum connection ใน DB Connection Pool แล้ว
    • Reusable Resources – คือทรัพยากรที่ reuse ได้ มีลำดับคือ acquire -> use -> release เช่น หน่วยความจำ
    • Non-Reusable Resources – คือทรัพยากรที่ reuse ไม่ได้ เช่น เวลา หรือ processing time
    • Single Access Resources หรือ Exclusive Resources – คือทรัพยากรที่ถูกเข้าถึงโดย 1 ไคลเอ็นต์ หรือ transaction สามารถเป็นทั้ง reusable หรือ non-reusable resources ก็ได้
    • Concurrently Access Resources – คือทรัพยากรที่ถูกเข้าถึงโดยมากกว่า 1 ไคลเอ็นต์ หรือ transaction พร้อมๆ กัน
  • Human Resources คือ ทรัพยากรมนุษย์ เช่น จำนวนคนและจำนวนเวลา/คนที่ใช้โปรแกรมเพื่อประมวลผลระบบ
  • Tangible Resources เช่น ซีพียู, หน่วยความจำ, I/O, ฮาร์ดดิสก์, อุปกรณ์เครือข่าย
  • Intangible Resources เช่น สิทธิบัตร, ไลเซนส์ซอฟต์แวร์, ทรัพย์สินทางปัญญา

การประมวลผลของระบบจะเกิดขึ้นได้เมื่อมี event เกิดขึ้น ซึ่ง event ก็คือเหตุการณ์ที่มี request จากไคลเอ็นต์ส่งเข้ามายังระบบนั่นเอง คราวนี้ event มันก็เกิดได้หลายแบบ โดยทั่วไปมี 3 แบบ ได้แก่ periodic event คือ เหตุการณ์ที่เกิดเป็นประจำ แน่นอน (คาดการณ์ได้ง่าย-บริหารทรัพยากรง่าย) sporadic event คือ เหตุการณ์ที่เกิดขึ้นเป็นช่วงๆ เป็นระยะๆ นานๆ ครั้ง (คาดการณ์เริ่มยาก-บริหารทรัพยากรเริ่มยาก) และ stochastic event คือ เหตุการณ์ที่เกิดขึ้นแบบไม่แน่นอน เดี๋ยวถี่ เดี๋ยวไม่ถี่ เอาแน่เอานอนไม่ได้ เช่น หน้าจอนี้บางวันผู้ใช้ก็เยอะ บางทีก็ไม่มีใครใช้เลยติดกันหลายวัน (คาดการณ์ยาก-บริหารทรัพยากรยาก) ดังนั้นหากไม่มี ‘incoming event’ มาจากไคลเอ็นต์ระบบมันก็ไม่ได้ทำอะไร เมื่อไม่ได้ทำอะไรก็ไม่มีการประมวลผล request ก็จะทำให้ไม่ต้องไปใช้ทรัพยากรอะไรนั่นเอง ด้วยเหตุนี้เราจึงต้องขวนขวาย-ควานหา-สืบเสาะให้ได้ว่า ‘พฤติกรรมของไคลเอ็นต์’ หรือในศัพท์การตลาดเรียกว่า ‘customer behavior’ เป็นอย่างไร

ปัจจัยด้านพฤติกรรมไคลเอ็นต์นั้นสำคัญมาก หลายคนมากมองข้าม (โดยเฉพาะตอนเก็บ requirement และมาคิดได้ตอนระบบเริ่มใช้หรือตอนทำ performance test ช่วงใกล้ปิดโครงการ) สำหรับไคลเอ็นต์ของระบบไอทีสามารถเป็น คน ระบบ และอุปกรณ์ แต่โดยมากมักเริ่มจากคนก่อน ทีมพัฒนาจำนวนมากมักเก็บ requirement แค่ว่าระบบนี้มีผู้ใช้ทั้งหมดเท่าไร วันละเท่าไร… แค่นี้ไม่พอ (ซึ่งหลักสำคัญของการเก็บ requirement หนึ่งคือต้องระบุไคลเอ็นต์และจัดจำแนกก่อน แล้วค่อยไปเก็บพวก functional requirement หรือ use case) เช่นต้องเก็บว่า:
– ผู้ใช้แบ่งเป็นกี่ประเภท กี่กลุ่ม กี่บทบาท ใช้เกณฑ์ใดจำแนก
– ผู้ใช้แต่ละประเภทมีจำนวนทั้งหมดกี่คน เข้ามาใช้ระบบในช่วงเวลาใดบ้างในหนึ่งวัน ในแต่ละชั่วโมงในแต่ละวันมีจำนวนประมาณกี่คน เช่น 7.00-8.00 มีกี่คน 8.00-9.00 มีกี่คน
– ในแต่ละชั่วโมงหรือในแต่ละวัน (หากซีเรียสเรื่องประสิทธิภาพมากๆๆๆ ให้เล่นที่ระดับชั่วโมง อย่าเกินชั่วโมง เกินชั่วโมงถือว่ากว้างเกินไป) มักเข้ามาใช้หน้าจออะไร มักคลิ้กปุ่มไหน เมนูไหน ใช้เวลากับแต่ละหน้าจอประมาณกี่นาที เป็นต้น…. ซึ่งตรงนี้นี่ล่ะที่คุณภาพด้าน usability จะสำคัญและมีผล (impact) ต่อคุณภาพด้านประสิทธิภาพอย่างมาก และหากสงสัยว่า..อ้าวหน้าจอยังไม่ได้ออกแบบเลย โปรแกรมก็ยังไม่ได้เขียนจะทำได้ไง? เมื่อ…ระบบยังไม่มี? ยังไม่ได้พัฒนา ยังทำไม่เสร็จเลย ผู้ใช้แต่ละประเภทจะมีชั่วโมงละกี่คน? เข้ามาทำอะไรกันบ้าง? ฯลฯ ให้ลองไปค้นคว้าเพิ่มเติมเกี่ยวกับ Architecture Evaluation และ Test-Driven Development…อย่ารอให้สร้างบ้านใกล้เสร็จแล้วค่อยหาวิธีจัดการประสิทธิภาพระบบครับ แต่ทั้งนี้ทั้งนั้นขอแนะนำเทคนิคที่สามารถหยิบยืมมาจากวงการการตลาดได้นั่นคือ การทำสำรวจ หรือ research นั่นเอง…

ในหลักการตลาดมักต้องทำการสำรวจตลาด (market research) เพื่อวิเคราะห์พฤติกรรมและความต้องการของผู้บริโภค ซึ่งในวงการการผลิตสินค้าไหนๆ เขาก็นิยมทำกัน โดยจ้างพวกบริษัทเอเจนซี่โฆษณา สำนักโพลล์ สำนักสำรวจวิจัยต่างๆ ทำกัน จะมีก็แต่วงการไอทีที่นักไอทีนิยม ‘ดื้อ’ ชอบทำอะไรเองไปเสียหมด และมักมีวิธีคิดและวิธีปฏิบัติเป็นแบบ inside-out จึงมักมองที่ระบบออกไปหาผู้ใช้ (คิดถึงระบบก่อนคิดถึงผู้ใช้) แต่นักการตลาดมักคิดถึงลูกค้าก่อนแล้วค่อยคิดถึงผลิตภัณฑ์ ผมสอนหนังสือและให้คำปรึกษาเกี่ยวกับ Requirements Engineering ด้วย มักแทรกเทคนิคและแง่คิดด้านการตลาดเข้าไปให้กับผู้เรียนและลูกค้าเสมอ เพราะการทำ requirement ผู้รับผิดชอบควรมีพื้นฐานด้านการตลาดด้วยจะยิ่งดี โดยเฉพาะการทำสำรวจนี่ล่ะ… (จริงๆ หลักสูตรวิทยาการคอมพิวเตอร์และวิศวกรรมคอมพิวเตอร์ในหลายสถาบันก็มักมีวิชาเกี่ยวการทำสำรวจ เช่น ‘Operational Research’ ให้เรียนกันอยู่แล้วนะครับตั้งแต่ระดับปริญญาตรี ใครเคยเรียนมาแล้วลองย้อนเวลาไปทบทวนดู ใครที่ไม่เคยเรียนก็ศึกษาตอนนี้ยังไม่สาย) ทั้งนี้สำหรับพฤติกรรมของไคลเอ็นต์ยังช่วยสนับสนุนการทำประมาณการณ์ (forecast) เพื่อให้สามารถคาดการณ์ได้คร่าวๆ ว่าจะมี incoming event เป็นลักษณะใด, จะออกแบบส่วนต่างๆ ในระบบให้มีคุณภาพด้านประสิทธิภาพอย่างไร, จะกำหนดสเป็กของฮาร์ดแวร์และซอฟต์แวร์สนับสนุนต่างๆ อย่างไร แต่ถ้าเป็นโครงการที่มีฮาร์ดแวร์ เน็ตเวิร์กและซอฟต์แวร์สนับสนุนที่ชัดเจน เปลี่ยนแปลงไม่ได้หรืออัพเกรดไม่ได้…อันนี้ง่ายวิเคราะห์และคำนวณง่ายหน่อย แต่ถ้าเป็นโครงการที่อาจต้องมีการซื้อสิ่งเหล่านี้ก็จะทำให้ระดับความง่ายหล่นวูบลงไปได้

นอกจากนี้ก็อย่ารอให้มีระบบก่อนแล้วค่อยมาดู log จึงค่อยทราบพฤติกรรมผู้ใช้หรือไคลเอ็นต์ แล้วมาถึงตรงนี้คุณอาจสงสัยว่าแล้วจะรู้พฤติกรรมของผู้ใช้หรือไคลเอ็นต์ไปทำไมกัน? อ้าว!… อย่างที่กล่าวถึงก่อนหน้านี้ ก็หากไม่มีใครมาใช้ระบบ ระบบมันก็อยู่เฉยๆ เมื่อมันอยู่เฉยๆ มันก็ไม่ได้ประมวลผลอะไร เมื่อไม่ได้ประมวลผลหรือไม่ได้ทำอะไรมันก็ไม่ได้ไปใช้ทรัพยากรอะไรนักนั่นเอง แต่เมื่อมีไคลเอ็นต์มาใช้ระบบ ระบบก็เลยทำงาน เลยประมวลผล เลยใช้ทรัพยากร ดังนั้นเราจึงต้องทราบปริมาณ ประเภท และพฤติกรรมของผู้ใช้หรือไคลเอ็นต์ให้ได้ ยิ่งละเอียดยิ่งดี

โครงสร้าง ‘Path’ ในสถาปัตยกรรมระบบ
เราจะทราบว่ามีจุดใดที่มีการประมวลผลและใช้ทรัพยากรโดยเฉพาะเป็นจุดสำคัญที่มีผลต่อประสิทธิภาพของระบบมากๆ ควรทำความเข้าใจและวิเคราะห์กันตลอดทั้งห่วงโซ่ (chain) ของระบบ ตั้งแต่ต้นน้ำ (ไคลเอ็นต์) จนถึงปลายน้ำ (ระบบและทรัพยากรต่างๆ ที่ถูกใช้) ไล่กันตั้งแต่การเตรียม request บนฝั่งไคลเอ็นต์ จน request ถูกส่งออกมา ข้ามเน็ตเวิร์กมาจนถึงฝั่งเซิร์ฟเวอร์ ผ่านวิบากกรรมต่างๆ เช่น ไฟร์วอลล์ เว็บเซิร์ฟเวอร์ จนไปถึงระบบ ไปจนถึงทรัพยากรต่างๆ ที่ถูกใช้ เช่น ระบบภายนอก ระบบฐานข้อมูล เมล์เซิร์ฟเวอร์…

โดยการวิเคราะห์นี้ต้องสามารถเห็นภาพรวม เพราะจะทำให้เห็น path ของสถาปัตยกรรมของระบบ ว่ามี request จากไหนวิ่งเข้าสู่ระบบบ้าง ต้องผ่านอุปกรณ์ฮาร์ดแวร์และซอฟต์แวร์อะไรบ้าง ซึ่งอาจรวมไปถึง เลเยอร์, tier, คอมโพเน้นต์ ด้วย หากระบบมีความซับซ้อนมากอาจพบว่า path จะยิ่งซับซ้อนยุ่งเหยิงจนดูยาก (ให้นึกถึงถนนและตรอกซอกซอยในกรุงเทพฯ) จึงควรมองจากภาพกว้างๆ (abstract มากๆ) ก่อน แล้วค่อยซูมเจาะลึกลงไปในรายละเอียดเรื่อยๆ เช่น จากรูปที่ 1 เห็นได้ว่า request วิ่งผ่าน public network มาจนถึงไฟร์วอลล์ ก็ให้มองไฟร์วอลล์เป็น black box ไปก่อน ยังไม่ต้องเจาะลงไปดูว่าฮาร์ดแวร์ยี่ห้ออะไร รุ่นอะไร ซอฟต์แวร์ยี่ห้ออะไร เวอร์ชั่นอะไร มีโมดูลอะไรทำงานและเกี่ยวข้องกับ request บ้าง หรือจุดที่ request วิ่งผ่านไฟร์วอลล์ โหลดบาลานเซอร์ จนมาถึงเว็บเซิร์ฟเวอร์ ก็ยังไม่ต้องเจาะลงไปดูฮาร์ดแวร์และซอฟต์แวร์เช่นกัน ในการทำงานควรวาดรูปโมเดลของสถาปัตยกรรมระบบประกอบ เพื่อช่วยในการทำความเข้าใจและวิเคราะห์ได้ง่ายขึ้น

Attached Image
รูปที่ 1 (คลิ้กที่รูปเพื่อดูรูปขยาย)

เมื่อเห็นภาพรวมแล้วว่า request วิ่งออกจากฝั่งไคลเอ็นต์เข้าสู่ฝั่งเซิร์ฟเวอร์แล้วมี path ของการ call แตกตัวต่อไปอย่างไรภายในสภาพแวดล้อมของฝังเซิร์ฟเวอร์ ณ จุดนี้จะทำให้ทราบว่าในบริบทของระบบที่กำลังโฟกัสมีสภาพแวดล้อมอย่างไร ซึ่งหมายถึงมีทรัพยากรอะไรบ้างที่เกี่ยวข้องกับบริบทของระบบ ทั้งนี้บริบทของระบบอาจไม่จำเป็นต้องตรงกับบริบทการพัฒนา (development context) เสมอไป เช่น ทีม ก กำลังพัฒนาระบบการเงิน โดยต้องมีการเรียกใช้เซอร์วิสของระบบบัญชีที่พัฒนาโดยทีม ข บริบทการพัฒนานั้นทีม ก อาจไม่มีสิทธิไปก้าวก่ายสภาพแวดล้อมของระบบบัญชีของทีม ข ได้มากนัก แต่บริบทของระบบการเงินอาจมี indirect coupling กับระบบฐานข้อมูลที่ระบบบัญชีใช้ก็ได้ ซึ่งการวิเคราะห์ด้านประสิทธิภาพการประมวลผลและด้านการจัดการทรัพยากรของระบบการเงินจึงอาจขยายรวมระบบบัญชีและระบบฐานข้อมูลของระบบบัญชีเข้าด้วยก็ได้ ทั้งนี้ทั้งนั้นขึ้นกับ SLA (Service Level Agreement) และระเบียบอื่นๆ การพัฒนาอื่นๆ ด้วย

สิ่งที่ต้องทราบของแต่ละโหนด
จากรูปที่ 1 หากนับเฉพาะทรัพยากรของฝั่งเซิร์ฟเวอร์แล้ว โดยพิจารณาจากภาพกว้าง ดูที่แต่ละโหนด (node) ทรัพยากรหลักได้แก่ ไฟร์วอลล์ โหลดบาลานเซอร์ เว็บเซิร์ฟเวอร์ แอพพลิเคชั่นเซิร์ฟเวอร์ ระบบฐานข้อมูล Oracle เมล์เซิร์ฟเวอร์ ระบบบัญชี ระบบฐานข้อมูล DB2 และเน็ตเวิร์กที่เชื่อมต่อกับแต่ละโหนด โดยแต่ละโหนดเราจะต้องทราบว่า:
– ภายในมีการประมวลผลอะไรบ้าง และการประมวลผลใดที่มีผล (impact) ต่อประสิทธิภาพรวมของระบบ (ภายในขอบเขตบริบทของระบบ)
– อุปกรณ์ฮาร์ดแวร์ยี่ห้ออะไร รุ่นอะไร สเป็ก (specification) อะไร เป็นต้น
– มีการใช้ซอฟต์แวร์อะไรบ้าง ยี่ห้ออะไร เวอร์ชั่นอะไร ทำหน้าที่อะไร เป็นต้น
– ความสามารถในการทำงาน เช่น throughput ในการประมวลผล request
*ปกติแล้วทรัพยากรสำคัญของโหนดโดยทั่วไป หรือเครื่องคอมพิวเตอร์โดยทั่วไป ได้แก่ ซีพียู หน่วยความจำ ดิสก์ I/O

จากรูปที่ 1 จึงต้องวิเคราะห์แต่ละโหนด กรณีที่เป็นสิ่งที่มีอยู่แล้ว เช่น
– ไฟร์วอลล์ ต้องไปเก็บ requirement เกี่ยวกับไฟร์วอลล์มา สิ่งที่ต้องทราบ เช่น จำนวนเฉลี่ยของ request ที่ประมวลผลเสร็จต่อวินาที (เช่น 1,000 request/วินาที)
– โหลดบาลานเซอร์ สิ่งที่ต้องทราบ เช่น จำนวนเฉลี่ยของ request ที่ประมวลผลเสร็จต่อวินาที, scheduling algorithm ที่ใช้, ซอฟต์แวร์จัดการที่ใช้
– เน็ตเวิร์กระหว่างไฟร์วอลล์กับโหลดบาลานเซอร์ สิ่งที่ต้องทราบ เช่น แบนด์วิธเท่าไร ระยะห่างระหว่าง 2 โหนดนี้คือเท่าไร (เช่น กี่เมตร กี่กิโลเมตร เป็นต้น)
– แอพพลิเคชั่นเซิร์ฟเวอร์ สิ่งที่ต้องทราบ เช่น ฮาร์ดแวร์ยี่ห้ออะไร สเป็กอะไร (โดยเฉพาะ ซีพียู หน่วยความจำ ดิสก์ I/O) ระบบปฏิบัติการอะไร เวอร์ชั่นอะไร คอนฟิกุเรชั่นหน้าตาอย่างไร ซอฟต์แวร์แอพพลิเคชั่นเซิร์ฟเวอร์ยี่ห้ออะไร อิดิชั่นอะไร เวอร์ชั่นอะไร คอนฟิกุเรชั่นหน้าตาอย่างไร มีการ host แอพพลิเคชั่นอยู่กี่ระบบ ระบบอะไรบ้าง พฤติกรรมการใช้ทรัพยากรของระบบต่างๆ ที่มีอยู่แล้ว (ไม่ใช่ระบบใหม่ที่กำลังพัฒนา) บนแอพพลิเคชั่นเซิร์ฟเวอร์รวมถึงระบบปฏิบัติการมีพฤติกรรมการใช้ทรัพยากร (ซีพียู หน่วยความจำ ดิสก์ I/O) อย่างไร เช่น แต่ละระบบใข้ซีพียูเฉลี่ยกี่เปอร์เซ็นต์ต่อชั่วโมง (อยากทราบเฉลี่ยเป็นวินาทีก็หารด้วย 3,600) หากเครื่องนี้ทำงาน 24 ชั่วโมง แต่ระบบการเงินที่กำลังพัฒนาทำงานแค่ตอน 7.00 – 19.00 เท่านั้น ก็ต้องเก็บมาให้ได้ว่า แต่ละระบบดังกล่าวใช้ทรัพยากรเฉลี่ยในแต่ละชั่วโมงตั้งแต่ 7.00 – 19.00 เป็นอย่างไร (จะใช้ช่วงเป็นชั่วโมง นาที วินาที หรือเช้า-บ่ายยังไงก็ได้ ขึ้นกับดีกรีคุณภาพด้านประสิทธิภาพที่ระบบการเงินต้องการ หากต้องการประสิทธิภาพสูงๆ ก็เก็บที่ระดับนาทีหรือวินาทีไปเลย แต่แนะนำว่าไม่ควรเกินระดับชั่วโมง) เช่น เวลา 7.00-8.00 แต่ละระบบใช้หน่วยความจำเฉลี่ยกี่เม็กกะไบต์

เพราะเมื่อทราบว่าแต่ละระบบมีพฤติกรรมการใช้ทรัพยากรภายในโหนด (ภายในเครื่อง) เป็นอย่างไร ก็จะนำมาคำนวณได้ว่า โดยรวมทุกระบบบนโหนดใช้ทรัพยากรเฉลี่ยเท่าไร แล้วนำมาหักลบก็จะทราบว่าโหนดมีทรัพยากร ‘เหลือ’ เท่าไร เช่น มีซีพียูเหลือเฉลี่ยกี่เปอร์เซ็นต์เวลา 9.00-10.00 มีหน่วยความจำเหลือเฉลี่ยกี่กิกะไบต์เวลา 16.00-17.00 เป็นต้น

ด้านเน็ตเวิร์กก็เช่นกัน ต้องทราบว่ามีแบนด์วิธเท่าไร มีปริมาณการใช้งานเท่าไร เหลือเฉลี่ยต่อชั่วโมง นาที วินาที…เท่าไร ตลกร้ายที่มักเจอได้บ่อยในองค์กรใหญ่ๆ และคนชอบชี้โม้ เช่น “เรามีเน็ตเวิร์ก 10 กิกะบิต” แต่เราเอาคำถามข้างต้นถามกลับไปว่า… “แล้วเหลือเฉลี่ยต่อชั่วโมง นาที วินาที…ล่ะเท่าไร?” หรือ “คุณมีแบนด์วิธเหลือให้ระบบเราเท่าไร?… ถนนเส้นใหญ่มีตั้ง 10 เลนแต่รถวิ่งกันแน่นเอี้ยดทุกเลนตลอดเวลามันก็ไร้ประโยชน์ รถจำนวนมากที่วิ่งเข้า-ออกระบบเราอาจต้องติดแหงกก็ได้ หนำซ้ำสิ่งที่พบเจอได้บ่อยในองค์กรที่ใช้เว็บเซอร์วิสและ ESB (Enterprise Service Bus) กันเยอะๆ นั่นคือบนถนนมีแต่รถบรรทุกและรถกระบะเต็มไปหมด (บางครั้งมีรถพ่วงด้วย) ซึ่งแต่ละคันมีคนขับคนเดียวและบรรทุกของไม่กี่ชิ้น!

จากตัวอย่างข้างต้นของไฟร์วอลล์ โหลดบาลานเซอร์ แอพพลิเคชั่นเซิร์ฟเวอร์ เป็นกรณีของ ‘สิ่งที่มีอยู่แล้ว’ ซึ่งเราต้องเก็บ requirement ให้ละเอียด ซึ่งมักพบได้บ่อยมากว่าคนเก็บ requirement มักไม่ได้เก็บพฤติกรรมการใช้ทรัพยากรด้วย เก็บแต่สเป็กของฮาร์ดแวร์และซอฟต์แวร์ เช่น เครื่องนี้มีซีพียู 2 ตัวเป็นแบบ dual core แต่ละตัวมีความเร็ว 2.0 GHz มีหน่วยความจำ DDR3 32 GB โดยมีความเร็วบัสที่ 1,333 MHz เป็นต้น การทราบว่ามีเท่าไหร่… ไม่เพียงพอ แต่ต้องทราบให้ได้ว่า…เหลือเท่าไหร่??? หรือเหลือเฉลี่ยต่อชั่วโมงหรือต่อนาทีเท่าไหร่?…กันไปเลย

คราวนี้มาถึงกรณีสิ่งที่ยังไม่มี นั่นก็คือระบบที่จะพัฒนา (จากรูปที่ 1 หมายถึงระบบการเงิน) หากเป็นระบบที่ต้องออกแบบและเขียนโปรแกรมขึ้นเองจากสเต็ปศูนย์ ไม่ใช่การนำซอฟต์แวร์แพ็กเกจมา customize นั่นหมายความว่าเราจะไม่สามารถทราบได้ว่าระบบใหม่นี้จะมีพฤติกรรมการใช้ทรัพยากรอย่างไร แต่โชคดีที่เราจะมี constraint จาก requirement ที่เก็บมาแล้วว่าแต่ละโหนดมีสเป็กอย่างไร มีทรัพยากรต่างๆ (โดยเฉพาะ ซีพียู หน่วยความจำ ดิสก์ I/O) เหลือเท่าไร นั่นหมายความว่าจะต้องออกแบบและพัฒนาระบบให้สามารถทำงานได้มีคุณภาพ (ด้านประสิทธิภาพ) ภายใต้ข้อจำกัดนี้

เป้าหมายหลักในการจัดการประสิทธิภาพ
กลับมาที่เป้าหมายของระบบที่ต้องการคุณภาพด้านประสิทธิภาพ หรือ performance กัน นั่นคือการทำให้ค่า latency time และ response time สั้นที่สุด
– latency time หมายถึง เวลาแฝง ซึ่งเกิดขึ้นได้ในหลายจุดทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ ซึ่งเจ้าเวลาแฝงนี้มีได้หลายชนิดขึ้นกับนำคำว่า latency ไปใช้กับเรื่องอะไร เพราะไม่จำเป็นต้องเป็นกับระบบไอทีเท่านั้น แต่สำหรับระบบไอทีโดยทั่วไปมักหมายถึง ระยะเวลาที่ request สูญเสียไปกับการรอเข้าใช้ทรัพยากรและอาการติดๆ ขัดๆ ระหว่างการใช้ทรัพยากร เช่น เมื่อ request มาถึงทรัพยากร (บันทึกเวลาครั้งที่หนึ่ง) แต่เข้าใช้ทรัพยากรไม่ได้เนื่องจากทรัพยากรไม่ว่างจึงต้องรอ พอทรัพยากรว่าง ตัว scheduler จะมาหยิบ request ไปใช้ทรัพยากร (บันทึกเวลาครั้งที่สองเมื่อ request ได้เข้าใช้ทรัพยากร) นำเวลาครั้งที่สองลบครั้งแรกก็จะได้ค่า latency time นั่นเอง ในที่นี้มีความหมายคล้ายคำว่า waiting time นั่นเอง เพียงแต่ว่าจากตัวอย่างจากรูปที่ 1 จะเห็นได้ว่าบริบทของระบบการเงินมีทรัพยากรที่เกี่ยวข้องจำนวนมาก โดยภายในแต่ละโหนดเองก็มีทรัพยากรย่อยๆ อยู่ ดังนั้น การประมวลผล 1 request จากไคลเอ็นต์ต้องใช้ทรัพยากรหลายประเภทและหลายตัวมาก ซึ่งอาจเกิด latency time ได้หลายจุดมากตามไปด้วยนั่นเอง

– response time หมายถึง ระยะเวลาที่อินพุตมาถึง (เช่น มาถึงระบบ) จนครบ (อินพุตต้องมาถึงจนครบก่อน เช่น ฟอร์มมี 4 ฟีลด์ ทั้ง 4 ฟีลด์ก็ต้องมาถึงจนครบหมดก่อน) จนถึงระยะเวลาที่ประมวลผลเสร็จจนเริ่มส่งเอ๊าต์พุตกลับไปให้ไคลเอ็นต์ (นับที่เริ่มส่ง ไม่ใช่ส่งจนส่งเสร็จหมด) ดูแล้วคล้ายกับเวลาการประมวลผล หรือ processing time แต่ต่างกัน โดย processing time เกิดขึ้นได้กับหลายส่วนภายในบริบทของระบบ ดูตัวอย่างจากรูปที่ 2 สมมติว่าอินพุตของ request จากไคลเอ็นต์มาถึงระบบครบตอนวลา 8 โมงตรง อ็อบเจ็คต์แรกที่ทำงานคือ A โดย A ไปเรียก B และ B ไปเรียก C ซึ่ง C ใช้เวลาประมวลผล 1 วินาที B ประมวลผลต่อหลังจาก C เสร็จแล้ว โดยใช้เวลาประมวลผล 1 วินาที ดังนั้น response time ของ B เท่ากับ 2 วินาที แล้ว A ประมวลผลต่ออีก 1 วินาที ดังนั้น response time ของ A เท่ากับ 3 วินาที เมื่อ A ประมวลผลเสร็จระบบก็เริ่มส่งเอ๊าต์พุตตอนเวลา 8 โมง 3 วินาที ดังนั้น response time ของระบบเท่ากับ 3 วินาที

ตัวอย่างทรัพยากรภายในโหนดที่หลายคนมักมองข้าม หรือไม่เข้าใจถ่องแท้ อาทิเช่น pool, cache, process & thread, session, หลักการทำงานของซีพียู, หน่วยความจำ, ดิสก์, I/O เป็นต้น
ตัวอย่างกลไกการประมวลผลภายในบริบทของระบบที่หลายคนมักมองข้าม หรือไม่เข้าใจถ่องแท้ อาทิเช่น กลไกการจัดการ session, I/O, cache, pool, synchronization, multi-process, multi-thread, exception, encrypt-decrypt, redundancy, single sign-on, transaction, resource life-cycle, data access, object-to-relational mapping, locking, mail, messaging, distribution, backup & recovery, clustering, integration, transform/exchange/convert data, user experience, form, filtering, request & response, authentication & authorization เป็นต้น นอกจากนี้ยังรวมถึงการจัดวางเลเยอร์, tier, domain logic หรือ business logic ด้วย นอกจากนี้ยังต้องเข้าไปดูการทำงานภายในกลไกเหล่านี้อีกด้วยซึ่งก็จะแตกต่างกันไปตามประเภทกลไก แต่พื้นฐานการทำงานที่พบได้บ่อยว่ามักมีผลต่อประสิทธิภาพได้แก่ pool, cache, scheduling, thread, synchronization, resource life-cycle, locking, evict, data type, granularity, อัลกอริธึม เป็นต้น

อาการมองข้าม หรือไม่เข้าใจถ่องแท้ ส่งผลต่อการคอนฟิกฯ การทดสอบ (test) การจูน (tuning) โดยตรง!

Attached Image
รูปที่ 2 (คลิ้กที่รูปเพื่อดูรูปขยาย)

จากรูปที่ 1 สมมติว่าระบบการเงินคือระบบใหม่ที่จะ host อยู่บนแอพพลิเคชั่นเซิร์ฟเวอร์ ภายในระบบการเงินหรือระบบทั่วไปก็มักประกอบด้วยระบบย่อยจำนวนมาก แต่ละระบบย่อยก็ประกอบด้วยอ็อบเจ็คต์ต่างๆ ซึ่งหมายถึงการประกอบกันเป็นชั้นๆ ซึ่งไม่ว่าจะพัฒนาด้วย Object-Orientation หรือไม่ก็ตาม โดยหากย่อยกันไปจนถึงที่สุดแล้วนั่นอาจหมายถึงระดับ statement ของโค้ดกันเลยทีเดียว เพราะแต่ละ statement ก็ต้องมีการประมวลผลและใช้ทรัพยากร ดังนั้นสถาปนิกจึงต้องกำหนดขอบเขต (boundary) และระดับชั้น (hierarchy) ให้ชัดเจนในระหว่างออกแบบ ไม่จำเป็นต้องทำละเอียดจนถึงระดับ statement ของโค้ดเพราะจะเกินขอบเขตของงานสถาปัตยกรรมและงานออกแบบ ทั้งนี้โดยธรรมชาติการทำงานของหน่วยย่อย (เช่น อ็อบเจ็คต์ module หรือ subsystem) จะมีการประมวลผลและการใช้ทรัพยากรอยู่แล้ว การออกแบบจึงต้องมุ่งเน้นควบคุมการประมวลผลและการใช้ทรัพยากรให้มีประสิทธิภาพสูงสุด หรือให้มี latency time และ response time สั้นที่สุดเท่าที่จะทำได้นั่นเอง

ตัวอย่างเช่น ระบบฐานข้อมูล Oracle ที่ระบบการเงินใช้ รองรับ request ได้สูงสุดคือ 500 request/วินาที ขณะที่เมื่อใช้งานระบบจริงจะมี request เข้ามาพร้อมกันถึง 1,000 request/วินาที จะทำให้ มี request ที่ต้องรอถึง 50 เปอร์เซ็นต์ในทุกๆ วินาที ซึ่งจะนำไปสู่ปัญหาคอขวดและอาจลามจนทำให้ระบบล้มเหลว (failure) หรือล่ม (down) ได้

อีกตัวอย่างเช่น ระบบการเงินมีทรานแซกชั่นเฉลี่ย 50 ทรานแซกชั่น/วินาที โดยทุกหนึ่งทรานแซกชั่นจะสร้าง 1 database connection แล้วส่งคำสั่ง SQL ไปยัง Oracle จากนั้นจึงปิด database connection โดยการติดต่อกับ Oracle ของทุก 50 ทรานแซกชั่นเป็นการทำงานแบบ sequential ประมวลผลทีละทรานแซกชั่นไปเรื่อยๆ ซึ่งส่งผลต่อประสิทธิภาพของระบบและอาจนำไปสู่ปัญหาได้เช่นกัน

จากสองตัวอย่างนี้จะเห็นได้ว่าเป็นปัญหาต่อคุณภาพด้านประสิทธิภาพโดยตรงแน่ๆ นอกจากนี้ยังมีปัจจัยอีกมากมายที่สามารถส่งผลต่อประสิทธิภาพการประมวลผลและการใช้ทรัพยากรได้ อาทิเช่น ระดับ isolation level, รูปแบบการเซ็ต locking, การเลือกใช้ scheduling algorithm, การจัดการ life-cycle ของทรัพยากร, การจัดการการเข้าใช้ทรัพยากร, อัลกอริธึมการประมวลผล, ประสิทธิภาพของฮาร์ดแวร์, เวอร์ชั่นของซอฟต์แวร์, ค่าคอนฟิกุเรชั่นของฮาร์ดแวร์และซอฟต์แวร์, business process, คุณลักษณะทรานแซกชั่น, พฤติกรรมของผู้ใช้และไคลเอ็นต์ประเภทต่างๆ, พฤติกรรมของเซอร์วิสแต่ละประเภทและแต่ละเซอร์วิสภายในบริบทของระบบ เป็นต้น

ดังนั้นข้อสำคัญในการจัดการการประมวลผลใดๆ ให้มีประสิทธิภาพคือ การจะทำอย่างไรให้ประมวลผลแต่ละ request เสร็จเร็วๆ และหลักสำคัญในการใช้ทรัพยากรคือ ใช้ให้พอดีกับความจำเป็น และใช้ให้เสร็จเร็วๆ ซึ่งสถาปนิกจะต้องเข้าใจหลักอุปสงค์ (ความต้องการใช้ทรัพยากร) -อุปทาน (ทรัพยากรที่มีให้ใช้) เป็นอย่างดี เพราะทั้งสองสิ่งนี้ต้องสมดุลกัน (เรียกว่าจุด ‘ดุลยภาพ’ หรือ equilibrium) และต้องป้องกันไม่ให้เกิดสถานการณ์อุปสงค์มากกว่าอุปทานเด็ดขาด ยกเว้นว่าเป็นระยะเวลาสั้นๆ หลักที่ผมมักท่องเป็นประจำคือ ‘เข้าเร็ว-ใช้เร็ว-ออกเร็ว’ หรือผมมักเรียกอีกอย่างว่า ‘เข้าเร็ว-ล็อกเร็ว-ปลดล็อกเร็ว’ เพราะการใช้ทรัพยากรอาจเกิดการล็อก (lock) ทรัพยากรได้ หากล็อกนานไปจะไม่ดีกรณีที่มีโปรเซสอื่นรอเป็นจำนวนมาก

หลายคนมักเข้าใจว่าระบบที่มีประสิทธิภาพคือต้องเร็ว รับโหลดได้มากๆ ซึ่งก็ถือว่าไม่ผิด หากแต่ต้องทำความเข้าใจให้ละเอียดลึกซึ้งขึ้นว่าที่แท้แล้วประสิทธิภาพของระบบเกิดจากอะไร (การประมวลผลและการใช้ทรัพยากร) แล้วมีปัจจัยอะไรบ้างที่มีผลต่อประสิทธิภาพ (ผู้ใช้หรือไคลเอ็นต์ ทรัพยากรในโหนดและนอกโหนด ทรัพยากรที่ทีมพัฒนามีสิทธิเข้าถึงและที่ไม่มีสิทธิเข้าถึง คุณลักษณะของทรานแซกชั่น business process เลเยอร์ tier เป็นต้น) จากที่ได้อธิบายมาทั้งหมดนี้เป็นเพียงมโนทัศน์ (concept) กว้างๆ ขั้นพื้นฐาน ยังไม่ได้เจาะลึกในด้านเทคนิคนัก ซึ่งอยากฝากให้ผู้ที่สนใจลองศึกษาค้นคว้าเพิ่มเติมโดยเฉพาะเรื่องการจัดการการประมวลผล การจัดการการใช้ทรัพยากร และการทำความเข้าใจกับ latency time และ response time จากที่ได้อธิบายมาทั้งหมดเห็นได้ว่าระบบที่มีปัญหาด้านประสิทธิภาพสาเหตุมักเกิดตั้งแต่ตอนเก็บ requirement! จากประสบการณ์ส่วนตัวที่พบปะองค์กรมาจำนวนมากสาเหตุที่พบเป็นประจำคือคุณภาพของ requirement ที่ไม่มี…คุณภาพ!…และไม่เพียงพอ! ในเมื่อสาเหตุเกิดตั้งแต่ต้นน้ำ ไฉนเลยเรามักมาแก้กันที่ปลายน้ำ…แถมมักแก้กันด้วยเงินด้วย (ก็แก้กันที่ฮาร์ดแวร์กับเน็ตเวิร์กกันไง ฮา…) ลองประยุกต์แนวคิด Architecture Evaluation และ Test-Driven Development ดูสิครับ จัดการ requirement ให้ดีๆ มีกรอบ test case ให้ชัดเจน และออกแบบสถาปัตยกรรมให้ดีๆ สักหน่อยหนึ่งก่อน อย่าไปวัดใจกันตอนระบบใกล้เสร็จด้วยการทำ load test และอีกหลากหลายการทำ performance test เพราะถ้าเจอปัญหาแล้วสาเหตุอยู่ที่สถาปัตยกรรมหรือช่วงก่อนเขียนโค้ดหลัก… จะมีใครนั่งไทม์แมชชีนย้อนเวลากลับไปแก้ดีไซน์หรือ requirement กันไหม? ดังจะเห็นได้บ่อยๆ ว่าปัญหา ‘performance’ มักแก้ได้ด้วย ‘เงิน’! และอีกประการ constraint หลักในการพัฒนาระบบคือ ‘คน เงิน เวลา และความเสี่ยงทางธุรกิจ’ นอกจากทีมพัฒนาต้องเข้าใจแล้ว ฝั่งลูกค้าและผู้ใช้ก็ต้องยิ่งเข้าใจให้มากๆ ด้วยเช่นกัน ไม่ใช่ระบบงบฯ 5 แสนบาทจะเอาประสิทธิภาพระดับระบบ 5 สิบล้านบาท ดังนั้นเมื่อออกแบบระบบประมาณหนึ่งแล้ว เขียนโค้ดประมาณหนึ่งแล้ว ทดสอบประมาณหนึ่งแล้ว ทั้งสองฝ่ายจึงต้องมาสุมหัวหาจุดลงตัว (ลงรอย) กัน ด้วยการเจรจาต่อรองเพื่อประนีประนอมกัน เพราะก็ต้องเข้าใจด้วยกันทั้งคู่ว่าตอนช่วง requirement มันยังไม่มีระบบ จึงอาจระบุตัวชี้วัดด้านประสิทธิภาพระบบกว้างไปบ้าง แคบไปบ้างนั่นเอง

สำหรับเทคนิคในการวิเคราะห์ requirement และข้อมูลต่างๆ ประกอบการออกแบบระบบในลักษณะ high performance system รวมถึงเทคนิค (architectural tactics & patterns) ในการออกแบบในระดับสถาปัตยกรรม ไว้ผมจะมาเล่าสู่กันต่อไปในภายภาคหน้านะครับ :)

นอกจากนี้เรื่อง Granularity นั้นสำคัญมากๆๆๆ มีผลต่อประสิทธิภาพของระบบอย่างมาก เพราะมันบริโภคเนื้อที่บนหน่วยความจำและดิสก์เป็นอาหาร และใช้ I/O เป็นพาหนะหลัก หากจัดการ Granularity ไม่ดีก็อาจส่งผลต่อการประมวลผลของซีพียูได้เช่นกัน

เรื่อง Granularity นี้สถาปนิกหรือผู้ออกแบบต้องมีเข้าใจหลักพื้นฐานของภาษาโปรแกรมที่ใช้พัฒนาระบบเป็นอย่างดี อาทิเช่น ชนิดข้อมูล (data type) โดยเฉพาะเรื่อง mutable variable, immutable variable ขนาดของชนิดข้อมูลแต่ละชนิด, การ initialize (รวมทั้งการ construct & destroy), หลักการด้านอ็อบเจ็คต์, stream I/O ชนิดต่างๆ ไปจนถึงการแปลง (convert / cast) ค่าแบบต่างๆ และไปจนถึงโครงสร้างโปรแกรมพวก for, while, if,… นอกจากนี้ก็เกี่ยวกับวงจรชีวิตของทรัพยากร (resource life-cycle) และการเปลี่ยนสถานะ (state) ไปมาของทรัพยากรแต่ละประเภท เพราะมี Granularity มาเกี่ยวด้วยอย่างมาก เช่น วงจรชีวิตอย่าง construct->initialize->run->destroy หรือการเปลี่ยนสถานะอย่าง create->ready->run->idle->block->ready->run->destroy เป็นต้น ซึ่งทรัพยากรแต่ละประเภทอาจมีสิ่งเหล่านี้คล้ายหรือต่างกันออกไปบ้าง

อย่างที่ผมกล่าวเชิงอุปมาอุปไมยว่าองค์กรที่ใช้เว็บเซอร์วิสหลายแห่งมีรถบรรทุกวิ่งเต็มถนน ถนนก็เล็กนิดเดียว แต่รถบรรทุกมีคนขับแค่คนเดียว บรรทุกของก็แค่นิดเดียว… นี่ก็คือเรื่อง Granularity ดีๆ นี่เอง

ส่วน Isolation Lock ก็เป็นปัญหาประจำ เพราะมักเซ็ตไม่สอดคล้องกัน เช่น ระดับแอพพลิเคชั่นเซิร์ฟเวอร์เซ็ตจัดการแบบหนึ่ง ระดับดาต้าเบสเซ็ตจัดการแบบหนึ่ง ระดับดาต้าเบสคอนเน็กชั่นเซ็ตจัดการแบบหนึ่ง ก็ก่อให้เกิดปัญหาคอขวด dead-lock ได้ง่าย ทำให้มี latency สูงได้

การออกแบบทรานแซกชั่นที่ไม่เหมาะสม เช่น ชอบ begin ตั้งแต่เนิ่นๆ แล้วไป commit เอาตอนท้ายโน่น กลายเป็นทรานแซกชั่นที่มี Granularity ก้อนใหญ่มาก ก็เปลืองเซสชั่นอีก เพราะทรานแซกชั่นเซสชั่นก็คือเซสชั่นประเภทหนึ่ง ซึ่งอาศัยอยู่ในหน่วยความจำเป็นหลัก การมีทรานแซกชั่นก้อนโตๆ จำนวนมากก็เป็นสาเหตุของการเกิดคอขวดและ dead-lock ได้ รวมถึงสถาปนิกหรือผู้ออกแบบ และโปรแกรมเมอร์ที่ไม่เข้าใจ business process ก็จะทำให้ไม่เข้าแก่นส่งผลให้ออกแบบและเขียนโปรแกรมจัดการทรานแซกชั่นไม่เหมาะสมหรือไม่มีประสิทธิภาพได้ ประเด็นการออกแบบและเขียนโปรแกรมจัดการทรานแซกชั่นที่ไม่เหมาะสมก็เป็นสาเหตุนำไปสู่ปัญหาด้านประสิทธิภาพที่พบได้บ่อยมากๆ อีกเช่นกันนะครับ

ยังมีอีกหลายปัจจัยเลยที่ไม่ได้อธิบายและยกตัวอย่างละเอียดนัก แต่หากใครที่อ่านตั้งแต่จนจบได้ (เพราะยาวมาก :D) ก็น่าจะพอคลำทางได้ออกแล้ว ใครสนใจตรงไหน ติดตรงไหนปรึกษาสอบถามกันมาได้ครับ ยินดีครับ ไม่ต้องเกรงใจ ไม่ต้องมาจ้างกันหรอก ยกเว้นเคสใหญ่ๆ เนื้องานเยอะๆ ก็ค่อยว่ากัน :lol:

ผมมาเสริมเนื่องจากไม่อยากแก้ในเนื้อความหลัก เพราะเขียน draft เก็บเอาไว้สักพักใหญ่แล้ว เอามาลงให้ เห็นคุณ Bomber ถามถึง เลยนึกขึ้นได้ ตัวไฟนอลค่อยเอาไว้เรียบเรียงใหม่อีกทีภายหลัง ^_^

*สำหรับ business process, เลเยอร์ และ tier มีผลอย่างไรต่อประสิทธิภาพของระบบ ไว้มีโอกาสจะมาอธิบายต่อในภายภาคหน้าครับ :)

ณรงค์ จันทร์สร้อย
minimalist (๔ กันยายน พ.ศ. ๒๕๕๔)

ป.ล. หากอ่านแล้วงงๆ สงสัย อยากรู้พื้นฐานละเอียดขึ้น และอยากทราบเทคนิคการวิเคราะห์และออกแบบ ขอแนะนำหลักสูตร ‘Design Technique for High Performance System’ ที่ซอฟต์แวร์พาร์ค เป็น public training (จะได้ภาพกว้างๆ เหมาะแก่ผู้เริ่มต้น) หรือหากอยากรู้ลึกๆๆๆ ขึ้น และอยากทำได้เร็วๆ แนะนำจัดอบรมแบบ on-site training เพราะสามารถ customize เนื้อหา วัน เวลา และเวิร์กช็อปให้เข้ากับผู้เรียนและงาน (ระบบที่ทำอยู่) ได้ (ค่าใช้จ่ายต่อหัวต่ำกว่าโข จำนวนผู้เรียนรับได้เพียบกว่า) :D อิอิ หรือจะจัดแบบโค้ชชิ่งก็ได้นะเออ ขออนุญาตโฆษณาแฝงหน่อย :lol: เพราะเรื่องนี้สอนก็สนุก ทำก็สนุก ;)

Advertisements

One thought on “Concern สำคัญสำหรับ High Performance System

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s