อาจยังพอมีทางที่จะ "รีดพลังซ่อนเร้น" ของระบบรองรับ gotoknow ได้ โดยยังไม่ต้องเพิ่ม servers ในเร็ววัน ถ้าทุกฝ่ายร่วมมือกัน ก่อนถึงจุดวิกฤติเดือนพฤษภาคม 2551 นี้

ประเด็นสืบเนื่องจาก

Pช่วยคิดช่วยทำ » ตัดหางปล่อยวัด gotoknow การคิดก่อนปล่อยหรือปล่อยให้คิดเอง

Pของขวัญจากวันวาน » อยากให้ G2K เป็นอย่างไร ?

Pnote by wwibul » ไร้สาระใน GotoKnow - ต้อง optimize ไม่ใช่ minimize

 

สรุปประเด็นหลักที่สำคัญ 

  • ปัจจุบัน ใช้ servers ราว 10 ตัวให้บริการ 
  • ภาระที่แท้จริงของระบบ คือ อัตราเร็วการอ่านข้อมูล ว่ามีการร้องขอมากเกินระดับวิกฤติไหม
  • อัตราเร็วการอ่านข้อมูล เกิดจาก pageview (จำนวนหน้าที่คลิ๊กเข้าอ่าน) ในช่วงเวลานั้น คูณด้วย pagesize (ขนาดเฉลี่ยต่อหน้า ปัจจุบันอยู่ที่ราว 0.3-0.4 MB)
  • ถ้าวัดภาระของระบบเครื่องที่บริการ gotoknow ด้วย pageview (จำนวนหน้าที่คลิกเข้าอ่าน) โดยถือว่า ทุกหน้าที่โหลดอ่าน มีขนาดเท่ากัน....
  • สถิติของ gotoknow ในปีที่ผ่านมา pageview เพิ่มเป็น 2.35 เท่าต่อปี (ใช้ตัวเลขสถิติจากทรูฮิตส์)
  • สถิติล่าสุด อยู่ที่ราว 4 ล้าน pageview/เดือน
  • คุณ Conductor คาดว่า จุดวิกฤติ จะอยู่ที่ 5.586 ล้าน pageview/เดือน
  • ด้วยอัตราการเติบโตระดับนี้ ผมคาดว่าระบบ server ของ gotoknow จะตึงตัวสุดขีด ไปแตะระดับวิกฤติที่คุณ conductor คาดไว้ คงราว ๆ กลางพฤษภาคม 2551 เป็นอย่างเร็ว กลางมิถุนายน 2551 เป็นอย่างช้า 
  • ต้องมีการปรับตัวครั้งใหญ่ (อีกครั้ง) ให้เสร็จในเดือนเมษายน 2551 ระบบจึงจะไม่สะดุด 

ทางแก้ที่(ดูเหมือน)ง่าย คือ เพิ่ม servers ("อีก" !)

แต่ตัวเลขที่น่าตกใจกว่าคือ การเพิ่ม server 1 ตัว ก็ยืดเวลาไปได้อย่างมาก ก็ 2-3 เดือน ไม่เกินนั้น

(เว้นแต่ server ใหม่ ซิ่งแรงสุด ๆ เกินสมรรถนะของ server เก่าไม่เห็นฝุ่น)

แต่ ยอดเงินสมทบทุนกองทุน Gotoknow ณ วันที่ 28 ธันวาคม 2550 รวมทั้งสิ้น 105,025.93 บาท แค่ซื้อ servers ได้ 1 ตัวเองนะครับ (ผมไม่แน่ใจว่าพอมั้ย ?)

วันที่ 2 มกราคม 2551 เวลาบ่ายสามโมง สถิติทรูฮิตส์ชี้ว่า ใช้งานเพียง 11,765 pageview ต่อชั่วโมง ผมลองจับเวลาดู ก็เห็น gotoknow อืดมากจนน่าเป็นห่วงแล้ว ย้อนกลับไปดู พบว่า มีบางวัน สถิติใช้งานหนักกว่านี้ ก็พอมีบ้างเหมือนกัน

แต่เมื่อลองดูสถิติทรูฮิตส์ ผมยังเชื่อว่า อาจยังพอมีทางที่จะ "รีดพลังซ่อนเร้น" ของระบบรองรับ gotoknow ได้ โดยยังไม่ต้องเพิ่ม servers ในเร็ววัน ถ้าทุกฝ่ายร่วมมือกัน

 

แนวทาง รีดพลังซ่อนเร้น ของระบบรองรับ gotoknow

สิ่งที่เป็นภาระ servers จริง ๆ แล้ว คือ ภาระในการต้อง อ่าน+ส่ง ข้อมูล ว่ามีอัตราเร็วเกินระดับวิกฤติหรือเปล่า

ถ้าเกิน ก็เหมือนกับการโจมตี server แบบ DOS (denial of service) ด้วยผู้ใช้ซะเอง

ผลของ DOS ร้ายแรงยังไง ต้องขอผู้รู้ช่วยขยายความครับ

*************************************************************  

ภาระการอ่านข้อมูล = "จำนวน pageview ในช่วงเวลานั้น"  คูณ  "ขนาดต่อ 1 webpage หรือ pagesize"

*************************************************************

ทางออกของเรา ซ่อนอยู่ในความสัมพันธ์ข้างต้นนี้เองครับ

ข้อเสนอคือ

ผู้ใช้ทั่วไป ช่วยเรื่อง "เกลี่ย" จำนวน pageview ให้เสมอกันทั้งวัน

และ

ผู้ดูแลระบบ ช่วยเรื่อง "ลด pagesize" และ "เพิ่ม page flexibility"

 

1. ผู้ใช้ทั่วไป จะช่วยได้อย่างไร

1.1 เกลี่ยตัวเอง ไปใช้ในช่วงเวลาที่ผู้คนไม่แออัด 

ลองดูกราฟ สถิติรายชั่วโมงของโกทูโนว (เอื้อเฟื้อจากทรูฮิตส์) นะครับ จะเห็นได้ว่า pageview ซึ่งสะท้อนถึงภาระของ server ณ เวลาใด ๆ ไม่ได้สูงลิ่วตลอดเวลา แต่จะสูงแค่บางช่วงเวลาเท่านั้นเอง คือ สาย ๆ 10-11 น. และบ่ายแก่ 14-15 น.

ตัวกราฟนี้ แต่ละวัน ไม่เหมือนกัน ทำอย่างไรให้ผู้ใช้ตระหนักถึงกราฟนี้ตลอดเวลาแบบ real-time เพื่อให้การตัดสินใจ เหมือนระบบจราจรในกรุงเทพฯ ที่ใช้วิทยุ จอสอร้อย เป็นตัวช่วย ? (ผมยังปวดหัวว่า จะมี link แบบ real-time ยังไง เพราะดูใน ทรูฮิตส์ มันเปลี่ยน link ไปทุกวัน)

หากผู้ใช้ ปรับพฤติกรรม "เลี่ยง" ช่วงเวลาที่การจราจรแออัดดังกล่าว ควรเลี่ยงการใช้ gotoknow โดยตรง  หรือใช้ผ่าน monitor.gotoknow.org ก็จะทำให้ระบบไม่คอขวด

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

สถิตินี้บอกว่า ท่านที่ชอบคลิกอย่างเมามันส์ หรือใช้อย่างดุเดือด ควรปรับตัวเองไปใช้ในช่วงเวลาอื่น เช่น ใช้กลางคืน

กลางคืนนี่ ใช้ตามสบายครับ

ดึก ๆ นี่ อยากกด refresh ยังไง ก็ไม่ใช่เรื่องใหญ่

แต่ช่วงแออัด คลิ๊กแล้วอืด แบบนั้น ควรใช้อย่างถนอม จะ click แต่ละที ควรชั่งใจ

ลองดูสถิติการคลิ๊กแต่ละวันในรอบสัปดาห์บ้างนะครับ ว่าวันไหน เพิ่มหรือลดจากวันก่อนหน้าอย่างไร ?

 

เสาร์-อาทิตย์ จะเงียบเหงา ก็ไม่แปลก เพราะหลายท่าน เข้า net จากบ้านไม่ได้ หรือไม่สะดวก 

สถิตินี้บอกว่า ต้นสับดาห์ กลับจากหยุดพักผ่อน ทุกท่าน มีเนื้อหาสาระแน่นเอี๊ยดมาเขียน มาเล่า มาอ่าน มาสนทนา click กันกระฉูดตอนวันทำงานวันแรก

แต่อะไรที่อยากเขียน ก็มักจะเขียนไปหมดแล้ว ปลายสัปดาห์ มักหมดมุขเขียน ปลายสัปดาห์ จะซาไป

เกลี่ยตรงนี้ได้ไหมครับ ?

จากทรูฮิตส์อีกเช่นกัน ชี้ว่า ผู้ใช้ครึ่งหนึ่ง เข้ามาผ่าน search engine กลุ่มนี้ ถ้าเป็นขาจร คงหวังเรื่องการเกลี่ยไม่ได้ เพราะเขาคงไม่มาใส่ใจปัญหาที่แปลกถิ่นไกลตัว  มาตรการนี้ จึงเป็นเพียงการผ่อนหนักเป็นเบา แต่ผมเชื่อว่า แค่เกลี่ยการใช้ให้ยอดแหลมของ pageview ยุบลงมาเหลือแค่ 2/3 จากเดิม ก็จะเท่ากับเราเพิ่ม servers รวดเดียว 3 ตัว เพราะความเสี่ยงเชิงระบบ อยู่ตรงตำแหน่งยอดแหลมนี่เอง ว่าสูงแค่ไหน ถ้ากุดยอดแหลม ไปโปะให้ตรงเวลาอื่นที่ใช้น้อย ๆ จะทำให้เกิดช่องว่างให้ขยับขยายได้อีกมากแบบสบาย ๆ

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

พูดอีกอย่างคือ เรากลัว ค่าสูงสุดของโหลด ไม่ได้กลัว ค่่าเฉลี่ยของโหลด 

ดังภาพนี้ ที่คุณ conductor เคยเล่าไว้ว่า

..."รูปข้างบนนี้ แกนตั้งเป็นเวลาในการตอบสนองของระบบ ผมเริ่มวัดหลังจากการปรับปรุงครั้งแรกในเดือนเมษายน เดิมมี 3 เครื่อง เอามาเพิ่มให้อีก 4 เครื่อง แต่เวลาในการตอบสนองยังสูงอยู่มาก ทั้งๆที่มีทรัพยากรเหลือเฟือ อาจารย์ธวัชชัยค้นพบคอขวด และสามารถปราบ GotoKnow เสียอยู่หมัดในเดือนพฤษภา (ลบโปรแกรมออก 32 ตัวอักษร จากบรรทัดเดียว)

ระบบดูดีมากครับ เรารู้ว่าคอขวดอันใหญ่หายไปแล้ว pageview เดือน 6 เดือน 7 ก็โต แต่ response time เดือน Jul(7) แสดงอาการผิดปกติ พอเดือนถัดมา ระบบก็ไปไม่ไหวแล้ว ไม่ทันได้ตั้งตัวเลย

แล้วก็มาถึงการปรับปรุงครั้งที่สอง เป็นการปรับแต่งฐานข้อมูล จัดระบบหน่วยความจำ ประคับประคองให้ GotoKnow Learners Researchers และ Volunteers พออยู่ได้ นั่งปรับแต่งกันตั้งแต่เย็นไปจนเช้าอยู่อาทิตย์หนึ่ง GotoKnow ก็กลับมา

แต่ในช่วงที่มีปัญหา Google เข้ามาเอาข้อมูลไม่ได้ ก็เลยงอน ทำให้ PageRankTM ของ GotoKnow ตกลงมาก หลุดหน้าแรกของ Google ไป ทำให้คนเข้า GotoKnow จากภายนอกน้อยลง ซึ่งอันนี้อธิบายว่าทำไม pageview เดือน 9 จึงลดลงมาก

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

ตลอดหลายเดือนที่ผ่านมา ก็ไล่ดูโปรแกรม และพยายามช่วยเท่าที่ช่วยได้แล้ว เริ่มใช้ GotoKnow Monitor เมื่อเดือน ส.ค. เอาหน่วยความจำมาเสริม พยายามพยุง พยายามรีดทุกอย่างที่มีอยู่ ให้ GotoKnow อยู่ได้ ก็ไม่รอด [ระบบ GotoKnow มีมากกว่าและซับซ้อนกว่าที่แสดงในรายการครับ] คราวนี้ไม่มีทางอื่น ต้องซื้อเครื่องใหม่อย่างเดียว

สมาชิกผู้ไม่ประสงค์จะออกนาม บริจาคเครื่องแม่ข่ายมาสองเครื่อง GotoKnow เร็วปรี๊ด ทุกคนมีความสุขเหมือนเดิม ตอนนี้ยังไม่มีปัญหาอะไร

สัญญาณที่ผมพูดถึงใน #8 คือแท่งที่อยู่ดีๆ โด่งขึ้นมาโดยไม่มีเหตุผลอธิบาย สีก็สำคัญครับ สีเขียวดี สีฟ้ารับได้ สีอื่นไม่ดี เคยบอกว่ามันโผล่มาในวันที่ 11 กับ 13 ธ.ค. แต่ถ้าคลิกดูตอนนี้ในรูป Last 10 Days จะเห็นว่าวันที่ 17, 21, 22, 23 และวันนี้ 25 ก็มีนะครับ แล้วสูงขึ้นมาเรื่อยๆ ..."

ซึ่งคุณ conductor ประเมินว่า

"best estimator คือของ next crash น่าจะอยู่ที่ 5.586 ล้าน pageview/เดือน"

การประเมินดังกล่าว ประเมินอิงตามพฤติกรรมจริงของผู้ใช้ ซึ่งผมเองเชื่อว่า หากผู้ใช้ปรับพฤติกรรมเรื่องช่วงเวลาการใช้ให้เกิดการเกลี่ยโหลด เราอาจเขยิบจุด next crash ให้สูงกว่านี้ไปได้อีกมาก

คือเหมือนให้คนแบกของหนักกองหนึ่ง บางเที่ยว ขนของหนักมาก บางเที่ยวก็เดินตัวปลิว ถ้าจะล้ม ก็ล้มตอนเที่ยวที่ของหนักเกินตัวนั่นแหละ เจอรอบเดียวก็เดี้ยงแล้ว

แต่ถ้าเฉลี่ยน้ำหนักที่แบกให้เสมอกัน แบกหลายรอบ อาจทำได้โดยไม่ทันเหนื่อย และไม่กลัวล้ม แบกได้มากกว่าด้วย

โรงไฟฟ้าที่เขาจะสร้างเพิ่ม ก็เกิดจากปัญหาทำนองเดียวกันนี้ คือ กลัวโหลดทะยานช่วงสั้น ๆ ตอนบางช่วงเวลาในแต่ละวัน ทั้งที่โหลดเฉลี่ยยังรับมือได้สบาย เขาจึง(เคย)พยายามรณรงค์ให้ประชาชนใช้ไฟฟ้าเสมอกันทั้งวันไงล่ะครับ

"ตรงนี้ เป็นไปได้ไหมครับ ที่ผู้ดูแลระบบ ใช้วิธีทำให้ระบบซอฟท์แวร์มี self-awareness ว่า ขณะนี้ ถึงเวลาต้อง feedback ให้ผู้ใช้รู้ว่า ระบบกำลังตึงตัวนิดหน่อย หรือตึงตัวรุนแรง" ?

 

1.2 ใช้ RSS ให้เป็นประโยชน์

น้องบ่าววีร์ (ดู comment ข้างท้าย) ชี้ประเด็นนี้ขึ้นมา ทำให้ตาสว่างขึ้น(...นิดหน่อย ... พอเข้าใจลาง ๆ)

ตรงนี้ ผมลองค้นย้อนไปดู เห็นมีการพูดถึงกันพอสมควร ตัวเองไม่ค่อย อิน-เทรนด์ ก็เลยไม่ได้สนใจในตอนนั้น  

ก็เลยถือโอกาส ทำลิงค์ รวมฮิต RSS ให้ลองเข้าไปดูกัน เผื่อมีทางออกที่ "ดี และ ง่ายผิดคาด" ให้เราใช้กัน ซึ่งแม้เคยมีการคุยประเด็นนี้กันมามาก ซึ่งหากมีท่านใด review ประเด็นนี้ เพื่อตอบโจทย์ "ลดภาระระบบ" ได้ และ "ตอบโจทย์ผู้ใช้ได้" (ดูประเด็นที่ท่านอัยการชาวเกาะ comment ข้างล่าง)" ก็น่าจะดี

 

2. ผู้บริหารระบบ จะช่วยได้อย่างไร

 

ในขณะที่ ผู้ใช้ มีส่วนช่วยเรื่องการลดจำนวน pageview ในช่วงเวลานั้น ๆ 

ผู้ดูแลระบบ ก็อาจจะพิจารณาถึงการทำให้หน้าเว็บประหยัดขึ้น เช่น

2.1 ลดขนาดต่อ 1 webpage

จะลดได้อย่างไร นี่คงเป็นโจทย์ เพราะมีประเด็นเรื่อง usability มาเกี่ยวข้องเยอะ และเป็นประเด็นทางเทคนิค ที่ผมไม่มีความรู้ 

แต่เท่าที่ลอง save หน้าเว็บมาดู เห็นส่วนเนื้อที่เป็นข้อเขียนไม่มาก แต่เป็น overhead ของระบบค่อนข้างมาก

หากลด content per page ลงได้สักครึ่งหนึ่ง ผมเชื่อว่า จะยืดเวลาของการเกิดปัญหาไปได้อีก 1 ปีเต็ม เพราะเท่ากับภาระของระบบหล่นฮวบลงครึ่งหนึ่ง น่าจะทำให้เพิ่ม page view ขึ้นได้อีกมากโดยระบบยังไม่ตึงตัว

 

2.2 เป็นไปได้ไหมครับ ที่จะใช้วิธีทำให้ระบบซอฟท์แวร์-server มี self awareness และปรับตัวตามระดับความรุนแรงของปัญหา

เช่น ในส่วนระบบ server จับเวลา access time และใช้วิธีดูค่าเฉลี่ยเคลื่อนที่ (moving average) ว่ากำลังเจอคอขวดของการใช้งานไหม หรือนับจำนวนครั้งการ request ข้อมูล แล้วเปรียบเทียบกับค่าระดับที่เคยทำให้เกิดวิกฤติครั้งก่อน แล้วปรับตัวเพียงเล็กน้อย เพื่อโต้ตอบกับสถานการณ์เฉพาะหน้า

การปรับตัวเพียงเล็กน้อย อาจเป็นตั้งแต่

2.2.1 แทรกคำเตือนเข้าไปในพาดหัวของ gotoknow เมื่อระบบกำลังใกล้คอขวด ให้ไปใช้ผ่าน monitor.gotoknow.org/งด post/เลี่ยงการเข้าใช้ถ้าเป็นไปได้ หรือใส่สีเป็น alert mode เช่น พาดหัวเหลืองอ๋อย เมื่อ "ระดับการใช้งานเริ่มตึงตัว ผู้ใช้ควรเลี่ยง" หรือพาดหัวแดงก่ำ เมื่อ server เริ่มมีปัญหา ผู้ใช้จะได้งดไปก่อนเลย ไม่ click ซ้ำเป็นการสร้างปัญหาทับถมเข้าไปอีก

อีกทางที่ทำง่ายมาก คือ ค้าง link ไปดูสถิติทรูฮิตส์ โดยเฉพาะ สถิติรายชั่วโมง

และค้าง link ของ monitor.gotoknow.org ไว้ในช่วงเวลา peak ของวัน เพื่อจูงใจให้หันไปใช้ตรงนั้น

ทำไมต้องทำให้ยุ่ง ไม่ค้างคำเตือนถาวร ? ทำไมต้องใช้กระบวนท่าลวดลาย ?

ผมมีประสบการณ์ว่า ระบบเตือนทั้งหลายที่ล้มเหลว จะล้มเหลวเมื่อเตือนมากไป หรือเตือนตลอดเวลา แต่จะได้ผลดี ถ้าเลือกเตือนเมื่อถึงเวลาจริง ๆ เตือนแบบเมื่อทุกอย่างสุกงอม จะได้รับการร่วมมือดีกว่า (ลองนึกถึงเวลากรมอุตุเตือนเรื่องภัยพิบัตินะครับ ถ้าเตือนทุกวัน "เผื่อเกิด" คนจะไม่เชื่อถือ ต้องเลือกเตือนเมื่อทุกอย่างค่อนข้างชัดว่า "คงเกิด")

 

2.2.2 ระบบการแสดงผลแบบประหยัดในช่วงเวลาที่ server มีภาระหนัก เช่น ไม่แสดงภาพหน้าผู้ post หรือตัดทิ้งบางส่วนที่ไม่คอขาดบาดตายมาก (ตัดชั่วคราว แต่จะกลับมาใช้โหมดปรกติได้เมื่อ server กำลังว่าง ๆ)

ข้อเสนอนี้ ผมเองก็มองว่า ทำยาก แต่เสนอไว้ เผื่อมีการ ปิ๊ง ทางออก

 

2.2.3 ใช้ระบบ login ค้างข้ามวันได้ โดยผู้ใช้สามารถ click เปลี่ยนกลับเป็นแบบครั้งต่อครั้ง ในกรณีที่ใช้เครื่องสาธารณะ

แบบนี้ น่าจะทุ่นการ click ไปได้หลาย pageview ?

ผมประมาณเองอย่างไม่เป็นทางการ น่าจะทุ่นไปได้สัก 10+ %

ที่มา: สองสุ่มข้อมูลมาวันหนึ่ง เวลาบ่ายสอง มีราว 4800 pageview มี 1500 unique IP

หาร 2 ที่ unique IP น่าจะได้เป็น IP ของสมาชิก (ครึ่งหนึ่งที่เข้ามา ผ่าน search engine ผมจึงตีความว่า ที่เหลือ เป็นสมาชิกหมด)

หาร 2 อีกที (อันนี้มั่วเอาเอง) สมมติว่าเป็นสมาชิกที่ login

ก็เท่ากับว่า ใน 4800 pageview นี่ รองรับการ login 400 รายการ ซึ่ง login แต่ละครั้ง มีหลาย click โขอยู่ ผมจึงประมาณว่า ภาระราว 10 % หรืออาจมากกว่านั้น เป็นภาระที่เกี่ยวเนื่องกับการ login (ซึ่งดูจากพฤติกรรมของตัวเอง ผมคิดว่า น่าจะพอเป็นไปได้)

ดูไม่เยอะ แต่จริง ๆ แล้ว น่าจะพอเทียบได้กับการเพิ่ม server 1 ตัว

ทางเลือก 2.2.3 น่าจะทำได้ง่าย และคงมีส่วนช่วยลด pageview ได้ไม่น้อย...

 

3. จะทำอย่างไร ให้เกิด distributed network ข้ามไปยังเครือข่ายอื่นด้วย ?

เท่าที่ผมทราบ หลายท่าน ก็มี blog ที่อื่นด้วย

ทำอย่างไรให้เห็นทะลุถึงกันได้หมด ?

เห็น โดยไม่ต้อง เก็บไว้เอง ถือเป็นสุดยอดของการจัดการ เพราะตัวเองแทบไม่มีต้นทุนการจัดการเก็บ (มีแต่ต้นทุนในการ มองให้เห็น)

ผมยกตัวอย่างนะครับ

ที่ ม.อ. มีเว็บทำ KM ชื่อ share.psu.ac.th ซึ่งขอเรียกสั้น ๆ ว่า "วงแชร์" (ฟังดูแล้วนึกถึงเรื่องเงิน ๆ ทอง ๆ จังวุ้ย) ซึ่งก็ใช้โค้ดของ gotoknow นี่แหละ ไปปรับแต่งนิดหน่อยให้เข้ากับลักษณะเฉพาะของตัวเอง

ผมเองก็แถกไปเปิด blog ตรงนั้นด้วย ในฐานะบุคลากร (เอาซะหน่อย !) ตาม link นี้

เนื่องจากเว็บนั้น การใช้งาน ไม่ได้ดุเดือดอะไร (ยกเว้นเวลาเปิดอบรมการเขียนบล็อก) จึงไม่ทำให้ผู้ใช้ต้องกังวล (อีกอย่าง ยังไม่ถูก ตัดหางปล่อยวัด เจ้าของยังรัก ยังถนอมอยู่)

แม้เป็นวงใน วงเล็ก ๆ ที่ต้องเป็นสมาชิกเท่านั้น จึงจะเข้าไปเขียนบล็อกได้ แต่กระทู้ส่วนใหญ่ เปิดให้ทุกคนอ่านได้เป็นสาธารณะ ซึ่งถ้าผมเข้าใจไม่ผิด ใช้ RSS feed ได้ (มั้ง ? ... ใช้ไม่เป็นอ่ะนะ ที่ผ่านมา สั่งมั่ว ๆ ... แล้วมันบังเอิญทำให้ ... ให้ทำอีกที ไม่แน่ใจว่าจะทำได้รึเปล่า ... หุหุหุ)

บางกระทู้ ผมอยากใส่รูปเยอะ ๆ เขียนน้อย ๆ และค่อนข้างเป็นเรื่องที่คนในท้องถิ่นสนใจ ผมก็ไปเปียแชร์ เอ๊ย เข้า วงแชร์ (อุ๊บส์... เผลอเปิดเผยความในใจ... !)

ผมอาจใส่ link จาก gotoknow ออกไป ในกรณีนี้ ก็เกือบเหมือนเขียนใน gotoknow เหมือนกัน แต่ภาระหนัก server ไปอยู่ที่อื่นแทน

แต่ต่อให้ทำไม่ได้ในฐานะของผู้จัดการระบบ แต่ในฐานะของผู้ใช้ ทำแบบนี้ ก็เป็นรูปแบบหนึ่งของการ เกลี่ยโหลด ได้เหมือนกัน ?

ในอนาคต จะมีการเชื่อมต่อแบบ virtual network โดยใช้หลัก distributed network ให้เสมือนหนึ่ง เห็นเป็น blog เดียวได้หรือไม่ ? เช่น login passport ใน share แล้วเห็น gotoknow

 

ซักซ้อมสัญญาณเตือนภัย

 

ญี่ปุ่น ขึ้นชื่อว่าเกิดภัยพิบัติซึนามิบ่อย แต่ไม่ค่อยมีใครเป็นอะไร เพราะเขาซ้อมรับมือบ่อย ควรที่เราเรียนรู้จากตรงนั้น มารู้จัก "สัญญาณเตือนภัย" ของ gotoknow ไว้ เพื่อจะได้ปรับตัวได้ทันควัน

หากวันแรกที่เปิดทำงานต้นสัปดาห์ ช่วงสาย ๆ หรือบ่ายแก่ ๆ ใด ท่านเข้า gotoknow แล้วโหลดอืดมาก ทั้งที่เข้าเว็บอื่น ไวเป็นไฟแล่บ นั่นคือสัญญาณเตือนว่า ถึงเวลาที่ทุกท่านต้องปรับพฤติกรรมด่วน อย่างน้อย ก็หลีกช่วงเวลาแออัดที่อันตรายต่อ server ตามสถิติล่าสุดของทรูฮิตส์ (click ที่นี่)

 

สรุปปิดท้าย

วันที่เพิ่งเปิดทำงานวันแรกหลังวันหยุด ช่วงสาย และบ่ายแก่ หากวันใด ท่าน click แล้ว gotoknow อืดมาก พึงตระหนักว่า นั่นคือ สัญญาณขอความช่วยเหลือจาก gotoknow

การช่วยเหลือ ไม่ใช่ click ซ้ำ

แต่เป็นการ เลี่ยงไปใช้ผ่าน monitor.gotoknow.org หรือเปลี่ยนเวลาใช้

 

หมายเหตุแนบท้าย 21 มกราคม 2551

หลังจาก gotoknow มีการปรับโฉมใหม่ ในต้น มกราคม 2551 แล้ว ทำให้การทำงานเร็วขึ้นราว 20 % จะทำให้การประมาณค่าจาก "next crash ที่ 5.586 ล้าน pageview/เดือน" เขยิบขึ้นมาเป็น 7 ล้าน pageview/เดือน 

ตอนนี้ ถือว่า โล่งใจได้พักใหญ่ แต่อาจจะกลับเข้มข้นอีกที ราวปลายปี 2551 ครับ