เนื่องจากผู้เขียนได้มีการทำงานที่ต้องตรวจสอบไฟล์ จึงอยากจะแชร์ประสบการณ์การเขียน web service โดยยกตัวอย่างการเขียนดังนี้ โดยจากตัวอย่างผู้เขียนได้ใช้ฟังก์ชัน client.DownloadData(url) โดยผลลัพธ์ที่ได้ มีดังนี้ ถ้าไม่มีไฟล์อยู่ก็จะตอบกลับมาเป็น “File not found.” ถ้ามีไฟล์ระบบจะตอบกลับมาว่ามีจริง ซึ่งหวังว่าจะมีประโยชน์ไม่มากก็น้อยค่ะ
เนื่องจากช่วงนี้ ผู้เขียนมีโอกาสได้เข้ามาอยู่ในแวดวงของ Dojo และได้ประสบกับปัญหาในการที่จะ set property ของ Dojo ซึ่งในที่นี้คือ Radio Button หลังจากที่ได้ลองผิด ลองถูก Error กันหัวหมุน จนสุดท้ายได้เจอทางออก เลยอยากจะบันทึกไว้สำหรับตัวเองมาดูในอนาคต และเผื่อท่านอื่นที่ประสบปัญหาเดียวกัน มาเจอจะได้ลองนำไปใช้งานกันดูค่ะ Let’s GO!!! เนื่องจาก Radio Button เป็น Control ภายใต้ dijit/form/RadioButton ดังนั้น การเขียนคำสั่งเพื่อ set property จึงได้เป็นดังนี้ dijit.byId(‘control_id‘).set(‘control_prop‘, value); control_id : id ของ control นั้น ๆ control_prop : property ของ control ที่ต้องการกำหนดค่า value : ค่าที่ต้องการกำหนด ตัวอย่างเช่น ต้องการกำหนดให้ radio button ที่มี id=”rdBtn1″ ไม่สามารถใช้งานแต่ยังแสดง(disable) และ id=”rdBtn2″ มีค่าโดยปริยายเป็นเลือกไว้ จะเขียน Code ได้ดังนี้ dijit.byId(‘rdBtn1’).set(‘disabled’, true); dijit.byId(‘rdBtn2’).set(‘checked’, true); ซึ่ง properties ของ control ต่าง ๆ สามารถดูเพิ่มเติมได้จากเว็ปเพจของ Dojo ตามลิงค์นี้ค่ะ Dojo Documentation หวังว่าบทความนี้จะเป็นประโยชน์แก่ท่านผู้อ่านไม่มาก็น้อยนะคะ แล้วพบกันใหม่ตอนหน้าค่ะ
วันนี้จะมาพูดถึง Firebug ซึ่งหลาย ๆ คนคงใช้งานหรือรู้จักกันอยู่แล้ว แต่ผู้เขียนเพียงแค่นำส่วนที่ใช้งานมาแบ่งปันสำหรับผู้ที่ยังไม่เคยใช้งานค่ะ Firebug เป็นเครื่องมือสำหรับ Web Development ในการแก้ไขตรวจสอบ JavaScript / CSS / HTML เป็น Extension หรือ Add-ons สำหรับใช้ในการช่วยจัดการ Debug พวก HTML , JavaScript และ CSS การใช้งานไม่ยาก โดยทำการติดตั้ง Plugin ลงใน Web Browser เช่น Google Chrome หรือ Mozilla Firefox หลังจากนั้นก็เปิด URL หรือเว็บไซต์ที่ต้องการ และทำการคลิกที่ Icon ของ Firebug จากนั้นโปรแกรม Firebug ก็จะแสดงรายละเอียดโครงสร้าง HTML , JavaScript และ CSS ทั้งหมดใน URL นั้น ๆ เราสามารถทำการคลิกเพื่อแก้ไข CSS หรือแม้กระทั่งตรวจสอบค่าต่าง ๆ ซึ่งการใช้งานนั้นไม่ยากซับซ้อนอะไร ผู้เขียนได้ใช้ Firebug กับการทำงานโดยใช้การ debug ที่แท็บ Console ตัวอย่างดังนี้ เมื่อมีการแจ้งจากผู้ใช้งานระบบว่าข้อมูลแสดงไม่ครบถ้วน จึงทำการตรวจสอบ Service ที่ดึงข้อมูลดังกล่าว โดยใช้ Firebug ในการตรวจสอบ คลิก Service ที่ต้องการจะแสดงข้อมูลดังนี้ (จะเห็นได้ว่าจากรูปด้านบนแสดงเวลาที่โหลดข้อมูลแต่ละคำสั่งด้วยค่ะ) ในส่วนอื่น ๆ ก็สามารถศึกษาได้ไม่ยากค่ะ
API คืออะไร? API ย่อมาจาก Application Programming Interface คือการพัฒนาโปรแกรมสำหรับเป็นส่วนติดต่อเซอร์วิสของแอพพลิเคชั่น หรือโมดูลต่างๆ เพื่อให้คนภายนอกมาเรียกใช้งาน หรือกล่าวอย่างง่ายๆ ก็คือการเขียนโปรแกรมเพื่อให้บริการสำหรับให้คนอื่นมาเรียกใช้งาน ซึ่งแนวคิดเรื่องการสร้าง API เพื่อการใช้งานก็มีมาอย่างยาวนานแล้ว ยกตัวอย่างเช่นตั้งแต่ที่มีการสร้างระบบปฎิบัติการ (OS) ก็จะมีการติดต่อ API ของไดร์เวอร์อุปกรณ์ฮาร์แวร์ต่างๆ ของเครื่องคอมพิวเตอร์เพื่อเรียกใช้งานอุปกรณ์นั้นๆ ตามคำสั่งของนักพัฒนา
ปัญหาของ PSU Webmail ในช่วง 9-15 สิงหาคม 2559 ที่ผ่านมา คือ เมื่อเริ่มเข้าสู่เวลาราชการ ในวันทำการ พบว่า มีการตอบสนองที่ช้า บางครั้งต้องรอถึง 15-20 วินาที หรือ ผู้ใช้บางท่านแจ้งว่า Timeout ไปเลย หรือไม่ก็ใช้งานไปสักพัก ถูกดีดกลับมาหน้า Login ใหม่ แต่เมื่อพ้นเวลาราชการ พบว่าการตอบสนองก็เร็วขึ้นดังเดิม รวมถึงในช่วงวันหยุดก็เร็วอย่างที่ควรเป็น ขอบคุณทาง NetAdmin ที่ทำระบบตรวจสอบไว้ที่หน้า Data Center เพื่อตรวจจับความเร็วในการตอบสนองบริการ PSU Webmail ด้วย SmokePing ผลที่ได้เป็นดังภาพ จะเห็นว่า มีความหน่วงในการตอบสนอง เฉพาะในวันเวลาราชการเท่านั้น … ทำไม ??? ทำการตรวจสอบด้วยคำสั่ง ps aux |grep apache| wc -l เพื่อดูว่า มีจำนวน Apache อยู่กี่ Process พบว่า ในช่วงเวลาที่ระบบหน่วง มี Process เกือบคงที่ที่ 150 แต่ในช่วงที่ระบบทำงานได้เร็ว มีจำนวนประมาณ 50 process จากการศึกษา พบว่า Apache2 ที่ใช้ MPM Prefork นั้น จะจำกัดค่า MaxRequestWorkers ไว้ โดยหากไม่กำหนดค่าใดๆจะตั้งไว้ที่ 256 แต่เมื่อตรวจสอบในไฟล์ /etc/apache2/mods-enabled/mpm_prefork.conf พบว่า <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 150 MaxConnectionsPerChild 0 </IfModule> ทำให้เพดานของจำนวน Process ไปจำกัดที่ 150 ดังที่ตรวจสอบเบื้องต้น เมื่อมีผู้ใช้มากขึ้นกว่าเดิม จึงทำให้ Process ไม่เพียงพอต่อความต้องการ เป็นผลให้เกิดการหน่วงขึ้น จึงทำการแก้ไข MaxRequestWorkers เป็น 256 แล้ว Restart Apache ผลทำให้ จำนวน Apache Process ขึ้นไปถึง 200 Process และการตอบสนองเร็วขึ้นตามที่ควรเป็นดังภาพ (หลังเวลา 14:45) ทั้งนี้ การกำหนดจำนวน MaxRequestWorkers นั้น ต้องสัมพันธ์กับ RAM ของ Server ด้วย โดยมีสูตรคร่าวๆ คือ จำนวน RAM ในหน่วย MB หารด้วยขนาดของ Apache Process โดยเฉลี่ย เช่น มี RAM 4GB = 4 x 1024 = 4096 ขนาดเฉลี่ย Apache Process = 20 ดังนั้น MaxRequestWorkers = 4096/20 = 204 แต่จริงๆแล้ว ควรเผื่อ Memory ไว้ให้ OS และอื่นๆด้วย (อาจจะไม่เต็ม 4096) หากขยับค่า MaxRequestWorkers แล้วยังพบว่า จำนวน Process ยังขึ้นไปเต็มเพดานอยู่ ควรพิจารณาเพิ่ม Memory ด้วย ประมาณนี้ครับ UPDATE: ผลการปรับแก้ไข ทำให้ เวลาในการตอบสนอง จากที่หน่วง 10 วินาที เหลือ เพียง 50 มิลลิวินาที ดังภาพ