การยืดอายุ GotoKnow โดย(ยัง)ไม่ต้องเพิ่ม server

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

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

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

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

note 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 เข้ามาเอาข้อมูลไม่ได้ ก็เลยงอน ทำให้ PageRank^TM ของ 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 ครับ

 

[เบิร์ด]

สวัสดีค่ะ อ.วิบุล

เอาอีกๆๆๆๆ

อยากทราบต่อค่ะ เพราะน่าสนใจมากเลย

ส่วนของผู้ใช้ 

1. หลีกเลี่ยงการใช้งานช่วงการจราจรหนาแน่นคือช่วง  

10-11 น. และ่ 13 - 16 น. สรุปสั้นๆคือควรใช้งานหลังเลิกงานไปจนถึงก่อน 9 โมงเช้า

2. ควรใช้ monitor.gotoknow.org ไม่ควรใช้หน้าแรกของ G2K เพื่อลดโหลด และไม่ควร Refresh บ่อยๆ

 ส่วนของผู้บริหารระบบ

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

2. ทำให้ระบบซอฟท์แวร์-server มี self awareness 

3. ใส่ link ไปดูสถิติทรูฮิตส์ โดยเฉพาะสถิติรายชั่วโมง  และอาจมีข้อความเตือนในช่วงระบบอาจเข้าภาวะงานหนักเกินกำลัง

จะรออ่านต่อนะคะอาจารย์ เพราะหนังเรื่องนี้ยาว ^ ^

 

 

[वीर]

ผม check blog ที่มีคน update จาก web feed ซึ่งน่าจะมีขนาดเล็กกว่า web page มาก (มั้ง). ถ้าเป็นไปได้ผมก็พยายาม อ่านใน feed เลย. ยกเว้นถ้าอยาก comment มากๆ (แบบกรณีนี้) ก็ถึงเข้าเว็บ. นอกจากนั้นผมก็พยายามเขียน blog ที่อื่น (ผมคิดว่า)เก็บทรัพยากรณ์ไว้สำหรับคนที่ต้องการจริงๆดีกว่า.

[wwibul]

ขอบคุณน้อง เบิร์ด

 

• แหม..ผมเกรงใจจัง คุณเบิร์ดเล่นช่วยโปรโมตกระหน่ำ
• ถือเป็นยอดฝีมือเรื่อง PR เลยนะนี่

 

ขอบคุณคุณบ่าว   वीर

 

• ประเด็นนี้ ไม่ทราบว่า พอจะมีวิธีเช็คตัวเลขไหมครับ
• ตัวเองทำไม่เป็นครับ แฮะ แฮะ...

 

[वीर]

http://gotoknow.org/planet/vsel ขนาดประมาณ 1.3 MB
http://gotoknow.org/planet/vsel/rss20.xml ขนาดประมาณ 24 KB


ใน RSS ข้อความที่ตัดมาสั้นกว่า. ส่วนที่ตัดออกไป ที่ไม่เกี่ยวกับข้อความที่สั้นกว่า น่าจะเป็น javascript, รูป และ css ฯลฯ. อย่างไรก็ตาม javascript, css หรืออะไรอื่นๆที่ load มาซ้ำจะถูก cache แล้วหรือเปล่า.


ส่วนวิธีทดสอบผมใช้ Firefox เก็บหน้าเว็บและอื่นๆมา. แล้วใช้คำสั่ง find ดูว่าไม่ไฟล์อะไรบ้าง find ~/vsel > list.txt แล้วก็ใช้ script รวมขนาดไฟล์



f = open("list.txt")
a = 0
while f.gets
    a += File.size("#{$_.chomp}")
end
f.close
print "#{a}\n"

[वीर]

http://gotoknow.org/planet/vsel/rss20.xml ขนาดประมาณ 28 KB นะครับ.

[อัยการชาวเกาะ]

ขอบคุณข้อเสนอแนะดีๆครับ

ผมขอเสนอแนะอีกข้อหนึ่งครับ เพราะคิดในแง่การใช้งาน ทำไมคนใช้ mornitor.gotoknow น้อย ก็เพราะจิตวิทยาผู้ใช้ เมื่อเข้าบล๊อก G2K ก็อยากจะดูบล๊อกตัวเองก่อนว่าบันทึกของตัวมีคนเข้าไป comment บ้างหรือเปล่าจะได้ตอบเขาไป

ดังนั้นเมื่อจะเข้า mornitor ก็ให้ log in ก่อน แล้วทำให้ใน mornitor ช่องแรกมีบอกว่า บันทึกของเรามีใครเข้ามาแสดงความคิดเห็นหรือไม่มี ผมว่าผู้ใช้ก็จะใช้ mornitor มากขึ้นครับ

เทียบจากพฤติกรรมของผมเองครับ แต่ทุกวันนี้ก็พยายามใช้ mornitor ในวันที่ไม่ได้เขียนบันทึกครับ

[wwibul]

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

1. RSS feed ลดภาระระบบได้ ?

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

หรือ ส่ง=รับ ? (คือ ส่งไปยังไง ก็เห็นยังงั้น)

ถ้าลดได้จริง คือ ส่ง = รับ ผมเชื่อว่า มีรูปแบบการประยุกต์ต่อได้ หลากหลาย เช่น

2. ท่านอัยการชาวเกาะ เสนอเรื่องเช็คประเด็น บันทึกที่ได้รับความคิดเห็นล่าสุดของฉัน และ บันทึกที่ได้รับความคิดเห็นล่าสุดที่ฉันร่วมให้ความคิดเห็น ได้จาก monitor.gotoknow.org

ผมไม่แน่ใจประเด็นนั้น เพราะ monitor ทำไว้กลาง ๆ ไม่ได้มีหน้าตาที่ปรับตาม login เฉพาะตัว

แต่ถ้า บันทึกที่ได้รับความคิดเห็นล่าสุดของฉัน และ บันทึกที่ได้รับความคิดเห็นล่าสุดที่ฉันร่วมให้ความคิดเห็น ของแต่ละท่าน มี RSS feed (ตอนนี้ ผมเข้าใจว่า ยังไม่มี link หรือ RSS feed) แล้วใช้วิธีแบบของคุณบ่าว คือใส่ RSS feed ไว้ใน web ข้างนอก ให้เห็นตรงนี้ตลอด หรือแม้แต่พลิกแพลงใส่ใน monitor ให้ add RSS ได้ ก็น่าสนใจนะครับ ว่าเป็นไปได้แค่ไหน ในทางเทคนิค...

หรือปรับโฉม gotoknow ให้ผลักสองส่วนนี้ขึ้นมาให้เข้าถึงได้โดย click น้อยครั้งกว่าเดิม... ?

หรือทำโปรแกรมเล็ก ๆ ให้ดึง บันทึกที่ได้รับความคิดเห็นล่าสุดของฉัน และ บันทึกที่ได้รับความคิดเห็นล่าสุดที่ฉันร่วมให้ความคิดเห็น โดยเลียนแบบ monitor แต่เป็น monitor ที่ปรับให้เข้ากับคน คือ login แล้วค้างไว้ แล้ว feed ไหลเข้ามาเอง ?

 

[वीर]

wwibul: ข้อมูลที่ส่งมาจาก server ถึงเครื่องของผู้ใช้น้อยลงแน่นอนครับ ถ้าใช้ RSS ในกรณีของ Gotoknow. อย่างไรก็ตามข้อมูลที่ส่งกันระหว่าง server และภาระในการประมวลผลอาจจะไม่ได้ลดลง.

การส่งข้อมูลกันระหว่าง application server, web server, database server อาจจะยังไม่ใช่เรื่องใหญ่ เพราะใช้ local area network ที่เร็วได้ ในราคาไม่แพงอยู่แล้ว.

ส่วนที่น่าจะทำงานหนักอยู่ดีถึงแม้จะใช้ RSS น่าจะเป็น database server? application server ก็อาจจะทำงานหนักเหมือนกัน แต่ก็น่าจะพอมีวิธีแก้เช่น ใช้ Java แทน Ruby เฉพาะส่วนที่เปิด RSS ก็น่าจะพอทำได้.

[เบิร์ด]

สวัสดีค่ะ อ.วิบุล , คุณวีร์ , ท่านอัยการชาวเกาะ

สนุกจังค่ะ ^ ^

เบิร์ดแชร์ข้อมูลในส่วนผู้ใช้ที่เป็นตัวเบิร์ดเองนะคะ

เบิร์ดไม่เคยยุ่งกับหน้าแรกของโก ฯ และ monitor เลยล่ะค่ะ เบิร์ดจะเข้าที่หน้าล็อคอินเลย และศูนย์รวมข้อมูล

ดังนั้นเพจที่รับการใช้งานหนักที่สุดของเบิร์ดคือหน้าศูนย์รวมข้อมูลค่ะเพราะต้องกลับไปกลับมาระหว่างบันทึกที่เบิร์ดติดตามและหน้าศูนย์รวมข้อมูล..มีทางแก้ไขมั้ยคะ ?

และถ้าเราสามารถทำให้ G2K รักษาบัญชีผู้ใช้ไว้ได้ 2 อาทิตย์โดยไม่ต้องล็อคอินบ่อยๆแบบ Yahoo จะช่วยได้บ้างมั้ยคะ ?

 

[वीर]

เบิร์ด: ไม่ต้อง login บ่อยๆ ก็ช่วยลดภาระของเครื่องได้ครับ แต่ *อาจจะ* ไม่ได้ลดในส่วนสำคัญก็ได้. หน้าศูนย์รวมข้อมูลจะไม่ต้องถูกเปิดบ่อยๆ. ถ้ามี e-mail แจ้งเตือน บันทึกของคนอื่นที่เราสนใจได้รับคิดเห็นด้วย.

[wwibul]

• ขอบคุณน้องบ่าว สำหรับการหาข้อมูล และความเห็น เชื่อว่า คงมีการสานต่อ ครับ
• ประเด็นที่น้องเบิร์ดยกมา ผมก็ว่า น่าสนใจในประเด็นว่า "ผู้ใช้ส่วนใช้ ใช้ตรงหน้าไหน บ่อยที่สุด" ?
• มีทางหาข้อมูลไหมครับ ?

[ดร. ธวัชชัย ปิยะวัฒน์]

เรียนทุกท่าน

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

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

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

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

[ดร. ธวัชชัย ปิยะวัฒน์]

ลืมใส่ลิงค์ในความเห็นด้านบนครับ "บันทึกนี้" คือ "แผนการทำงานของ UsableLabs" ครับ

[वीर]

ขอบคุณดร. ธวัชชัย ปิยะวัฒน์ครับ ได้อ่านแบบนี้ ผมก็ใช้ได้สบายใจขึ้น :-).

[wwibul]

• อ่านที่   ดร. ธวัชชัย ปิยะวัฒน์ ชี้แจงแล้วโล่งใจครับ

 

 

[Conductor]

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

การปรับปรุงระบบเมื่อเดือนพฤศจิกายน ทำให้ระบบมีความสามารถที่เพิ่มขึ้นมาก ช่วงก่อนน้องต้นไม้จะเกิด ก็มีการ "จัดระบบ" อีกที เชื่อได้ว่าทำให้ระบบมีเสถียรภาพดีขึ้นอีกพอสมควร

ข้อพิสูจน์ก็คือการ crash เมื่อเดือนสิงหาคม มี peak load อยู่ที่หมื่นสองพันหน้าต่อชั่วโมง แต่ในขณะนี้ peak load ไปถึงหมื่นห้าพันหน้าต่อชั่วโมง โดยระบบยังไม่แสดงอาการอะไรมากมาย 

อาการช้าเป็นบางครั้งแบบที่อาจารย์วิบุลสังเกตเห็น อาจเกิดจากความคับคั่งในวงจร ADSL ครับ ถ้าจะดูการตอบสนองของระบบโดยตัดความคับคั่งภายในวงจรของไอเอสพีที่อาจารย์ใช้ออกไป ดูที่นี่ครับ สภาพดูดีกว่าเดือนสิงหาคม/พฤศจิกายนมากมายทีเดียว เคยมีสัญญาณเตือนแต่ก็ผ่านพ้นไปได้ด้วยดี 

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

ส่วนสมาชิก สามารถช่วยกันได้ ตามคำแนะนำต่างๆในบันทึกและความคิดเห็นในบันทึกนี้

• กระจายการอ่านหรือใช้งาน GotoKnow ออกไปจากชั่วโมงเร่งด่วน 15:xx น.
  
• หลีกเลี่ยงการเปิดหน้าแรกโดยไม่จำเป็น จะเข้า portal หรือ login เลยก็แล้วแต่ ดีกว่าทั้งนั้น
• สมาชิกที่ล๊อกอิน มีน้อยกว่าที่ไม่ล๊อกอินมากมากนัก; ส่วนใหญ่จะ browse ดูเฉยๆ กวาดไปเรื่อยๆ
  
• RSS ช่วยได้ดี แต่ไม่มากเท่า monitor ซึ่งลดภาระของการแสดงหน้าแรกได้มากโดยตรง 
• ตั้งอีเมลให้ถูกต้อง เมื่อมีใครมาให้ความเห็น GotoKnow จะแจ้งเตือนผ่านอีเมล ท่านสามารถตรงไปที่บันทึกนั้นได้ทันที โดยไม่ต้องผ่านหน้าใด

สำหรับคำแนะนำของท่านอัยการ ยังติดคิวการพัฒนาครับ แต่ได้คุยกันแล้ว

กล่าวโดยรวม คือมีความเสี่ยงอยู่เสมอไม่ว่าจะชอบหรือไม่ชอบ แต่ตอนนี้สมาชิกเข้าใจสถานการณ์แล้ว จึงช่วยกันรักษา ใช้งาน GotoKnow อย่างคุ้มค่า 

เมื่อวาน(3) ก็มีโหลดสูง แต่ยังต่ำกว่าที่ระบบเก่าเคยรับได้ (ดูกราฟ) ตอนนี้ GotoKnow ดีกว่าเก่ามากมาย ผมเชื่อว่ายังรับโหลดได้อีกพอสมควร 

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

[wwibul]

• ขอบคุณครับ สำหรับการเสริมข้อมูลที่รอบด้าน ทำให้เห็นภาพชัดเจนขึ้น
• แถวบ้านผม ถือกันว่า "การกู้ระเบิด เป็นหน้าที่ของผู้เชี่ยวชาญ การให้เบาะแส เป็นหน้าที่พลเมืองดีครับ"

 

ผมยังมีข้อสงสัยหน่อยนึงครับ...

• เป็นธรรมเนียมปฎิบัติทาง IT ไหมครับ ที่จะ validate ระบบ ด้วยการ challenge test ตัวเอง ? (ในกรณีนี้ คือ challenge test ด้วยการจำลอง DOS เข้าหาตัวเอง เพื่อดูระดับความทนทานของระบบ ว่า รับเต็มที่ได้กี่ pageview) 
• หาก "ไม่" ที่ทำไม่ได้เพราะอันตรายเกินไป ? หรือทำได้ยาก ?

(วางระเบิดไปไหมนี่ ?)

[Conductor]

ขยายความอีกครั้งหนึ่งครับ

คำแนะนำของคุณ वीर เรื่อง RSS นั้น ช่วยได้จริงครับ RSS อ่านข้อมูลจาก memory pool (memcached) กลางอันเดียวกับ GotoKnow ซึ่งจะตรงจุดหากรู้ว่าต้องการดูอะไร; ส่วน monitor อ่านข้อมูลจาก memory pool เช่นกัน แต่ว่ามีเป็นของตัวเอง-ไม่แชร์กับ GotoKnow; ทั้งคู่ ปัมป์ออกมาได้เรืี่อยๆ โดยไม่กินกำลังฐานข้อมูลซึ่งในตอนนี้เป็นจุดที่เปราะบางที่สุด แต่ยังรับไหวครับ

สำหรับคำแนะนำของท่านอัยการเรื่องล๊อกอินใน #6 และคำแนะนำของอาจารย์กมลวัลย์(ในบันทึกอื่น) เรื่องการติดตามความเปลี่ยนแปลงในแพลนเน็ตของเรา ยังติดที่ไม่สามารถล๊อกอินผ่าน monitor ได้เนื่องจาก KV ยังไม่ได้รองรับเรื่องนี้ครับ แต่อยู่ในแผนที่ยังไม่ได้ทำ

ตอนนี้ monitor เปิดศูนย์ข้อมูลได้ในแท็บที่ห้า (ลิงก์สำคัญ) โดยใส่บัญชีชื่อผู้ใช้เข้าไป แล้วคลิก "เปิดศูนย์รวมข้อมูล" -- ที่จริงจะสามารถเปิดศูนย์รวมข้อมูลของใครก็ได้ ถ้ารู้ username

monitor ยังมีคุณลักษณะอีกอย่างหนึ่ง อยู่ในแท็บที่ห้าเช่นกัน คือไล่ดูได้ว่าใครเขียนอะไรไว้ที่ไหนในช่วง 96 ชั่วโมงที่ผ่านมานะครับ ใส่ username ที่เดียวกับข้างบน แต่คลิก "ติดตามข้อความล่าสุด" แทน อันนี้จะเห็นด้วยว่าสมาชิกท่านนั้น เขียนความคิดเห็นที่ไหนบ้าง เช่นติดตามข้อความล่าสุดของท่านอัยการ

• จริงใจกว่านี้ ไม่มีอีกแล้ว: วิธีแอบติดตามบล๊อกเกอร์คนโปรด
  

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

[wwibul]

"monitor ยังมีคุณลักษณะอีกอย่างหนึ่ง อยู่ในแท็บที่ห้าเช่นกัน คือไล่ดูได้ว่าใครเขียนอะไรไว้ที่ไหนในช่วง 96 ชั่วโมงที่ผ่านมานะครับ ใส่ username ที่เดียวกับข้างบน แต่คลิก "ติดตามข้อความล่าสุด" แทน.... "

ขอบคุณครับ คุณConductor

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

http://monitor.gotoknow.org/allmsgs.php?wwibul

• ซึ่งคนอื่นก็ปรับไปใช้ทำนองเดียวกันได้ โดยเปลี่ยนหลังเครื่องหมาย ? เป็นชื่อที่ login ใน gotoknow ของตัวเอง
• สะดวกมากเลยครับ ถูกใจสุด ๆ

 

[Tan]

อาจจะนำเอา ระบบ caching เข้ามาช่วย ทำให้ข้อมูลประเภท static เช่นรูปภาพต่างๆ ไม่ต้องไปดึงจาก webserver มาใหม่ทุกครั้งไป

ซึ่ง wikipedia เองก็ใช้ squid เป็น cache engine ช่วยแบ่งเบาภาระของ apache  ดังตัวอย่าง 

[tan@server-244 ~]$ telnet en.wikipedia.org 80
Trying 203.212.189.253...
Connected to en.wikipedia.org (203.212.189.253).
Escape character is '^]'.
GET / HTTP/1.0
HOST: en.wikipedia.org

HTTP/1.0 301 Moved Permanently
Date: Sat, 05 Jan 2008 00:50:31 GMT
Server: Apache
X-Powered-By: PHP/5.2.1
Vary: Accept-Encoding,Cookie
Cache-Control: s-maxage=1200, must-revalidate, max-age=0
Last-Modified: Sat, 05 Jan 2008 00:50:31 GMT
Location: http://en.wikipedia.org/wiki/Main_Page
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Cache: HIT from sq35.wikimedia.org
X-Cache-Lookup: HIT from sq35.wikimedia.org:3128
Age: 155
X-Cache: HIT from yf1004.yaseo.wikimedia.org
X-Cache-Lookup: HIT from yf1004.yaseo.wikimedia.org:3128
X-Cache: MISS from yf1000.yaseo.wikimedia.org
X-Cache-Lookup: MISS from yf1000.yaseo.wikimedia.org:80
Via: 1.0 sq35.wikimedia.org:3128 (squid/2.6.STABLE16), 1.0 yf1004.yaseo.wikimedia.org:3128 (squid/2.6.STABLE16), 1.0 yf1000.yaseo.wikimedia.org:80 (squid/2.6.STABLE16)
Connection: close

[ครูอ้อย แซ่เฮ]

• ครูอ้อย...รับทราบค่ะ
• จะพยายามเปลี่ยนเวลามาใช้ในยาม ที่ไม่ฝืด 
• ขอบคุณทุกฝ่าย ที่ร่วมมือกันค่ะ

โชคดีทุกท่าน ตลอดปีใหม่และตลอดไปค่ะ

[wwibul]

• ขอบคุณคุณ Tan และครูอ้อย สิริพร กุ่ยกระโทก ครับ
• ช่วยกันคนละไม้คนละมือ
• เรือ gotoknow จะได้แล่นฉิวครับ
  
  

[Conductor]

ใช้ reverse proxy เหมือน wikipedia ไม่เหมาะหรอกครับ ได้พิจารณาทางเลือกนี้นานแล้ว 

ด้วย template ใหม่ เวลาในการตอบสนองฝั่งเครื่องแม่ข่ายเร็วขึ้นประมาณ 20% ครับ (จาก 100ms เหลือ 80ms) แต่ว่าด้วย template ใหม่ มีการใช้ javascript มากขึ้น *และ* ยังไม่ได้ enable cache เนื่องจากระบบยังไม่นิ่ง นะครับ ยังต้อง debug ต่อไป

เมื่อระบบนิ่ง แล้ว minify javascript (ลดขนาด), compress และ enable cache น่าจะเร็วขึ้นกว่าตอนนี้อีกครับ  

[wwibul]

• ขอบคุณทุกท่านครับ
• ผมสังเกตว่า สถิติ web มักนิยมนำเสนอในสเกลเลขคณิต
• ทำให้ค่าที่สูงผิดปรกติ "ท่วม" กราฟ ทำให้อ่านค่าต่ำ ๆ อื่นยากขึ้น
• ไม่รู้ว่า ถ้านำเสนอใน log scale จะมีส่วนช่วยไหมครับ
• ประสบการณ์ส่วนตัวคือ log scale ช่วยได้ดีีมาก ในการตามดูสถิติย้อนหลังที่มีการแกว่งของข้อมูลดิบรุนแรง แต่ไม่มีประสบการณ์เรื่องทำรายงานในเว็บครับ เพียงแต่ "รู้สึกว่า น่าจะได้"
• ตัวอย่างข้างล่าง เป็นรายงานสถิติสแปมเว็บบอร์ด ใช้อัตราส่วน จำนวนสแปม หาร จำนวนรายการที่ไม่ใช่สแปม เมื่อแสดงเป็นแบบสเกล log จะเห็นปรากฎการณ์ชัดเจนมากขึ้นครับ