on
เราคงจะเคยเห็นบ่อยๆว่า จองตั๋วอะไรที่ดังๆ อย่างที่เพิ่งมีการจองไป จนทำให้ระบบของเซเว่น ล่มกันไปเลยในวินาทีแรก ที่เปิดให้จอง
แล้วก็ในอดีต เช่นการจอง iphone ที่ก็ทำให้เว็ปจองของค่ายต่างๆล่ม รับไม่ไหว
อันที่จริง อาจจะหมายถึงเว็ปที่ต้องมีผู้ใช้งานค่อนข้างเยอะด้วย
อยากทราบว่า ปัญหาพวกนี้ จริงๆเกิดจากอะไร แล้วมีทางแก้ไขยังไงบ้าง ใช้เทคโนโลยีอะไร
หรือต้องมีการออกแบบระบบอย่างไร ควรใช้เทคนิคยังไง
และคุ้มค่ากับการลงทุนหรือไม่ มีค่าใช้จ่ายสูงแค่ไหน
ระบบคลาวอย่าง amazon สามารถช่วยได้แค่ไหนครับ ขอความเห็นหน่อยครับ
ในกรณีของ "เดี่ยว"
mr_tawan Sun, 17/02/2013 - 01:22
ในกรณีของ "เดี่ยว" ผมว่าระบบเมฆก็น่าจะช่วยในส่วนของ web app ตรงกลาง กระจายเป็นหลาย ๆ instance ดูแลผู้ใช้หลาย ๆ คนพร้อม ๆ กัน
ส่วน Database เองก็อาจจะออกแบบเป็น db server หลาย ๆ ตัว ดูแลเป็นตัวละรอบไปเลยก็น่าจะช่วยได้ (รันบน VM ก็ได้ จะได้ไม่ต้องใช้ HW มากมาย) ผมว่าถ้าเอา DB ตัวเดียวอาจจะเอาไม่อยู่ ไม่รู้นะครับ ไม่รู้ด้วยว่าถ้าทำเป็น distribute DB แล้วจะมีปัญหาอะไรบ้าง (น่าจะเรื่อง sync เรื่องนึงล่ะ)
หรือถ้าเป็นกรณี iPhone ก็อาจจะเป็นให้ DB Server มี quota จำนวนลูกค้าไปเลยส่วนหนึ่ง (สมมติว่าสัก 5000 เครื่องต่อ server) ถ้ามี server นึงเต็มโควต้าไปแล้ว ก็หยุดแล้วให้ server ตัวอื่นทำงานแทน ตอนที่ application พยายามเขียน db ก็สุ่มเอาว่าจะเขียนลง db server ตัวไหน วิธีจะมีปัญหาคือตอนอ่านข้อมูลขึ้นมา เพราะต้องไปรันหาข้อมูลในหลาย ๆ server แต่ก็ไม่เป็นไรมั้ง ยังไงเรื่องการเขียนน่าจะสำคัญกว่า (ผมไม่รู้ว่าถ้าใช้ Distributed DB แล้วจะมีวิธีการทำ load balance ลักษณะนี้หรือเปล่านะครับ อาจจะมีก็ได้)
ข้างบนที่ว่ามาผมจินตนาการณ์เอานะครับ ไม่เคยลองเองแม้แต่นิด ในความเป็นจริงมันอาจจะไม่เวิร์คก็ได้
เจ็บกันไปเยอะ พวก
adente Sun, 17/02/2013 - 02:08
เจ็บกันไปเยอะ พวก impactที่เดียวกันแบบนี้ ถ้าไม่มีประสบการณ์ก็ตายเรียบ
ถ้าจะให้ทำรองรับงานนี้
lancaster Sun, 17/02/2013 - 04:24
ถ้าจะให้ทำรองรับงานนี้ ค่าใช้จ่ายไม่สูงมากหรอกครับ ปริมาณไม่ได้เยอะขนาดนั้น
การทำงานกับข้อมูลแบบแบบ burst
McKay Sun, 17/02/2013 - 05:02
การทำงานกับข้อมูลแบบแบบ burst กับ database นี่ผมว่าจริงๆแล้วคอขวดด้านประสิทธิภาพหลักๆไม่ได้ติดที่ CPU/Network Controller เลย คือ request หลักหมื่นที่ไม่ได้มีการคำนวนเยอะๆเนี่ย CPU ในปัจจุบันรองรับได้ค่อนข้างสบาย
คอขวดหลักๆน่าจะมาจากปัญหาด้าน I/O มากกว่า (ซึ่งส่งผลกระทบโดยตรงกับการทำ locking) ควรทำการ optimize คำสั่งต่างๆ(Application/SQL)ให้ดีๆ อาจใช้งาน DB Engine แบบ MEMORY หรือใช้ DB Engine ที่ทำการ Lock ในระดับต่ำๆ เช่น InnoDB ที่ lock ในระดับ ROW จากนั้นก็ปรับ Buffer Pool ให้ค่อนข้างใหญ่ และ/หรือ เปลี่ยนมาใช้ SSD เพื่อลดคอขวดตรงนี้ พอหลังจาก request แบบ burst หมดก็สบายแล้วครับ โอนข้อมูลจาก MEMORY ลงฐานข้อมูลปกติ
ถ้าระบบล่มโดยใช้ memory db
bongikairu Sun, 17/02/2013 - 18:49
In reply to การทำงานกับข้อมูลแบบแบบ burst by McKay
ถ้าระบบล่มโดยใช้ memory db นี่น่าจะเสี่ยงหนักกว่าเดิมอีกนะครับ ผมว่า innodb ก็น่าจะ ok หละ
มันแล้วแต่ว่าระบบล่มนี่หมายถึ
McKay Sun, 17/02/2013 - 19:00
In reply to ถ้าระบบล่มโดยใช้ memory db by bongikairu
มันแล้วแต่ว่าระบบล่มนี่หมายถึงอะไรหน่ะครับ ถ้าหมายถึง response time สูงจนเกิด timeout MEMORY DB ก็ช่วยได้ ถ้าเกิดการ crash (ซึ่งผมว่าไม่น่าจะใช่) ก็เป็นผลเสียครับ
ล่ม
lancaster Sun, 17/02/2013 - 19:54
In reply to ถ้าระบบล่มโดยใช้ memory db by bongikairu
ล่ม ในความหมายของงานที่รับโหลดเยอะๆ มันไม่มีล่มเพราะแครชหรอกครับ มีแต่ล่มเพราะคนเข้าเยอะจัดเฉยๆ
ไม่เกิน 20k transaction/sec
kowito Sun, 17/02/2013 - 10:30
ไม่เกิน 20k transaction/sec Database ไม่มีปัญหาหรอกครับ
ร้านมีสองหมื่นสาขา ยังไงจองบัตรก็ต้องกรอกข้อมูล ไอ้เรื่องที่ Transaction เยอะจน Database ไม่ไหวไม่น่าใช่ อันนี้ต้องไปดูการออกแบบแล้ว ว่าทำยังไงให้ระบบล่มได้
ล่มยังกับระบบทะเบียนมหาลัย
Architec Sun, 17/02/2013 - 11:39
ล่มยังกับระบบทะเบียนมหาลัย เปิดไม่ถึงห้านาที ซัดไปสี่หมื่นคน/วิ ก็เดี้ยงละ
คุ้นๆว่าใช้ db
neonicus Sun, 17/02/2013 - 22:04
คุ้นๆว่าใช้ db เจ้าที่ไม่ค่อยดังในไทยครับ
มันล่มเพราะคนเข้าเยอะ
wichate Mon, 18/02/2013 - 15:35
มันล่มเพราะคนเข้าเยอะ ดังนั้นถ้าเป็นผมนะ ผมแยกการขายตั๋วแต่ระรอบ เป็น 1 รอบ/ 1ระบบ
ประมาณว่าแยก web app แยก Server แยก DB เป็น 1รอบ/1ชุด
ง่าย และจบโดยไม่ต้องคิดอะไรมากมาย (@_@)!
มันจะจบตอนยื่นงบประมาณนี่แหละ
McKay Mon, 18/02/2013 - 18:34
In reply to มันล่มเพราะคนเข้าเยอะ by wichate
มันจะจบตอนยื่นงบประมาณนี่แหละครับ - -"
server
mr_tawan Mon, 18/02/2013 - 19:09
In reply to มันล่มเพราะคนเข้าเยอะ by wichate
server ที่ทำงานกับรอบเสาร์-อาทิตย์ล่มหมดทุกตัว
วันพุธทำงานสบายใจเฉิบ (ไม่มีคนจอง)
แล้ว 1 รอบเนี่ย
PaPaSEK Mon, 18/02/2013 - 19:46
In reply to มันล่มเพราะคนเข้าเยอะ by wichate
แล้ว 1 รอบเนี่ย ใครมีสิทธิอยู่รอบแรกเหรอครับ แล้วจะจัดการยังไงให้คนไม่มาตะลุมบอนกันเป็นรอบแรก
คิดว่า รอบโชว์ นะ
mr_tawan Mon, 18/02/2013 - 22:40
In reply to แล้ว 1 รอบเนี่ย by PaPaSEK
คิดว่า รอบโชว์ นะ คงไม่ใช่ทุกคนที่อยากดูรอบแรก (ที่มักจะขลุกขลักและเละเทะที่สุด) กันหรอกครับ
ไปดูระบบใช้ขายตั๋ว olympic
erawat Tue, 19/02/2013 - 04:52
ไปดูระบบใช้ขายตั๋ว olympic ปีที่ผ่านมาสิครับ
อย่าเทียบกันเลยครับ อันนั้นทด
PaPaSEK Wed, 20/02/2013 - 12:19
In reply to ไปดูระบบใช้ขายตั๋ว olympic by erawat
อย่าเทียบกันเลยครับ
อันนั้นทดสอบกันเป็นระบบมากๆ ... ถึงขนาดเช่า cloud ของ Amazon มาช่วยกันถล่มเพื่อทดสอบ load กันเลยทีเดียว ผมอ่านแล้วชื่นชมในความเป็นมืออาชีพมากๆ ครับ
ใครไม่เคยอ่านลองอ่านดูนะครับ เบื้องหลังระบบไอทีของโอลิมปิก 2012 ที่กรุงลอนดอน การทดสอบเว็บไซต์จะอยู่ในหัวข้อเว็บไซต์ครับ แต่แนะนำให้อ่านทั้งหมดเพราะได้ความรู้ดีครับ
.. ความจำเปนเลิศ *O*/
tontpong Fri, 22/02/2013 - 18:03
In reply to อย่าเทียบกันเลยครับ อันนั้นทด by PaPaSEK
.. ความจำเปนเลิศ *O*/
มันเป็นความประทับใจครับ
PaPaSEK Fri, 22/02/2013 - 18:16
In reply to .. ความจำเปนเลิศ *O*/ by tontpong
มันเป็นความประทับใจครับ
นับแต่วันนั้น เมื่อแรกพบเธอ
tontpong Fri, 22/02/2013 - 18:31
In reply to มันเป็นความประทับใจครับ by PaPaSEK
นับแต่วันนั้น เมื่อแรกพบเธอ .. ;P