(พื้นฐาน)การแก้ Race Condition อย่างงาย โดยไม่ใช้ Semaphore by

30
Jun
0

Race Condition ก็คือปัญหา การที่ข้อมูลกลางของระบบ (Global Variable) ถูกแก้ไขพร้อมๆกัน และ save เข้าไป พร้อมๆกัน ดังนั้นแนวทางการแก้ไขพื้นฐานของปัญหา Race condition ก็คือ หากคุณมีข้อมูลขนาดใหญ่ที่เป็นข้อมูลที่ถูกใช้จากหลายๆจุดพร้อมๆกัน คุณควรแบ่งข้อมูลนั้นๆ ออกเป็นขนาดเล็กที่สุดเท่าที่จะทำได้ และการอ่าน และเขียนข้อมูลใดๆควรทำที่จุดที่เล็กที่สุดนั้น วิธีการนี้จะช่วยลดปัญหา Race condition ได้ในระดับหนึ่ง แต่หากปัญหา Race condition ที่คุณเจอนั้น ไม่ได้เกิดจาก กรณีนี้แล้วล่ะก็ คุณก็คงต้องใช้ Semaphore ช่วยแล้วล่ะ ….

วิธีการลดความกระตุกของภาพเมื่อมีการ render iso จำนวนมาก by

30
Jun
0

โดยปกติแล้วเวลาที่เรามีการปรับเปลี่ยนตำแหน่งของ object (ในที่นี้คือ isoSprite) ใน isoScene ของเรา เราก็ต้องทำการ สั่ง render() isoScene นั้นใหม่เพิ่อที่จะจัดเรียง z index หรือความลึกตื้นของ object ว่าชิ้นไหนควรอยู่หน้าหลัง แต่เมื่อเราได้ทำแผนที่ขนาดใหญ่ซึ่งมีจำนวน object ปริมาณมากๆ สิ่งที่ตามมาคือ Frame per sec ของเราจะตกลงอย่างมาก (หรือง่ายๆคือเกมกระตุกมากนั่นเอง) ซึ่งวันนี้จะมาเสนอวิธีแก้ไขปัญหาดังกล่าว

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


public function limitedIsoRender(scene:IsoScene,limit:int=10):void{ //รับ isoScene ที่จะจำกัด object(เขียนไว้เผื่ออนาคตมีการ render หลายๆ scene) และ limit คือระยะของช่องการมองเห็นของผู้ใช้
for(var i:int=0;i<aObjectData.length;i++){
for(var j:int=0;j<aObjectData[i].length;j++){ //วนลูปตามจำนวนช่องทั้งหมดเพื่อนำมาเช็คในบรรทัดถัดไป
if(aIsoMap[i][j]!=null){
if(aIsoMap[i][j].sprite!=null){
if(scene.contains(aIsoMap[i][j].sprite)){
scene.removeChild(aIsoMap[i][j].sprite); //ถ้าอยู่นอกระยะการมองเห็นเราก็จะนำมันออกจาก scene ก่อนเพื่อลดอาการกระตุกในการ render
}
}
}
}
else{
if(aIsoMap[i][j]!=null){
if(aIsoMap[i][j].sprite!=null){
if(!scene.contains(aIsoMap[i][j].sprite)){
aIsoMap[i][j].sprite.moveTo(CELL_SIZE*(i), CELL_SIZE*(j),0);
aIsoMap[i][j].sprite.setSize(CELL_SIZE,CELL_SIZE,CELL_SIZE);
scene.addChild(aIsoMap[i][j].sprite); //ถ้าอยู่ในระยะการมองเห็นก็จับมาใส่ใน scene เพื่อรอ render
}
}
}
}
}
}
scene.render(); //เมื่อครบลูปแล้วค่อยทำการ render ครับ
}

ซึ่งผลลัพธ์เห็นผลได้อย่างชัดเจนมากครับ

ถ้าเรา render ปกติก็ต้อง render object จำนวนมหาศาลตามรูป ซึ่งกระตุกสุดๆครับ

ถ้าเรา render ปกติก็ต้อง render object จำนวนมหาศาลตามรูป ซึ่งกระตุกสุดๆครับ

(กดเพื่อดูรูปใหญ่) ภาพของเกมที่ใช้การ render ปกติซึ่งกรอบการมองเห็นที่จริงแล้วเป็นเพียงซ้ายบนจอตามกรอบ UI เท่านั้น มี object จำนวนมากที่เกินขอบการมองเห็นแต่ยังมีอยู่เพื่อ render

(กดเพื่อดูรูปใหญ่) ภาพของเกมที่ใช้การ render ปกติซึ่งกรอบการมองเห็นที่จริงแล้วเป็นเพียงซ้ายบนจอตามกรอบ UI เท่านั้น มี object จำนวนมากที่เกินขอบการมองเห็นแต่ยังมีอยู่เพื่อ render

พอผ่านฟังก์ชั่น limitedRender ที่จำกัดการมองเห็นไว้ที่ 10 รอบๆตัวละคร object ใน scene ก็เหลืเพียงร้อยกว่าตัวเท่านั้น ซึ่ง render ได้สบายๆ

พอผ่านฟังก์ชั่น limitedRender ที่จำกัดการมองเห็นไว้ที่ 10 รอบๆตัวละคร object ใน scene ก็เหลืเพียงร้อยกว่าตัวเท่านั้น ซึ่ง render ได้สบายๆ

(กดเพื่อดูรูปใหญ่) จะเห็นได้ว่าเมื่อผ่านฟังก์ชั่นแล้วปริมาณจะไม่มากแล้ว

(กดเพื่อดูรูปใหญ่) จะเห็นได้ว่าเมื่อผ่านฟังก์ชั่นแล้วปริมาณจะไม่มากแล้ว

AWS กับการทดลองใช้งาน by

30
Jun
0

มีโอกาสได้ทดลองใช้งาน AWS ก็พบว่าใช้ยากโคตรๆ เครื่องมือมันเยอะไปหมดจนไม่รู้จะทำอะไร เริ่มตรงไหน ยังไง แนะนำว่าต้องมีความรู้ System Admin ในระดับกลางค่อนไปทางสูงนะครับถึงจะใช้งานได้ดั่งใจ สถาปัตยกรรมทาง hardware สุดท้ายเราก็ยังต้องรู้อยู่ดี หากใครเป็น Programmer ที่ไม่มีความรู้ System Admin มากนักแนะนำให้ไป Heroku จะง่ายกว่ามาก ก่อนอื่นแนะนำให้ไปอ่านบทความสองที่นี้ซะก่อนเพื่อให้มองเห็นภาพรวมการใช้งาน

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

สำหรับค่าใช้จ่ายของ AWS มักจะคิดเป็นรายชั่วโมง ดูตัวเลขก็เหมือนจะถูกดี คิดเฉพาะที่ใช้งาน ถ้าคุณใช้แค่วันเดียวเลิก โอเคมันคุ้มแน่ๆ เสียตังไม่กี่บาท แต่ถ้าจะใช้งานระยะยาวแล้วจะใช้ได้คุ้มต้องศึกษาข้อมูลเป็นอย่างดีเสียก่อน ต้องศึกษาดีๆ เทียบกับ VPS ทั่วๆ ไปด้วยเพราะ performance ต่อราคาที่ AWS ให้นั้นไม่ได้ดีอย่างที่คิด อย่างไรก็ตามลองอ่านสิ่งต่างๆ เหล่านี้ แล้วจำไว้ให้ดี

  1. Cloud ไม่ใช่พระเจ้า หลากหลายข้อดีของมันนั้น แลกมาซึ่งประสิทธิภาพที่ลดลง
  2. การใช้ Server Hardware แล้วเสียเฉพาะค่า Colo + ค่าจ้าง System Admin ถูกที่สุดเสมอในการใช้งานระยะยาว รวมไปถึง Performance เทียบราคาแล้วจะดีกว่า Cloud แน่นอนอย่างไม่ต้องสงสัย
  3. หากคุณต้องการแค่พื้นที่ส่วนตัว, OS ส่วนตัว แต่ไม่อยากยุ่งยากเรื่องค่าใช้จ่ายที่อาจบานปลาย แนะนำให้เช่า VPS จะ control ค่าใช้จ่ายได้ง่ายกว่า
  4. Cloud ไม่ใช่การใช้งานส่วนตัว คุณ share ทรัพยากรร่วมกับผู้อื่นแทบทุกอย่าง แม้จะมี disk,OS แยกจากชาวบ้าน แต่คุณยังต้องแชร์ CPU, I/O กับชาวบ้านเสมอ โอกาสที่จะใช้งานได้เร็วกว่าเครื่องจริงมีน้อยมาก เนื่องจากทุกอย่างต้อง share กับชาวบ้านหมด
  5. การใช้งาน Cloud คือการแลก Performance ที่แย่ลง (เพราะใช้ Virtual Machine และ share กับชาวบ้าน) กับความยืดหยุ่นในการออกแบบ Architecture ทาง hardware เพราะคุณจะมี hardware เสมือน (VM) กี่เครื่องก็ได้ สร้างเมื่อต้องการจะใช้ และลบเมื่อไม่ใช้ หากเป็นการใช้งานแบบนานๆ ใช้ที ไม่ต้องเปิดใช้ตลอด จะคุ้มแน่นอนเพราะคิดเป็นรายชั่วโมง ดีกว่าจ่ายค่าเช่า colo แล้วนานๆ ใช้ที
  6. สิ่งที่เป็นปัญหาของ Cloud ทุกๆ เจ้าคือการเขียนอ่านลง disk จะมี performance แย่กว่าเครื่องจริงหลายเท่า ดังนั้นการใช้งาน Database หนักๆ IOPS เยอะๆ อาจไม่ใช่เรื่องดีนักบน Cloud
  7. อย่างไรก็ตาม AWS ก็แก้ปัญหา IOPS ด้วยการออก EBS แบบ Provisioned IOPS ซึ่งสามารถแยก I/O ตัวเองออกจากคนอื่นได้ดีกว่าแบบปกติ ส่งผลให้การทำงานไม่ขึ้นๆ ลงๆ มีความเสถียรมากกว่าเดิม แต่ก็แลกมากับราคาที่สูงขึ้นพอสมควร โดยแบบ 4000 IOPS นั้น(สูงสุดในเดือนมิ.ย.56 นี้) ราคาจะตกเดือนละ $400 หรือ หมื่นสองพันบาท ลองคิดว่าเราซื้อ SSD 128GB มาใช้เองไม่เกินห้าพันแถมจ่ายครั้งเดียวจบ ยังไงราคาก็ต่างกันราวฟ้ากับเหว แถมได้ค่า IOPS เกินหมื่นอีกต่างหาก
  8. จากการทดลองใช้ CPU รุ่นธรรมดานั้นช้ามาก ขนาดปรับเป็น High-CPU ขั้นแรกยังรู้สึกว่ารับได้ไม่มากเลย หากปรับสูงกว่านั้นก็จะเริ่มแพงมากแล้ว ซึ่งเลยจุดที่ไปเช่า VPS ถูกๆ เอาคุ้มกว่ามาก
  9. ค่าใช้จ่ายคิดเป็นรายชั่วโมง เหมือนจะน้อย แต่ว่าจะมีค่าใช้จ่ายทั้งหมด 4 อย่างที่คุณต้องจ่ายแน่ๆ และประมาณการต่อเดือนลำบากมาก โดยส่วนที่แพงที่สุดคือ Bandwidth และ IOPS
    • ค่า CPU/Memory
    • ค่า Bandwidth -> ส่วนที่ประมาณได้ยากที่สุด และแพงที่สุด
    • ค่าปริมาณ Storage ที่ใช้งาน -> หน่วยเป็น GB
    • ค่า IOPS (ค่า I/O ยิ่งสูงยิ่งแพง) -> แพงรองลงมา และประมาณได้ยากเป็นอันดับสอง
  10. AWS จะมีบริการเสริมเช่น RDS (MySQL Database), DNS, Load Balancer แต่ทั้งนี้ทั้งนั้นแนะนำว่าสร้าง OS มาติดตั้ง software เองดีกว่านะ (ถ้าทำเป็น) เพราะจะ config ได้มากกว่ามาก และราคาถูกกว่ามาก
  11. หากต้องการประหยัดค่า Bandwidth อาจะพิจารณาใช้ CDN cloudflare.com ช่วยเพราะจ่ายเหมาเป็นรายเดือนช่วย cache static content
  12. ข้อดีอย่างหนึ่งที่ผมชอบมากใน AWS คือ Elastic IP ซึ่งทำให้สามารถเรา setup server อีกเครื่องแยกต่างหาก แล้วเปลี่ยนการผูก IP จากเครื่อง A ไปเครื่อง B ได้เลยแบบไม่มี down time และไม่ต้องแก้ DNS เลย สะดวกมาก

ต่อไปเป็น Note สรุปการใช้งานของผมเองดังนี้

  • EBS คือ Harddisk, S3 คือ SAN
  • ข้อดีอย่างหนึ่งของ AWS คือเป็นรายใหญ่ มีหลาย Region ให้เลือกทั่วโลก สามารถ Copy AMI Image ข้าม Region ได้ ค่อนข้างสะดวกในการเปิด server หลายๆ ที่
  • EBS แบบ Provisoned IOPS จะดีกว่าเฉพาะ Random Read/Write เท่านั้น การทำงานแบบ Sequential Read/Write จะทำได้พอๆ กับแบบ Standard ซึ่งถูกกว่า
  • ระหว่าง Backup AMI ระบบจะปิด Image เพื่อ Backup อัตโนมัติ ระหว่างปิดเว็บจะใช้งานไม่ได้ ต้องระวังตรงจุดนี้
  • การ Stop Instace จะทำให้เราไม่ต้องจ่ายค่า CPU/Memory แต่เรายังต้องจ่ายค่า Storage ที่เก็บพื้นที่ใช้งานนั้นไปเรื่อยๆ จนกว่าจะ Terminate Server ทิ้ง
  • หาก AWS ไม่สามารถตอบสนองการใช้งาน IOPS ที่เราต้องการได้ (ยังใช้งาน disk หนักเกินขนาดอยู่) มีทางเลือกคือทำ Raid 0 ใน EBS ต่อหลายๆ ตัวเพื่อเพิ่ม performance I/O ได้
  • หาก AWS ล่มใน Region ใด Region หนึ่ง เป็นความรับผิดชอบของเจ้าของเว็บเองที่ต้องมี Mirror site ที่คนละ Region ไว้เองด้วย (AWS ก็ล่มได้นะ ไม่ใช่ไม่เคยล่ม และเคยล่มมากกว่า 1 ครั้งด้วย)
  • Raid 10 ยังจำเป็นอยู่หาก AWS ล่มไปบางส่วน จะยังคงมี disk บางส่วนที่ยังทำงานได้
  • การใช้ SSH Keys access เข้าเครื่อง Server ต้องใช้ puttygen เปิดไฟล์ที่ดาวน์โหลดมาจาก AWS เลือก Type เป็น SSH-1 (RSA) แล้วจึงกดเซพ private key ถึงจะสามารถนำ private key นั้นๆ ไปใช้งานได้ด้วย username ubuntu
  • การแก้ไข port firewall ที่เปิดปิด สามารถแก้ไขได้ไที่ Network & Security -> Security Group เพิ่ม Inbound ส่วนที่ต้องการเช่น 22, 80, 443, 3306 ลงไป

สรุปแล้วการใช้งาน Cloud ข้อดีหลักๆ คือใช้เพื่อทดสอบว่า Application ที่เราทำขึ้นนั้น ใช้งานหนักไปในด้านไหน และหากมีคนเข้าเยอะๆ จนนิ่งเมื่อไร จึงค่อยพิจารณาซื้อ hardware จริงให้รองรับจำนวนคนเข้าได้พอดี จะดีที่สุดเพราะถึงแม้ hardware จริงจะราคาถูกกว่าเช่า cloud แต่ข้อเสียของ hardware คือจะ upgrade ทีนึงต้องวิ่งไปที่ Data Center อยู่ดี ที่เป็นหลัการที่ Zynga ใช้ครับ ส่วนใครอยากใช้ cloud และไม่เกี่ยงว่ามันตั้งอยู่ที่ US แนะนำให้ลอง Joyent นะครับ คิดเป็นรายชั่วโมง และไม่มี hidden cost มากมายทั้ง Bandwidth, Storage, IOPS แบบ aws และที่สำคัญ ถูกกว่ามากเมื่อเทียบ performance ที่ได้รับ หากใช้แบบ SmartOS (เป็น Solaris) จะยิ่งได้ performance เทียบเคียงเครื่องจริงเลยละครับ :) (เสียอย่างเดียวให้พื้นที่ HDD น้อยไปหน่อย) ขอให้โชคดีทุกคนครับ :)

กำจัด Pathขยะ(ส่วนเกินจากการวาด Path) [Illustrator] by

30
Jun
0

บางทีในการทำงานที่มีรายละเอียดเยอะ ในIllustrator ก็ทำให้มีพวกส่วนเกิน สิ่งที่ไม่ต้องการ หลงเหลืออยู่ในชิ้นงาน เช่น จุด Path

ซึ่งสามารถมองเห็นได้ยากมาก แต่มีวิธีง่ายๆ ไว้กำจัด Pathขยะพวกนี้

เริ่มจาก  Ctrl+A

ไปที่ Object>Path>Clean Up

กด OK

Pathขยะที่เป็น Pathจุดเดียวก็จะหายไปโดยอัตโนมัติ จะเหลือไว้เพียงPathแบบ 2จุด โปรแกรมก็จะ Select ส่วนนั้นไว้ให้เพื่อถามว่าจะเก็บส่วนนี้ไว้รึเปล่า…ถ้าไม่ ก็กด Delete

ศัำพท์+ตัวย่อต่างๆที่สำคัญในการวิเคราะห์ Revenue ของเกม by

30
Jun
0

MAU – Monthly Active Users จำนวนคนเล่นต่อเดือน

DAU – Daily Active Users จำนวนคนเล่นต่อวัน

RU - Registered Users จำนวนคนสมัครเข้าเล่นเกม

BU – Buying Users จำนวนคนที่เติมเงิน

ARPU – Average Revenue Per User รายได้ต่อหัวของคนเล่นทั้งหมด
คำนวณได้จาก Revenue ÷ MAU ก็จะได้ ARPU ต่อเดือน
หรือ ถ้าต้องการทราบ ARPU ต่อวัน ก็นำ Revenue(ต่อวัน) ÷ DAU

ARPPU – Average Revenue Per Paying User รายได้ต่อหัวของคนที่จ่ายเงิน
คำนวณได้จาก Revenue ÷ BU(ทั้งเดือน) ก็จะได้ ARPPU ต่อเดือน
เช่นเดียวกัน ถ้าต้องการ ARPPU ต่อวัน ก็นำไปหารด้วย DAU

Conversion Rate – เปอร์เซ็นต์จำนวนคนเล่นที่จ่ายเงินต่อคนเล่นทั้งหมด
คำนวณได้จาก BU ÷ MAU x 100 ก็จะได้เป็นเปอร์เซ็นต์ออกมาครับ

เพิ่มเติมอีกข้อนึงคือ
CCU – Concurrent Users จำนวนคนเล่นที่ออนไลน์พร้อมๆกัน มักจะใ้ช้กับการวิเคราะห์ Traffic เพื่อทำให้ server รองรับคนเล่นได้

กู้เงิน | เศรษฐกิจพอเพียง | สินเชื่อบุคคล | สมัครบัตรกดเงินสด | สินเชื่อ | เงินกู้ด่วน | ยืมเงินทรูมูฟ | เงินด่วนนอกระบบ