Tags:

เราคงจะเคยเห็นบ่อยๆว่า จองตั๋วอะไรที่ดังๆ อย่างที่เพิ่งมีการจองไป จนทำให้ระบบของเซเว่น ล่มกันไปเลยในวินาทีแรก ที่เปิดให้จอง
แล้วก็ในอดีต เช่นการจอง iphone ที่ก็ทำให้เว็ปจองของค่ายต่างๆล่ม รับไม่ไหว

อันที่จริง อาจจะหมายถึงเว็ปที่ต้องมีผู้ใช้งานค่อนข้างเยอะด้วย

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

Get latest news from Blognone
By: mr_tawan
ContributoriPhoneAndroidWindows
on 17 February 2013 - 01:22 #541779
mr_tawan's picture

ในกรณีของ "เดี่ยว" ผมว่าระบบเมฆก็น่าจะช่วยในส่วนของ 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 ลักษณะนี้หรือเปล่านะครับ อาจจะมีก็ได้)

ข้างบนที่ว่ามาผมจินตนาการณ์เอานะครับ ไม่เคยลองเองแม้แต่นิด ในความเป็นจริงมันอาจจะไม่เวิร์คก็ได้


  • 9tawan.net บล็อกส่วนตัวฮับ
By: adente
ContributorSUSESymbianWindows
on 17 February 2013 - 02:08 #541798
adente's picture

เจ็บกันไปเยอะ พวก impactที่เดียวกันแบบนี้ ถ้าไม่มีประสบการณ์ก็ตายเรียบ

By: lancaster
ContributorUbuntuWindows
on 17 February 2013 - 04:24 #541812

ถ้าจะให้ทำรองรับงานนี้ ค่าใช้จ่ายไม่สูงมากหรอกครับ ปริมาณไม่ได้เยอะขนาดนั้น

By: McKay
ContributorAndroidWindowsIn Love
on 17 February 2013 - 05:02 #541814
McKay's picture

การทำงานกับข้อมูลแบบแบบ 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 ลงฐานข้อมูลปกติ


In Soviet Warcraft, Argus comes to you.

By: bongikairu
ContributoriPhone
on 17 February 2013 - 18:49 #541932 Reply to:541814

ถ้าระบบล่มโดยใช้ memory db นี่น่าจะเสี่ยงหนักกว่าเดิมอีกนะครับ ผมว่า innodb ก็น่าจะ ok หละ


Gear's Edge the Blog

By: McKay
ContributorAndroidWindowsIn Love
on 17 February 2013 - 19:00 #541934 Reply to:541932
McKay's picture

มันแล้วแต่ว่าระบบล่มนี่หมายถึงอะไรหน่ะครับ ถ้าหมายถึง response time สูงจนเกิด timeout MEMORY DB ก็ช่วยได้ ถ้าเกิดการ crash (ซึ่งผมว่าไม่น่าจะใช่) ก็เป็นผลเสียครับ


In Soviet Warcraft, Argus comes to you.

By: lancaster
ContributorUbuntuWindows
on 17 February 2013 - 19:54 #541940 Reply to:541932

ล่ม ในความหมายของงานที่รับโหลดเยอะๆ มันไม่มีล่มเพราะแครชหรอกครับ มีแต่ล่มเพราะคนเข้าเยอะจัดเฉยๆ

By: kowito
Android
on 17 February 2013 - 10:30 #541843

ไม่เกิน 20k transaction/sec Database ไม่มีปัญหาหรอกครับ

ร้านมีสองหมื่นสาขา ยังไงจองบัตรก็ต้องกรอกข้อมูล ไอ้เรื่องที่ Transaction เยอะจน Database ไม่ไหวไม่น่าใช่ อันนี้ต้องไปดูการออกแบบแล้ว ว่าทำยังไงให้ระบบล่มได้

By: Architec
ContributorWindows PhoneAndroidWindows
on 17 February 2013 - 11:39 #541856

ล่มยังกับระบบทะเบียนมหาลัย เปิดไม่ถึงห้านาที ซัดไปสี่หมื่นคน/วิ ก็เดี้ยงละ

By: neonicus
Android
on 17 February 2013 - 22:04 #541953

คุ้นๆว่าใช้ db เจ้าที่ไม่ค่อยดังในไทยครับ

By: wichate
Android
on 18 February 2013 - 15:35 #542196

มันล่มเพราะคนเข้าเยอะ ดังนั้นถ้าเป็นผมนะ ผมแยกการขายตั๋วแต่ระรอบ เป็น 1 รอบ/ 1ระบบ

ประมาณว่าแยก web app แยก Server แยก DB เป็น 1รอบ/1ชุด

ง่าย และจบโดยไม่ต้องคิดอะไรมากมาย (@_@)!

By: McKay
ContributorAndroidWindowsIn Love
on 18 February 2013 - 18:34 #542249 Reply to:542196
McKay's picture

มันจะจบตอนยื่นงบประมาณนี่แหละครับ - -"


In Soviet Warcraft, Argus comes to you.

By: mr_tawan
ContributoriPhoneAndroidWindows
on 18 February 2013 - 19:09 #542273 Reply to:542196
mr_tawan's picture

server ที่ทำงานกับรอบเสาร์-อาทิตย์ล่มหมดทุกตัว

วันพุธทำงานสบายใจเฉิบ (ไม่มีคนจอง)


  • 9tawan.net บล็อกส่วนตัวฮับ
By: PaPaSEK
ContributorAndroidWindowsIn Love
on 18 February 2013 - 19:46 #542281 Reply to:542196
PaPaSEK's picture

แล้ว 1 รอบเนี่ย ใครมีสิทธิอยู่รอบแรกเหรอครับ แล้วจะจัดการยังไงให้คนไม่มาตะลุมบอนกันเป็นรอบแรก

By: mr_tawan
ContributoriPhoneAndroidWindows
on 18 February 2013 - 22:40 #542332 Reply to:542281
mr_tawan's picture

คิดว่า รอบโชว์ นะ คงไม่ใช่ทุกคนที่อยากดูรอบแรก (ที่มักจะขลุกขลักและเละเทะที่สุด) กันหรอกครับ


  • 9tawan.net บล็อกส่วนตัวฮับ
By: erawat
ContributoriPhoneAndroidBlackberry
on 19 February 2013 - 04:52 #542444

ไปดูระบบใช้ขายตั๋ว olympic ปีที่ผ่านมาสิครับ

By: PaPaSEK
ContributorAndroidWindowsIn Love
on 20 February 2013 - 12:19 #543104 Reply to:542444
PaPaSEK's picture

อย่าเทียบกันเลยครับ

อันนั้นทดสอบกันเป็นระบบมากๆ ... ถึงขนาดเช่า cloud ของ Amazon มาช่วยกันถล่มเพื่อทดสอบ load กันเลยทีเดียว ผมอ่านแล้วชื่นชมในความเป็นมืออาชีพมากๆ ครับ

ใครไม่เคยอ่านลองอ่านดูนะครับ เบื้องหลังระบบไอทีของโอลิมปิก 2012 ที่กรุงลอนดอน การทดสอบเว็บไซต์จะอยู่ในหัวข้อเว็บไซต์ครับ แต่แนะนำให้อ่านทั้งหมดเพราะได้ความรู้ดีครับ

By: tontpong
Contributor
on 22 February 2013 - 18:03 #544176 Reply to:543104

.. ความจำเปนเลิศ *O*/

By: PaPaSEK
ContributorAndroidWindowsIn Love
on 22 February 2013 - 18:16 #544187 Reply to:544176
PaPaSEK's picture

มันเป็นความประทับใจครับ

By: tontpong
Contributor
on 22 February 2013 - 18:31 #544204 Reply to:544187

นับแต่วันนั้น เมื่อแรกพบเธอ .. ;P