การเร่งความเร็วแอพพลิเคชัน: ประสิทธิภาพที่เร็วขึ้นสำหรับผู้ใช้

โดย Techopedia Staff วันที่ 2 พฤศจิกายน 2016

Takeaway: Host Eric Kavanagh กล่าวถึงประสิทธิภาพของแอพพลิเคชั่นและวิธีปรับปรุงประสิทธิภาพกับ Dr. Robin Bloor, Dez Blanchfield และ Bill Ellis ของ IDERA

คุณยังไม่ได้เข้าสู่ระบบโปรดเข้าสู่ระบบหรือลงทะเบียนเพื่อดูวิดีโอ

Eric Kavanagh: ท่านสุภาพบุรุษและสุภาพสตรีสวัสดีทุกท่านและยินดีต้อนรับกลับมาที่ Hot Technologies อีกครั้ง ใช่แน่นอน! ชื่อของฉันคือ Eric Kavanagh ฉันจะเป็นเจ้าภาพของคุณสำหรับเว็บคาสต์อื่นในวันนี้ในซีรีย์ที่สนุกและน่าตื่นเต้นนี้ที่เราได้รับจากการชมซีรีย์ห้องบรรยายสรุปของเรา ชื่อคือ“ การเร่งความเร็วแอปพลิเคชัน: ประสิทธิภาพที่เร็วขึ้นสำหรับผู้ใช้ปลายทาง” มาที่คนที่ไม่ต้องการหรือไม่ ถ้าฉันเป็นคนที่แต่งตัวประหลาดที่นั่นช่วยให้แอปพลิเคชันของคุณทำงานได้เร็วขึ้นฉันคิดว่าฉันเป็นคนที่ซื้อเบียร์ให้ฉันที่บาร์หลังเลิกงาน มันจะต้องเป็นสิ่งที่ยอดเยี่ยมมากที่จะเดินเข้ามาและเร่งความเร็วแอปพลิเคชันของทุกคน

มีสไลด์เกี่ยวกับตัวคุณอย่างแท้จริงมาหาฉันที่ Twitter @Eric_Kavanagh ฉันมักจะพยายามติดตามและฉันจะทวีตซ้ำถ้าคุณพูดถึงฉันดังนั้นอย่าลังเลที่จะพูดถึงฉัน

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

วันนี้เรากำลังพูดถึงการเร่งความเร็วแอพพลิเคชัน เราจะได้ยินจาก Dez Blanchfield และ Doctor Robin Bloor - เราทุกคนทั่วโลกในวันนี้ - แล้ว Bill Ellis กำลังโทรจากพื้นที่เวอร์จิเนียที่มากขึ้น ด้วยสิ่งนี้ฉันจะมอบให้ดร. บลอร์คนแรกของเรา เราทวีตแฮชแท็กของ #podcast แล้วดังนั้นอย่าลังเลที่จะทวีต เอามันออกไป.

Dr. Robin Bloor: โอเคขอบคุณมากสำหรับการแนะนำครั้งนั้น ประสิทธิภาพของแอปพลิเคชั่นและระดับการให้บริการ - นี่เป็นพื้นที่ชนิดหนึ่งฉันได้ทำงานมากมายในพื้นที่นี้ในช่วงหลายปีที่ผ่านมาในความจริงฉันได้ทำงานมากมายในการตรวจสอบประสิทธิภาพและทำงานในที่เดียว วิธีการอื่นและวิธีการลองและคำนวณระดับเหล่านั้น ต้องบอกว่าจนกระทั่ง - เราเคยมียุคนี้เมื่อไม่นานมานี้ซึ่งผู้คนสร้างระบบในไซโล โดยทั่วไปปริมาณงานที่พวกเขาต้องทำเพื่อให้ระบบทำงานได้ดีพอสมควรถ้ามันอยู่ในไซโลไม่ได้ยากเกินไปเพราะมีตัวแปรจำนวนน้อยมากที่คุณต้องคำนึงถึง ทันทีที่เราได้รับเครือข่ายที่เหมาะสมการโต้ตอบและการให้บริการเข้ามาในสมการ มันยากนิดหน่อย ประสิทธิภาพอาจเป็นมิติเดียว หากคุณคิดว่าแอปพลิเคชันที่รันโค้ดพา ธ เฉพาะซ้ำ ๆ ให้ทำอย่างสมเหตุสมผลในเวลาที่เหมาะสมให้ความรู้สึกเหมือนเป็นมิติเดียว ทันทีที่คุณเริ่มพูดถึงระดับการให้บริการคุณกำลังพูดถึงหลายสิ่งหลายอย่างที่แข่งขันกับทรัพยากรคอมพิวเตอร์ มันกลายเป็นหลายมิติอย่างรวดเร็ว หากคุณเริ่มพูดคุยเกี่ยวกับกระบวนการทางธุรกิจกระบวนการทางธุรกิจสามารถรวมเข้าด้วยกันจากหลายแอปพลิเคชัน หากคุณกำลังพูดถึงสถาปัตยกรรมที่มุ่งเน้นการบริการดังนั้นแอปพลิเคชันที่กำหนดสามารถเข้าถึงความสามารถของแอพพลิเคชั่นหลายตัวได้ จากนั้นมันจะกลายเป็นสิ่งที่ซับซ้อนมาก

ฉันดูที่ - นานมาแล้วฉันวาดไดอะแกรมนี้ แผนภาพนี้มีอายุอย่างน้อย 20 ปี โดยทั่วไปฉันเรียกมันว่า Diagram of Everything เพราะมันเป็นวิธีการดูทุกสิ่งที่มีอยู่ในสภาพแวดล้อมด้านไอที จริงๆแล้วมีเพียงสี่ชิ้นเท่านั้น: ผู้ใช้ข้อมูลซอฟต์แวร์และฮาร์ดแวร์ แน่นอนว่ามันเปลี่ยนไปตามกาลเวลา แต่คุณรู้จริงเมื่อคุณมองสิ่งนี้ว่ามีการระเบิดตามลำดับชั้นของชิ้นส่วนเหล่านี้แต่ละชิ้น ฮาร์ดแวร์ใช่ฮาร์ดแวร์สามารถเป็นเซิร์ฟเวอร์ได้ แต่เซิร์ฟเวอร์ประกอบด้วย CPU หลายตัวเทคโนโลยีระบบเครือข่ายและหน่วยความจำและนี่เป็นตัวควบคุมที่น่ากลัวอย่างมากเมื่อมันเกิดขึ้น ถ้าคุณดูที่นี่จริงๆมันก็จะแตกออกเป็นชิ้น ๆ หากคุณคิดเกี่ยวกับการพยายามปรับแต่งทุกอย่างที่เกี่ยวกับข้อมูลที่เปลี่ยนแปลงการเปลี่ยนแปลงประสิทธิภาพของซอฟต์แวร์เนื่องจากการเปลี่ยนแปลงของฮาร์ดแวร์และอื่น ๆ คุณกำลังมองสถานการณ์ที่หลากหลายที่ยากอย่างไม่น่าเชื่อ นี่คือเส้นโค้งความซับซ้อน แน่นอนว่ามันเป็นเรื่องซับซ้อนสำหรับทุกสิ่ง แต่ฉันได้เห็นเวลาและอีกครั้งเมื่อพูดถึงคอมพิวเตอร์ โดยทั่วไปถ้าคุณวางโหนดบนแกนหนึ่งและการเชื่อมต่อที่สำคัญในแกนอื่น ๆ คุณจะพบกับเส้นโค้งที่ซับซ้อน เกือบจะไม่สำคัญว่าโหนดและการเชื่อมต่อคืออะไรและจะทำอย่างไรถ้าคุณต้องการแสดงการเติบโตของปริมาณในเครือข่ายโทรศัพท์

ในความเป็นจริงเมื่อพูดถึงโหนดในระบบคอมพิวเตอร์คุณกำลังพูดถึงสิ่งที่สนใจซึ่งกันและกัน ความซับซ้อนมันกลายเป็นเรื่องของโครงสร้างที่หลากหลายและข้อ จำกัด ต่างๆที่คุณกำลังพยายามที่จะเชื่อฟัง นอกจากนี้ตัวเลข เมื่อตัวเลขสูงขึ้นพวกเขาก็บ้าไปแล้ว ฉันมีการแชทที่น่าสนใจเมื่อวานนี้ฉันกำลังพูดคุยกับใครบางคน - ฉันไม่สามารถพูดถึงว่าเขาเป็นใคร แต่มันไม่สำคัญ - พวกเขากำลังพูดถึงเว็บไซต์ที่มี 40, 000 - นั่นคือสี่ศูนย์ศูนย์ 40, 000 - อินสแตนซ์ของฐานข้อมูล ในเว็บไซต์ แค่คิดว่า - 40, 000 ฐานข้อมูลที่แตกต่างกัน แน่นอนสิ่งเดียวที่เรามี - พวกเขาเห็นได้ชัดว่ามีแอปพลิเคชั่นมากมายหลายพันรายการ เรากำลังพูดถึงองค์กรขนาดใหญ่มาก แต่ฉันไม่สามารถตั้งชื่อได้ คุณมองไปที่สิ่งนั้นจริง ๆ แล้วคุณกำลังพยายามที่จะรับระดับการบริการที่เพียงพอสำหรับผู้ใช้หลายคนโดยมีหลายวิธีหากคุณต้องการความคาดหวัง มันเป็นสถานการณ์ที่ซับซ้อนและสิ่งที่ฉันพูดก็คือความซับซ้อนของสิ่งนี้ ตัวเลขเพิ่มขึ้นเสมอ ข้อ จำกัด ถูกกำหนดโดยกระบวนการทางธุรกิจและเป้าหมายทางธุรกิจ คุณจะสังเกตเห็นการเปลี่ยนแปลงความคาดหวัง

ฉันจำได้ทันทีที่ Gmail และ Yahoo mail และ Hotmail ระบบจดหมายเหล่านั้นทั้งหมดเริ่มต้นขึ้นผู้คนเริ่มมีความคาดหวังว่าระบบอีเมลภายในของพวกเขาภายในองค์กรจะได้รับประโยชน์จากระดับการให้บริการของการดำเนินการขนาดใหญ่เหล่านี้ องค์กรและเริ่มถูกกดดันให้ทำสิ่งนั้นเกิดขึ้น ที่จริงแล้วข้อตกลงระดับบริการเป็นสิ่งหนึ่ง แต่ความคาดหวังเป็นอีกเรื่องหนึ่งและพวกเขาต่อสู้กันเองภายในองค์กรซึ่งเป็นเรื่องที่น่าอึดอัดใจ นี่เป็นเพียงมุมมองทางธุรกิจ ในบางระบบเวลาตอบสนองที่ดีที่สุดคือหนึ่งในสิบของเวลาตอบสนองของมนุษย์ที่สอง หนึ่งในสิบของวินาทีคือเวลาที่งูเห่ากัดคุณ หากคุณยืนอยู่หน้างูเห่าและตัดสินใจกัดคุณมันสายเกินไปมันจะเกิดขึ้นเพราะคุณไม่สามารถตอบสนองได้ภายในเวลาสิบวินาที หนึ่งในสิบของวินาทีนั้นประมาณเวลาที่ลูกบอลจะปล่อยมือจากเหยือกเพื่อไปหาผู้ชายด้วยไม้ตี โดยทั่วไปเมื่อเขาเห็นลูกบอลโยนเขาจะต้องตอบสนองในเวลานั้น การตอบสนองของมนุษย์เป็นสิ่งที่น่าสนใจ ซอฟต์แวร์กับซอฟต์แวร์สามารถมีความคาดหวังสูงขึ้นอย่างชัดเจน

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

โอเคนี่คือฉันคิดว่าสไลด์สุดท้ายที่ฉันทำ แต่นี่เป็นเพียงเพื่อให้คุณเห็นภาพรวมของความซับซ้อนเมื่อคุณดูความต้องการขององค์กรการบริการ คุณมีแล้วขึ้นไปทางซ้ายมือที่นี่คุณจะได้รับการจัดการระบบซึ่งเป็นชุดของซอฟต์แวร์ที่ทำหน้าที่ในการจัดการบริการซึ่งกำลังพยายามจัดการระดับการให้บริการ เหนือสิ่งอื่นใดที่คุณได้รับการจัดการประสิทธิภาพทางธุรกิจ ถ้าคุณดูที่ด้านล่างนี่พื้นที่การจัดการบริการอัตโนมัติคุณจะได้รับบริการที่แยกส่วนซึ่งกลายเป็นบริการที่ได้มาตรฐานถ้าคุณสนใจที่จะลงทุนในสิ่งนี้ซึ่งพัฒนาเป็นบริการแบบครบวงจร . สิ่งที่คนส่วนใหญ่ทำคือเฉพาะที่มุมล่างซ้ายของสิ่งนี้ บางทีการจัดการบริการเล็กน้อย การจัดการประสิทธิภาพธุรกิจหายากมาก กระจัดกระจายเกือบทั้งหมด โลกที่สมบูรณ์แบบจะเติมกริดนั้น การประพันธ์ดนตรี - ฉันพูดถึงปัญหาการเพิ่มประสิทธิภาพย่อย คุณสามารถเพิ่มประสิทธิภาพส่วนต่าง ๆ ของระบบและไม่เป็นผลดีต่อทั้งระบบ หากคุณทำให้หัวใจดีที่สุดเลือดของคุณอาจหมุนเวียนเร็วเกินไปสำหรับอวัยวะอื่น ๆ ของคุณ นั่นเป็นปัญหากับองค์กรขนาดใหญ่และระดับการให้บริการ เห็นได้ชัดว่าไม่มีสิ่งใดที่จะเกิดขึ้นได้หากไม่มีเครื่องมือที่ซับซ้อนเพราะตัวแปรเพิ่งได้รับ - มีตัวแปรมากเกินไปที่จะลองและปรับให้เหมาะสม

ต้องบอกว่าฉันจะส่งต่อไปยัง Dez ที่จะพูดถึงเรื่องอื่นอย่างสิ้นเชิงหวังว่า

Dez Blanchfield: ขอบคุณครับ Robin เช่นเดียวกับดร. โรบินบลอร์ฉันใช้เวลาหลายปีในการคิดเกี่ยวกับประสิทธิภาพของระบบที่ซับซ้อนในระดับมาก อาจไม่ใช่ระดับเดียวกับ Robin แต่ประสิทธิภาพเป็นหัวข้อรายวันและเป็นส่วนหนึ่งของ DNA ของเราที่ต้องการประสิทธิภาพเพื่อให้ได้ประโยชน์สูงสุดจากทุกสิ่ง ในความเป็นจริงฉันใช้กราฟิกของสิ่งที่ฉันชอบที่สุดในโลกสูตรหนึ่งในการแข่งรถ Formula I ซึ่งโลกทั้งโลกยังคงอยู่พักหนึ่งและเฝ้าดูรถยนต์หมุนวนเป็นวงกลมอย่างรวดเร็ว ทุกแง่มุมไม่มีสูตรของฟอร์มูล่า 1 ที่ไม่เฉพาะเจาะจงเกี่ยวกับประสิทธิภาพ ผู้คนมากมายชอบเล่นกีฬาเพราะพวกเขาคิดว่ามันเป็นการเสียเงิน มันกลับกลายเป็นว่ารถที่เราขับทุก ๆ วันเพื่อทิ้งลูกฟุตบอลในวันหยุดสุดสัปดาห์และโรงเรียนในวันอื่น ๆ นั้นมาจากการพัฒนาและการวิจัยตามผลงาน มันคือชีวิตของการแข่งรถ Formula I เทคโนโลยีในชีวิตประจำวันวิทยาศาสตร์ในชีวิตประจำวันมักจะมาจากสิ่งที่ชอบซึ่งมุ่งเน้นที่ประสิทธิภาพสูง

แม้ว่าความเป็นจริงคือโลกใหม่ของเรา "อยู่เสมอ" ซึ่งต้องการเวลาทำงาน 100% ตามที่โรบินกล่าวไว้ก่อนหน้านี้ด้วยสิ่งต่าง ๆ เช่นการแนะนำเว็บเมลและบริการอื่น ๆ ที่เราให้ไว้ในพื้นที่ต่อเนื่องและตอนนี้เราคาดหวังว่า องค์กรและสภาพแวดล้อมการทำงานของเรา ความจริงก็คือการขึ้นไม่ได้หมายความว่าคุณจะบรรลุข้อตกลงระดับบริการของคุณ ฉันได้รับสิ่งนี้ในความต้องการในการจัดการประสิทธิภาพของแอปพลิเคชันและข้อตกลงระดับบริการที่มีอยู่นั้นได้รับการเปลี่ยนแปลงขั้นพื้นฐานในทศวรรษที่ผ่านมา เราไม่ได้แค่พยายามกังวลเกี่ยวกับประสิทธิภาพของระบบเดียวอีกต่อไป เมื่อโลกนั้นเรียบง่ายขึ้นเราอาจมีสถานการณ์ที่เซิร์ฟเวอร์เดียวที่ใช้บริการหลายบริการสามารถตรวจสอบการถ่ายทอดสดและมันก็ค่อนข้างตรงไปตรงมาที่จะสนับสนุน เราทำได้ - และนี่คือสิ่งเล็ก ๆ น้อย ๆ ของฉันสิ่งที่เราเคยกังวลเกี่ยวกับเมื่อฉันเป็นผู้ดูแลระบบเช่นเมื่อหลายปีก่อน - เราจะมองไปรอบ ๆ บริการมักจะตอบสนองหรือไม่? ฉันสามารถลงชื่อเข้าใช้เทอร์มินัลได้หรือไม่ ระบบปฏิบัติการตอบสนองและฉันสามารถพิมพ์คำสั่งได้หรือไม่ แอปพลิเคชั่นขึ้นและทำงานอยู่ ฉันสามารถดูกระบวนการและหน่วยความจำในการทำสิ่งต่าง ๆ และ I / O ผ่านเครือข่ายและอื่น ๆ ได้หรือไม่? ในวันเมนเฟรมคุณจะได้ยินเทปที่จะ zip-zip-zip และกระดาษหลุดออกมา

แอพตอบสนองและเราสามารถเข้าสู่ระบบและทำสิ่งต่าง ๆ กับพวกเขาได้หรือไม่? ผู้ใช้สามารถเชื่อมต่อกับเซิร์ฟเวอร์เหล่านั้นได้หรือไม่? มันเกิดขึ้น พวกมันค่อนข้างพื้นฐานคุณรู้ไหม ถ้าอย่างนั้นเป็นเรื่องตลกสองสามข้อ - โต๊ะช่วยเหลือเขียวหรือไม่? เพราะถ้าไม่เช่นนั้นทุกอย่างทำงานได้ดีและใครจะได้รับโดนัท? ชีวิตเรียบง่ายในสมัยนั้น แม้กระทั่งในสมัยนั้นและจากนั้นฉันก็พูดคุยกับ 20-30 ปีก่อนความซับซ้อนยังคงสูงมาก เราสามารถจัดการข้อตกลงระดับการให้บริการและติดตามประสิทธิภาพได้อย่างตรงไปตรงมา เราไม่สามารถทำได้ด้วยมืออีกต่อไปตามที่โรบินพูดถึง ความท้าทายยิ่งใหญ่เกินไป ความจริงคือเวลาที่แอพที่ดีผู้ดูแลระบบเครือข่ายและฐานข้อมูลผู้ดูแลระบบสามารถตรวจสอบและตอบสนอง SLA ของประสิทธิภาพได้ SLA หายไปแล้วตอนนี้ที่ฉันพยายามเมื่อคืนเมื่อฉันใส่บันทึกสุดท้ายของฉันเข้าด้วยกันเพื่อคิดถึงปีที่ฉันพยายามดูระบบของสแต็กที่ซับซ้อนมาก ๆ และเข้าใจมันและเข้าใจสิ่งที่เกิดขึ้น เกิดขึ้นภายใต้ประทุนและฉันมาจากภูมิหลังทางเทคนิคที่ลึกซึ้ง ฉันไม่สามารถจินตนาการได้ว่ามันเป็นอย่างไรที่ต้องเผชิญกับมันแบบวันต่อวันตอนนี้ในรูปแบบการบริหาร

เกิดอะไรขึ้น? ในปี 1996 แอพที่ขับเคลื่อนด้วยฐานข้อมูลได้รับการเปลี่ยนแปลงด้วยความนิยมทางอินเทอร์เน็ต พวกเราหลายคนผ่านพ้นไปแล้ว แม้ว่าคุณจะไม่ได้อยู่ใกล้อินเทอร์เน็ต แต่คุณก็สามารถมองไปรอบ ๆ และตระหนักได้ว่าในชีวิตประจำวันเราได้เชื่อมโยงทุกสิ่งเข้ากับอินเทอร์เน็ตทันที ฉันเชื่อว่าเรามีเครื่องปิ้งขนมปังที่เห็นได้ชัดว่ามาพร้อมกับตัวเลือกในการใช้ Wi-Fi ซึ่งไร้สาระเพราะฉันไม่ต้องการเครื่องปิ้งขนมปังที่เชื่อมต่อกับอินเทอร์เน็ต ในยุค 2000 โดยเฉพาะช่วงต้นยุค 2000 เราต้องรับมือกับการเติบโตอย่างมหาศาลของความซับซ้อนรอบนี้ซึ่งส่งมอบประสิทธิภาพการให้บริการในดอทคอม จากนั้นอีกสิ่งที่น่าหัวเราะอย่างน่าหัวเราะในเว็บ 2.0 ที่สมาร์ทโฟนมาถึงและตอนนี้แอปพลิเคชันอยู่ในมือของเรา 24/7 และอยู่ในโหมดตลอดเวลา

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

หากสิ่งนี้ยังไม่ดีพอเรากำลังจะสร้างปัญญาประดิษฐ์และการใช้ความรู้ความเข้าใจเกี่ยวกับทุกสิ่ง วันนี้เราคุยกับ Siri และ Google engine ฉันรู้ว่า Amazon มีของตัวเอง ไป่ตู้มีหนึ่งในอุปกรณ์เหล่านี้ที่คุณสามารถพูดคุยได้พวกเขาแปลงเป็นข้อความที่เข้าสู่ระบบปกติฐานข้อมูลสร้างแบบสอบถามและกลับมาและย้อนกลับกระบวนการ คิดเกี่ยวกับความซับซ้อนที่เกิดขึ้น ความจริงก็คือความซับซ้อนของแอปพลิเคชั่นมาตรฐานในปัจจุบันมีความซับซ้อนเกินความสามารถของมนุษย์ เมื่อคุณคิดถึงทุกสิ่งที่เกิดขึ้นเมื่อคุณกดปุ่มบนอุปกรณ์สมาร์ทโฟนหรือแท็บเล็ตของคุณคุณจะพูดกับมันแปลงข้อความให้เป็นข้อความวิ่งไปทางอินเทอร์เน็ตไปยังระบบแบ็คเอนด์ ที่แปลงไปเป็นแบบสอบถามเรียกใช้แบบสอบถามผ่านกองซ้อนของแอปพลิเคชันผ่านฐานข้อมูล Hit ดิสก์ออกมาและตรงกลางมีเครือข่ายผู้ให้บริการมีศูนย์สถานะเครือข่ายท้องถิ่น ความซับซ้อนเป็นบ้า

เรายืนยันเรื่องนี้อย่างมีประสิทธิภาพเป็น hyperscale ความซับซ้อนและความเร็วของการ hyperscale เป็นเพียงการรดน้ำ แอปพลิเคชันและฐานข้อมูลมีขนาดใหญ่และซับซ้อนดังนั้นการจัดการประสิทธิภาพจึงเป็นวิทยาศาสตร์ในตัวเอง หลายคนอ้างว่าเป็นวิทยาศาสตร์จรวด เรามีเทคโนโลยีในสถานที่เรามีเทคโนโลยีนอกสถานที่เรามีตัวเลือกศูนย์ข้อมูลมากมาย ทางกายภาพและเสมือน เรามีเซิร์ฟเวอร์จริงและเซิร์ฟเวอร์เสมือนเรามีระบบคลาวด์เรามีโครงสร้างพื้นฐานเป็นบริการและแพลตฟอร์มในฐานะบริการและซอฟต์แวร์เนื่องจากบริการเป็นสิ่งที่เราได้รับอนุญาตในขณะนี้ ซอฟต์แวร์หลังการบริการกลายเป็นสิ่งที่น่ากลัวเมื่อไม่กี่ปีที่ผ่านมาเมื่อ CFO และส่วนต่าง ๆ ขององค์กรตระหนักว่าพวกเขาสามารถรับบัตรเครดิตและซื้อสิ่งต่าง ๆ และไปรอบ ๆ CIO และเราเรียกเงานี้ว่า มัน” และซีไอโอตอนนี้พยายามที่จะหมุนกลับและต่อสู้กลับควบคุม

ในโครงสร้างพื้นฐานเรามีเครือข่ายที่กำหนดโดยซอฟต์แวร์การจำลองเสมือนของฟังก์ชั่นเครือข่ายด้านล่างที่เรามีในตอนนี้เรามีบริการไมโครและแอพของบริการที่ใช้งานอยู่ เมื่อคุณคลิกที่ URL จะมีตรรกะทางธุรกิจมากมายที่อยู่ท้าย URL นั้นซึ่งอธิบายถึงสิ่งที่จำเป็นในการส่งมอบจริง มันไม่จำเป็นต้องมีตรรกะที่สร้างไว้ล่วงหน้ารออยู่ เรามีฐานข้อมูลดั้งเดิมที่ด้านหนึ่งซึ่งมีขนาดใหญ่มาก เรามีสิ่งที่ชอบโครงสร้างพื้นฐานและระบบนิเวศของ Hadoop ที่คลื่นความถี่อื่นที่มีขนาดใหญ่มากอย่างที่ฉันพูดคุณรู้ว่าผู้คนกำลังพูดถึงข้อมูลหลายร้อยเพตาไบต์ตอนนี้ เรามีการเคลื่อนไหวที่ซับซ้อนเท่าที่อุปกรณ์พกพาไปได้ทุกที่แล็ปท็อปและโทรศัพท์และแท็บเล็ต

เรามี BYOD ในสภาพแวดล้อมที่ปิดล้อมและตอนนี้เพิ่มมากขึ้นเนื่องจากผู้ใช้ Gen Y มีประสบการณ์นำอุปกรณ์ของตัวเองมาใช้ เราเพียงแค่ให้พวกเขาพูดคุยกับพวกเขาเกี่ยวกับเว็บอินเตอร์เฟส ไม่ว่าจะผ่านอินเทอร์เน็ตหรือผ่าน Wi-Fi เรามี Wi-Fi ฟรีในร้านกาแฟชั้นล่างเนื่องจากพวกเขากำลังดื่มกาแฟ หรือ Wi-Fi ภายในของเรา เครื่องจักรต่อเครื่องเป็นปัจจุบันอยู่เสมอ นั่นไม่ได้เป็นส่วนหนึ่งของอินเทอร์เน็ตโดยตรง แต่ก็เกี่ยวข้องกัน Internet of Things เป็นเกมใหม่ที่เต็มไปด้วยความซับซ้อนที่ไม่น่าเชื่อ ปัญญาประดิษฐ์และถ้าคุณคิดว่าสิ่งที่เรากำลังเล่นกับ Siri และอุปกรณ์ที่เกี่ยวข้องอื่น ๆ ที่เราพูดถึงมีความซับซ้อนรอจนกว่าคุณจะไปถึงสถานการณ์ที่คุณเห็นสิ่งที่เรียกว่า Olli ซึ่งเป็น 3-D รถบัสที่พิมพ์ซึ่งใช้เวลาประมาณหกคนและสามารถขับรถไปรอบ ๆ เมืองและคุณสามารถพูดภาษาอังกฤษธรรมดากับมันและมันจะพูดกลับไปหาคุณ หากจราจรติดขัดจะตัดสินใจเลี้ยวซ้ายหรือขวาออกจากบริเวณหลักที่มีการจราจร เมื่อถึงคราวคุณจะกังวลว่าทำไมเลี้ยวซ้ายหรือขวาออกจากถนนหลักมันจะพูดกับคุณว่า“ ไม่ต้องกังวลฉันกำลังจะเลี้ยวซ้าย มีการจราจรอยู่ข้างหน้าและฉันจะเดินไปรอบ ๆ ”

การจัดการประสิทธิภาพของระบบทั้งหมดที่อยู่ในนั้นและความซับซ้อนทั้งหมดการติดตามว่าข้อมูลนั้นไปที่ใดไม่ว่าจะเข้าไปในฐานข้อมูลการเชื่อมต่อทั้งหมดและบิตที่เกี่ยวข้องทั้งหมดนั้นเป็นสิ่งที่น่าเหลือเชื่อ ความจริงก็คือการจัดการประสิทธิภาพและ SLA ด้วยความเร็วและขนาดของวันนี้ต้องใช้เครื่องมือและระบบและโดยค่าเริ่มต้นนี่ไม่ใช่สิ่งที่คุณคิดว่าจะมีเครื่องมือที่ดี - เป็นสิ่งที่จำเป็น มันจำเป็นจริงๆ นี่คือตัวอย่างเล็ก ๆ น้อย ๆ รายการของไดอะแกรมการออกแบบแอพพลิเคชั่นระดับสูงสำหรับ OpenStack ซึ่งเป็นคลาวด์ที่กำหนดโดยซอฟต์แวร์โอเพนซอร์ส นี่เป็นเพียงก้อนใหญ่ นี่ไม่ใช่แค่เซิร์ฟเวอร์และฐานข้อมูล นี่คือที่ซึ่งหยดสีน้ำเงินเล็ก ๆ แต่ละอันแทนกลุ่มสิ่งต่าง ๆ ในบางกรณีไฟล์และเซิร์ฟเวอร์หรือฐานข้อมูลหลายร้อยหรือแน่นอนไม่เกิน 10, 000 ตรรกะชิ้นส่วนเล็ก ๆ ของการใช้งานตรรกะ นั่นเป็นรุ่นเล็ก เป็นเรื่องที่น่าเหลือเชื่อเมื่อคุณเริ่มคิดถึงความซับซ้อนที่เกิดขึ้นในเรื่องนี้ วันนี้แม้ในพื้นที่ข้อมูลขนาดใหญ่ฉันจะใส่ภาพหน้าจอของแบรนด์ต่างๆ เมื่อคุณคิดถึงชิ้นส่วนทั้งหมดที่เราต้องจัดการที่นี่เราไม่ได้แค่พูดถึงยี่ห้อหนึ่ง ๆ แบรนด์เหล่านี้ล้วนเป็นแบรนด์ในแนวนอนของข้อมูลขนาดใหญ่และแบรนด์อันดับต้น ๆ ไม่ใช่แค่ทุกแหล่งเล็ก ๆ หรือโอเพนซอร์ส คุณมองและคุณคิดว่ามันเป็นแผนภูมิที่เหลือเชื่อ

ลองดูที่แนวดิ่งสองสามอัน ตัวอย่างเช่นลองทำการตลาด นี่เป็นแผนภูมิที่คล้ายกัน แต่จากสแต็คเทคโนโลยีที่มีอยู่ในเทคโนโลยีการตลาดเพียงอย่างเดียว นี่คือกราฟ 2011 นี่คือเวอร์ชั่น 2016 ลองคิดดูสินี่เป็นเพียงจำนวนของผลิตภัณฑ์ที่คุณสามารถใช้สำหรับเทคโนโลยีเกี่ยวกับเทคโนโลยีการตลาด ไม่ใช่ความซับซ้อนของระบบภายในนั่นไม่ใช่แอพและเว็บและการพัฒนาและเครือข่ายและอื่น ๆ เพียงแค่แบรนด์ ก่อนหน้านี้เมื่อห้าปีก่อนและนี่คือวันนี้ มันจะเลวร้ายลงเท่านั้น เรามาถึงจุดนี้แล้วในขณะที่ความจริงคือมนุษย์ไม่สามารถรับประกันข้อตกลงระดับบริการทั้งหมดได้ เราไม่สามารถดำน้ำในรายละเอียดที่เพียงพอเร็วพอและในระดับที่เราต้องการ นี่คือตัวอย่างของคอนโซลการตรวจสอบที่ดูเหมือนตอนนี้ นี่เป็นเหมือนหน้าจอเกือบยี่สิบหน้าจอที่ติดกันแกล้งทำเป็นว่าพวกเขาเป็นหนึ่งในหน้าจอที่ยอดเยี่ยม ตอนนี้มันน่าสนใจที่นี่ฉันจะไม่พูดถึงแบรนด์ แต่แพลตฟอร์มการตรวจสอบนี้กำลังตรวจสอบแอปพลิเคชันเดียวในสภาพแวดล้อมด้านโลจิสติกส์และการขนส่ง แอพเดียว หากคุณคิดว่าโรบินพูดถึงองค์กรที่สามารถมีฐานข้อมูลได้ 40, 000 ฐานในสภาพแวดล้อมการผลิต คุณสามารถเห็นภาพชุดสะสมของหน้าจอ 40, 000 หน้าจอที่สามารถใช้งานแอพพลิเคชั่นเดียวได้หรือไม่? มันเป็นโลกที่กล้าหาญมากที่เราอาศัยอยู่ในขณะที่โรบินพูดและฉันก็จะสะท้อน 100% อย่างนั้นโดยไม่มีเครื่องมือที่เหมาะสมโดยไม่มีการสนับสนุนที่ถูกต้องและชาวบ้านบนโต๊ะโดยใช้เครื่องมือเหล่านั้นประสิทธิภาพของแอพพลิเคชั่น จะต้องมีการดำเนินการโดยเครื่องมือและซอฟต์แวร์

โดยที่ฉันจะส่งต่อให้เพื่อนของเราใน IDERA

Eric Kavanagh: ก็ได้บิล

Bill Ellis: ขอบคุณ แบ่งปันหน้าจอของฉันที่นี่ ฉันเดาว่ามีคนยืนยันได้ว่าคุณสามารถเห็นหน้าจอของฉันได้หรือไม่

ดร. โรบินบลอร์: ใช่

Eric Kavanagh: มันดูดีนะ

Bill Ellis: ขอบคุณ สิ่งหนึ่งที่เขาอ้างถึงคือฉันไม่สามารถรอได้จริงๆคือรถยนต์ที่ขับเคลื่อนด้วยตนเอง สิ่งหนึ่งที่ฉันไม่เคยได้ยินใครพูดถึงคือเกิดอะไรขึ้นเมื่อหิมะตก? ฉันสงสัยว่าวิศวกรในแคลิฟอร์เนียรู้หรือไม่ว่าในส่วนอื่น ๆ ของประเทศมันมีหิมะตกเล็กน้อย

Dez Blanchfield: ฉันชอบที่ฉันจะจำได้ว่าหนึ่ง

Eric Kavanagh: ปกติหนึ่งไมล์ต่อชั่วโมง

Bill Ellis: เรามาที่นี่เพื่อพูดคุยเกี่ยวกับการจัดการประสิทธิภาพแอพพลิเคชั่นในสภาพแวดล้อมที่ซับซ้อน สิ่งหนึ่งที่ฉันชอบพูดถึงคือผู้คนจำนวนมากเมื่อพวกเขาพูดถึงประสิทธิภาพลักษณะของปฏิกิริยาคือเฮ้เซิร์ฟเวอร์ที่มากขึ้น CPU ที่มากขึ้นหน่วยความจำที่มากขึ้น ฯลฯ ด้านอื่น ๆ ของเหรียญนั้นคือประสิทธิภาพในการประมวลผล จริง ๆ นั่นคือทั้งสองด้านของเหรียญเดียวกันและเราจะดูทั้งสองอย่าง เป้าหมายสูงสุดคือการบรรลุข้อตกลงระดับบริการสำหรับธุรกรรมทางธุรกิจ ในที่สุดเทคโนโลยีทั้งหมดนี้มีอยู่สำหรับธุรกิจ เราพูดคุยเกี่ยวกับการมีฐานข้อมูลการจัดการประสิทธิภาพเป็นครั้งแรกในอุตสาหกรรม สิ่งที่ดีที่สุดคือการปรับให้เข้ากับรูปแบบการทำงานที่สมบูรณ์แบบและจัดการมันตั้งแต่จุดเริ่มต้นของวงจรชีวิตการใช้งาน

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

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

เพื่อที่จะแก้ปัญหานี้เพื่อให้เป็นวิธีที่ดีกว่าสิ่งที่จริง ๆ แล้วทำธุรกรรมแทร็กผู้ใช้ปลายทางจับ metadata เกี่ยวกับมันตามธุรกรรมผ่านเครือข่ายเข้าสู่เว็บเซิร์ฟเวอร์ลงในชั้นตรรกะทางธุรกิจและ เราสนับสนุน. NET และ ABAP และ PeopleCode และ E-Business Suite ในแอพพลิเคชั่นหลายชั้นซึ่งในที่สุดการทำธุรกรรมทั้งหมดจะต้องมีปฏิสัมพันธ์กับระบบของการบันทึก ไม่ว่าจะเป็นการค้นหาสินค้าคงคลังเวลาทำงานรายงานพวกเขาจะโต้ตอบกับฐานข้อมูลเสมอ ฐานข้อมูลกลายเป็นรากฐานของประสิทธิภาพทางธุรกิจ ในทางกลับกันฐานข้อมูลขึ้นอยู่กับการจัดเก็บ ข้อมูลเมตาเกี่ยวกับธุรกรรมตอบว่าใครทำธุรกรรมอะไรอยู่ที่ไหนในแอปพลิเคชันสแต็กจากนั้นเรามีการมองเห็นระดับรหัสลึกเพื่อแสดงให้คุณเห็นว่ากำลังดำเนินการอะไรอยู่ ข้อมูลนี้จะถูกบันทึกอย่างต่อเนื่องใส่ลงในฐานข้อมูลการจัดการประสิทธิภาพซึ่งจะกลายเป็นแผ่นเพลงเดียวสำหรับทุกคนเพื่อดูว่าเกิดอะไรขึ้น มีผู้คนและองค์กรต่าง ๆ ที่ให้ความสนใจกับสิ่งที่เกิดขึ้น: ผู้เชี่ยวชาญด้านเทคนิคเจ้าของแอปพลิเคชันในที่สุดธุรกิจเอง เมื่อมีปัญหาเกิดขึ้นคุณต้องการแยกข้อมูลเกี่ยวกับธุรกรรมนั้นออก

ก่อนที่เราจะดูธุรกรรมการลงทุนฉันต้องการแสดงให้คุณเห็นว่าสิ่งนี้อาจปรากฏต่อบุคคลต่าง ๆ ในองค์กรได้อย่างไร ในระดับการจัดการคุณอาจต้องการภาพรวมของแอปพลิเคชั่นหลายตัว คุณอาจต้องการทราบเกี่ยวกับสุขภาพที่คำนวณโดยการปฏิบัติตาม SLA และความพร้อมใช้งาน สุขภาพนั้นไม่ได้หมายความว่าทุกอย่างทำงานได้อย่างสมบูรณ์ 100% มีห้องในกรณีนี้คุณสามารถดูธุรกรรมการลงทุนที่อยู่ในสถานะเตือน ตอนนี้ลึกลงไปอีกเล็กน้อยบางทีในสายธุรกิจคุณต้องการมีรายละเอียดเพิ่มเติมเกี่ยวกับการทำธุรกรรมแต่ละรายการเมื่อพวกเขาฝ่าฝืน SLA, การนับจำนวนธุรกรรม ฯลฯ ทีมการดำเนินงานจะต้องการได้รับการแจ้งเตือนผ่านทางการแจ้งเตือนของบางอย่าง ประเภท เรามีการแจ้งเตือนประสิทธิภาพในตัวเราวัดประสิทธิภาพในเบราว์เซอร์ของผู้ใช้ปลายทาง ไม่ว่าจะเป็น Internet Explorer, Chrome, Firefox ฯลฯ เราสามารถตรวจพบได้นี่เป็นคำตอบของคำถามแรก: ผู้ใช้ปลายทางมีปัญหาหรือไม่

มาดำน้ำกันและดูว่าเราสามารถแสดงอะไรได้บ้าง คนที่มีความสนใจในการแสดงจะเปิดขึ้นอย่างแม่นยำ พวกเขาต้องการประเมินธุรกรรม พวกเขาต้องการดูคอลัมน์ SLA เพื่อระบุธุรกรรมที่ไม่สอดคล้องกับ SLA พวกเขาจะสามารถเห็นผู้ใช้ปลายทางที่ได้รับผลกระทบเช่นเดียวกับธุรกรรมที่ทำในขณะที่ไหลข้ามแอปพลิเคชัน วิธีที่คุณถอดรหัสอักษรอียิปต์โบราณเหล่านี้คือเบราว์เซอร์, URL, U สำหรับ URL นั่นคือจุดเริ่มต้นใน JVM ตอนนี้ JVM เฉพาะนี้ทำให้เว็บเซิร์ฟเวอร์โทรหา JVM ที่สองซึ่งดำเนินการคำสั่ง SQL นี่เป็นปัญหาฐานข้อมูลอย่างชัดเจนเนื่องจากคำสั่ง SQL นี้รับผิดชอบ 72 เปอร์เซ็นต์ของเวลาตอบสนอง เรามุ่งเน้นที่เวลา เวลาคือสกุลเงินของประสิทธิภาพ เป็นวิธีที่ผู้ใช้พบว่าสิ่งต่าง ๆ ทำงานช้าหรือไม่และเป็นตัวชี้วัดการใช้ทรัพยากร มันมีประโยชน์มาก เป็นตัวชี้วัดเดียวที่สำคัญที่สุดสำหรับการประเมินประสิทธิภาพ เมื่อปัญหานี้ถูกส่งไปยัง DBA ไม่ใช่เพียงปัญหาฐานข้อมูล แต่เป็นคำสั่ง SQL นี้ นี่คือบริบทที่ฉันพูดถึง

ตอนนี้มีข้อมูลนี้ฉันสามารถเข้าไปวิเคราะห์สิ่งที่เกิดขึ้นได้ ฉันเห็นก่อนอื่นแกน y คือเวลาข้ามวัน ขอโทษนะแกน y คือเวลาตอบสนองแกน x คือเวลาข้ามวัน ฉันเห็นว่ามีปัญหาเกี่ยวกับฐานข้อมูลมีสองเหตุการณ์เกิดขึ้นกลับไปที่โฟลว์รับคำสั่ง SQL นั้นและเข้าไปในมุมมองของผู้เชี่ยวชาญโดยที่แม่นยำสามารถแสดงให้คุณเห็นว่าเกิดอะไรขึ้นการควบคุมของมันใช้เวลานานแค่ไหน ปฏิบัติ ในระดับฐานข้อมูลเป็นแผนการดำเนินการ คุณจะทราบว่าแม่นยำเลือกแผนการดำเนินการจริงที่ใช้ในเวลาดำเนินการซึ่งแตกต่างจากแผนโดยประมาณซึ่งจะเป็นเมื่อมีการกำหนดแผนและไม่ได้อยู่ในช่วงเวลาดำเนินการ อาจหรือไม่อาจสะท้อนว่าฐานข้อมูลจริง

ตอนนี้ที่นี่คือการวิเคราะห์เวลาตอบสนองสำหรับคำสั่ง SQL เก้าสิบเปอร์เซ็นต์ของเวลาที่ใช้ในการจัดเก็บ สิบเปอร์เซ็นต์ถูกใช้ในซีพียู ฉันสามารถดูข้อความของคำสั่ง SQL รวมถึงรายงานการค้นพบ ข้อความของคำสั่ง SQL จริง ๆ แล้วเริ่มเปิดเผยปัญหาการเข้ารหัสบางอย่าง มันคือดาวที่เลือก ที่ส่งกลับทุกแถว - ขอโทษนะคอลัมน์ทั้งหมดจากแถวที่ถูกส่งคืน เรากำลังย้อนกลับคอลัมน์เพิ่มเติมแอปพลิเคชันอาจหรืออาจไม่จำเป็น คอลัมน์เหล่านั้นใช้พื้นที่และทรัพยากรในการประมวลผล หากคุณรัน SAP หนึ่งในการเปลี่ยนแปลงครั้งใหญ่เนื่องจากฐานข้อมูล HANA เป็นแบบเรียงเป็นแนวนั่นคือการเขียน SAP ซ้ำโดยไม่เลือกดาวที่เลือกเพื่อให้สามารถลดการใช้ทรัพยากรได้อย่างมาก นี่เป็นสิ่งที่เกิดขึ้นบ่อยครั้งในแอปพลิเคชันที่ผลิตเองเช่น Java, .NET เป็นต้น

หน้าจอนั้นแสดงให้คุณเห็นว่าใครทำอะไรเมื่อไหร่ที่ไหนและทำไม สาเหตุที่ได้รับเช่นคำสั่ง SQL และแผนการดำเนินการที่ช่วยให้คุณแก้ปัญหาได้ เนื่องจากการทำงานที่แม่นยำอย่างต่อเนื่องคุณสามารถวัดได้ทั้งก่อนและหลังที่ระดับคำสั่ง SQL ที่ระดับธุรกรรมดังนั้นคุณสามารถวัดได้ด้วยตัวคุณเองรวมถึงผ่านเจ้าของแอปพลิเคชันและการจัดการที่คุณได้แก้ไขปัญหาแล้ว . เอกสารนั้นมีประโยชน์จริง ๆ แอปพลิเคชันนี้มีความซับซ้อนมาก ในความเป็นจริงแล้วทุก ๆ แอปพลิเคชั่นที่เราได้พูดคุยกันนั้นทำงานอย่างน้อยหนึ่งส่วนของ application stack ภายใต้ VMware ในกรณีนี้พวกเขากำลังดูที่แอปพลิเคชันการบริการลูกค้าพวกเขากำลังดูเวลาธุรกรรมและเชื่อมโยงกับการชะลอตัวเป็นเหตุการณ์การจำลองเสมือน การติดตามเหตุการณ์การจำลองเสมือนทั้งหมดที่แม่นยำ เรามีปลั๊กอินไปยัง vCenter เพื่อเลือกสิ่งนั้น

เรายังสามารถตรวจจับการโต้แย้ง ความขัดแย้งต่างจากการใช้งาน แสดงจริงเมื่อเพื่อนบ้านที่มีเสียงดังกำลังส่งผลกระทบต่อ VM แขกของคุณในบริบทของแอปพลิเคชันของเซิร์ฟเวอร์ลูกค้า ตอนนี้ฉันสามารถเจาะลึกและรับข้อมูลได้และฉันสามารถเห็น VM ทั้งสองที่กำลังต่อสู้กันในกรณีนี้สำหรับทรัพยากร CPU สิ่งนี้ทำให้ฉันสามารถมองเห็นได้เพื่อให้ฉันสามารถดูการตั้งเวลาได้ ฉันสามารถวาง VM แขกบนเซิร์ฟเวอร์ที่แตกต่างกัน สิ่งต่าง ๆ เหล่านี้ทั้งหมดที่คุณอาจตอบสนองและนอกจากนั้นฉันสามารถดูประสิทธิภาพของรหัสเพื่อใช้ CPU น้อยลง ฉันคิดว่าฉันมีตัวอย่างที่ดีงามในการนำเสนอนี้ว่าใครบางคนสามารถลดการใช้ซีพียูตามลำดับความสำคัญได้อย่างไร

นั่นคือ VMware ลองเข้าไปในรหัสของตัวเองรหัสแอปพลิเคชัน แม่นยำจะสามารถแสดงให้คุณเห็นสิ่งที่เกิดขึ้นใน Java, . NET, รหัส ABAP, E-Business, PeopleCode ฯลฯ นี่คือจุดเริ่มต้นในกรณีนี้ลงใน WebLogic ด้านล่างนี้มีรายงานการค้นพบที่บอกฉันว่านี่คือ EJB ที่คุณต้องดูและจะบอกฉันว่าคุณกำลังล็อคสิ่งที่เกิดขึ้นในระบบนี้ อีกครั้งเจาะลึกลงไปในชั้นตรรกะทางธุรกิจเพื่อแสดงสิ่งที่เกิดขึ้น ในกรณีนี้ฉันกำลังดูตัวอย่าง ฉันยังสนับสนุนการจัดกลุ่ม หากคุณมี JVM จำนวนมากกำลังทำงานคุณสามารถดูทั้งคลัสเตอร์หรือดูที่คอขวดภายใน JVM แต่ละรายการ

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

หนึ่งในสิ่งที่เกี่ยวกับรายงานการค้นพบของ Precise ไม่เพียง แต่ดูที่บันทึกหรือรอสถานะ - ดูสถานะการดำเนินการทั้งหมดรวมถึง CPU รวมถึงการส่งคืนข้อมูลจากที่เก็บข้อมูล การจัดเก็บข้อมูลเป็นส่วนสำคัญของแอปพลิเคชันสแต็คโดยเฉพาะอย่างยิ่งกับสถานะของโซลิดสเตต การมีข้อมูลตามบรรทัดเหล่านั้นจะมีประโยชน์มาก สำหรับหน่วยเก็บข้อมูลบางหน่วยเราสามารถเจาะลึกและแสดงสิ่งที่เกิดขึ้นในแต่ละระดับอุปกรณ์ ข้อมูลประเภทนั้น - การมองเห็นอีกครั้ง มันมีขอบเขตกว้าง ๆ - เพื่อให้ข้อมูลที่เพียงพอสำหรับคุณในการดึงประสิทธิภาพการทำงานของแอพพลิเคชั่นให้มากขึ้นเพื่อให้คุณสามารถปรับแต่งแอพพลิเคชั่นของคุณให้เหมาะสมเพื่อตอบสนองธุรกรรมทางธุรกิจเหล่านั้น

ฉันมีกรณีศึกษาสองสามอย่างที่ฉันต้องการแบ่งปันกับคุณ เราล่องไปตามทางที่ค่อนข้างเร็ว ฉันหวังว่าฉันจะก้าวไปด้วยดี เมื่อพูดถึงการจัดเก็บข้อมูลทุกคนในช่วงเวลาเปลี่ยนฮาร์ดแวร์ มีการรับประกันฮาร์ดแวร์ มันส่งมอบสิ่งที่ผู้ขายบอกจริงหรือ คุณสามารถประเมินด้วยความแม่นยำ คุณเข้ามาและสิ่งที่เกิดขึ้นที่นี่โดยทั่วไปแล้วพวกเขาใส่ในหน่วยจัดเก็บข้อมูลใหม่ แต่เมื่อผู้ดูแลระบบจัดเก็บข้อมูลมองที่ระดับหน่วยเก็บข้อมูลพวกเขาเห็นความขัดแย้งมากมายและพวกเขาคิดว่าอาจมีปัญหากับหน่วยเก็บข้อมูลใหม่นี้ . ดูเพิ่มเติมจากมุมมองแบบ end-to-end เพื่อแสดงให้เห็นอย่างชัดเจนว่าจะเกิดอะไรขึ้น จริงๆแล้วพวกเขามาจากปริมาณงานประมาณ 400 เมกะบิตต่อวินาทีที่จัดเก็บรับผิดชอบเวลาตอบร้อยละ 38 ดังนั้นมันจึงค่อนข้างสูง ด้วยหน่วยจัดเก็บข้อมูลใหม่เราเพิ่มความเร็วในการรับส่งข้อมูลเป็นหก, เจ็ดร้อยเมกกะบิตต่อวินาทีดังนั้นโดยทั่วไปจึงเพิ่มเป็นสองเท่าและเราสามารถลดสัดส่วนของสตอเรจในการทำธุรกรรมได้ครึ่งหนึ่ง ก่อนหน้านี้ฉันสามารถวาดกราฟออกมาได้นี่คือช่วงเวลาตัดยอดและหลังจากนั้น

ดังนั้นเอกสารอีกครั้งเพื่อพิสูจน์ว่าการลงทุนด้านฮาร์ดแวร์นั้นคุ้มค่าและพวกเขาส่งมอบตามที่ผู้ขายรายนั้นได้คาดไว้ มีทั้งหมดเนื่องจากความซับซ้อนจำนวนสิ่งมีทุกสิ่งที่สามารถเกิดขึ้นได้ ในกรณีนี้พวกเขามีสถานการณ์ที่ทุกคนรู้สึกผิดกับ DBA และ DBA ก็เหมือน“ ไม่เร็วนัก” ที่นี่เรากำลังดูแอปพลิเคชัน SAP จริง ๆ ฉันคิดว่าสถานการณ์ประเภทนี้ค่อนข้างธรรมดา . เกิดอะไรขึ้นพวกเขากำลังพัฒนาธุรกรรมที่กำหนดเองสำหรับผู้ใช้ ผู้ใช้มีลักษณะเหมือน“ นี่ช้ามาก” ABAP coder - นั่นคือภาษาการเขียนโปรแกรมใน SAP - กล่าวว่า“ นี่คือปัญหาฐานข้อมูล” พวกเขาจบลงด้วยการเปิด Precise; พวกเขาวัดว่าผู้ใช้ปลายทาง 60 วินาทีดังนั้นในเวลาหนึ่งนาที ใช้เวลาห้าสิบสามวินาทีในส่วนหลัง พวกเขาเจาะลงไปด้านหลังและพวกเขาสามารถเปิดเผยคำสั่ง SQL ที่แสดงตามลำดับจากมากไปหาน้อย

คำสั่ง SQL ด้านบนนี้ซึ่งรับผิดชอบ 25 เปอร์เซ็นต์ของการใช้ทรัพยากรเวลาดำเนินการโดยเฉลี่ยคือสองมิลลิวินาที คุณไม่สามารถตำหนิฐานข้อมูล คุณรู้ใช่มั้ยไม่เร็วนัก คำถามคือทำไมมีการประหารชีวิตมากมาย? พวกเขาเด้งมันกลับไปที่ ABAP เขาเข้าไปตรวจดูรังของวงวนพบว่าพวกเขากำลังเรียกฐานข้อมูลผิดที่พวกเขาทำการเปลี่ยนแปลงทดสอบการเปลี่ยนแปลงและตอนนี้เวลาตอบสนองใหม่คือ ห้าวินาที ค่อนข้างช้า แต่พวกเขาสามารถอยู่กับสิ่งนั้นได้ ดีกว่า 60 วินาที บางครั้งก็เพิ่งออกไปมันเป็นรหัสแอปพลิเคชันมันเป็นฐานข้อมูลมันเป็นที่จัดเก็บ? เหล่านี้คือพื้นที่ที่แม่นยำโดยมีบริบทของการทำธุรกรรมแบบ end-to-end นั่นคือสิ่งที่ Precise เข้ามาเล่น คุณมักจะจบสิ่งเหล่านั้น

ฉันกำลังดูเวลาดูเหมือนว่าเรายังมีเวลาเล็กน้อยที่จะผ่านสิ่งเหล่านี้อีกสองสามครั้ง ฉันกำลังสตรีมผ่านสิ่งเหล่านี้ แอปพลิเคชันนี้อยู่ระหว่างการพัฒนามานานกว่าหนึ่งปี เมื่อพวกเขาเข้าสู่ระบบควบคุมคุณภาพพวกเขาเห็นว่าเว็บเซิร์ฟเวอร์นั้นมีค่าใช้จ่ายสูงสุด 100 เปอร์เซ็นต์และดูเหมือนว่าแอปพลิเคชันจะไม่สามารถทำงานภายใต้ VMware ได้ สิ่งแรกที่ทุกคนพูดคือ“ ใส่สิ่งนี้กับร่างกาย มันไม่สามารถทำงานได้ภายใต้ VMware” จริง ๆ แล้วเสนอวิธีเพิ่มเติมในการแก้ไขปัญหา เรามองไปที่การทำธุรกรรมเราเห็นการเรียกใช้เว็บเซิร์ฟเวอร์มันมาเป็น ASMX ใน IIS.NET มันเปิดเผยรหัสพื้นฐานจริง คุณเห็นสิ่งนี้ที่ฉันกำลังชี้? นี่คือ 23 วัน 11 ชั่วโมง ว้าวเป็นไปได้อย่างไร การเรียกแต่ละครั้งใช้เวลา 9.4 วินาทีและสิ่งนี้ถูกเรียกใช้ 215, 000 ครั้ง สำหรับการเรียกใช้ทุกครั้งจะใช้ CPU 6 วินาที นี่คือเหตุผลรหัสนี้เป็นสาเหตุที่สิ่งนี้ไม่สามารถปรับขนาดได้ ที่จริงแล้วมันไม่สามารถปรับขนาดในร่างกาย

สิ่งที่พวกเขาทำคือพวกเขากลับไปที่ผู้พัฒนาและพวกเขากล่าวว่า“ ใครสามารถทำการเปลี่ยนแปลงได้หรือไม่” พวกเขามีการแข่งขันและพวกเขาทดสอบข้อเสนอแนะต่าง ๆ และพวกเขาพบข้อเสนอแนะที่สามารถทำงานได้มาก มีประสิทธิภาพมากขึ้น ใหม่เสร็จหนึ่งจุดน้อยกว่าสองวินาทีน้อยสองร้อยในวินาทีของซีพียู ตอนนี้สามารถปรับขนาดและสามารถทำงานบนฟาร์ม VMware เราสามารถทำเอกสารโดยพื้นฐานว่าทั้งในระดับรหัสและระดับธุรกรรม นี่เป็นสิ่งที่เกิดขึ้นก่อนหน้านี้และหลังจากนั้น ตอนนี้คุณสามารถเห็นที่นี่ในกราฟแท่งสแต็กที่แสดงเว็บ, . NET และฐานข้อมูลตอนนี้คุณกำลังโต้ตอบกับฐานข้อมูล นี่เป็นโปรไฟล์ที่คุณคาดว่าจะเห็นสำหรับแอปพลิเคชันที่ทำงานได้ตามปกติ

เอาล่ะฉันกำลังเลือกและเลือกในสิ่งเพิ่มเติมที่ฉันสามารถแสดงให้คุณเห็น ผู้คนมากมายชอบสิ่งนี้เพราะสิ่งนี้ทำให้ร้านค้ามากมาย หากคุณไม่สามารถพบธุรกิจ SLA และทุกคนเป็นเหมือน“ ช่วยเราออกมา” ร้านนี้มีสถานการณ์ที่ธุรกิจ SLA อยู่ในคำสั่งซื้อที่ได้รับภายในเวลา 15.00 น. จัดส่งในวันนั้น มันสำคัญมากที่พวกเขาจะได้รับคำสั่งซื้อและคลังสินค้าก็ยุ่งมาก หน้าจอใบสั่งขายของ JD Edwards นี้ค้างและคุณสามารถรับความคิดที่ดีมากว่านี่เป็นระบบการจัดการสินค้าคงคลังค้าปลีกแบบทันเวลา ชั้นวางเปล่าไม่สามารถค้าปลีกได้ ต้องมีสินค้าที่นั่นเพื่อขาย สิ่งที่เราทำคือเราพุ่งเข้าไปในกรณีนี้เรากำลังดูฐานข้อมูลเซิร์ฟเวอร์ SQL รูปลักษณ์จะเหมือนกันไม่ว่าจะเป็น SQL, Oracle, DB2 หรือ Sybase

เราระบุตัวเลือกจาก PS_PROD และเราสามารถจับภาพระยะเวลาได้จริงว่ามันทำงานได้มาก สีน้ำเงินเข้มที่ตรงกับคีย์ที่กล่าวว่าพวกเขาไม่รอสถานะรอหรือการบันทึกหรือการเก็บข้อมูล - สิ่งนี้ถูกผูกไว้โดย CPU เราติดตามคำสั่ง SQL ภายใน 34301 ดังนั้นทุกครั้งที่มีการดำเนินการเราเพิ่มเคาน์เตอร์ของเราเพื่อติดตามมัน นั่นหมายความว่าเรามีประวัติโดยละเอียดและฉันสามารถเข้าถึงได้โดยคลิกที่ปุ่มปรับแต่ง นี่คือแท็บประวัติ หน้าจอนี้แสดงระยะเวลาเฉลี่ยกับการเปลี่ยนแปลง วันพุธวันพฤหัสบดีวันศุกร์ระยะเวลาเฉลี่ยประมาณสองในสิบของวินาที หน้าจอค้างน้อยมากพวกเขาสามารถพบ SLA ธุรกิจได้ มา 27 กุมภาพันธ์มีอะไรบางอย่างเปลี่ยนแปลงและจู่ ๆ ก็มีเวลาดำเนินการที่นี่และที่จริงก็ช้าพอที่จะทำให้เกิดการหมดเวลาซึ่งส่งผลให้หน้าจอค้าง แม่นยำโดยการเก็บประวัติโดยละเอียดรวมถึงแผนการดำเนินการและการเปลี่ยนแปลงทั่วไปในดัชนีของตารางหากมีการใช้ SQL นั้น เราสามารถรับได้ว่าแผนการเข้าถึงมีการเปลี่ยนแปลงในวันที่ 27 กุมภาพันธ์ วันจันทร์ถึงวันศุกร์ที่เลวร้าย มา 5 มีนาคมแผนเข้าถึงการเปลี่ยนแปลงอีกครั้ง เป็นสัปดาห์ที่ดี ดาวสีชมพูดวงนี้บอกเราถึงปริมาณที่อัพเดต

คุณสามารถดูจำนวนแถวในตารางที่กำลังเติบโตและนี่เป็นเรื่องปกติสำหรับธุรกิจ คุณต้องการให้โต๊ะของคุณเติบโต สิ่งที่เป็นที่งบแยกวิเคราะห์งบ SQL มา, เครื่องมือเพิ่มประสิทธิภาพจะต้องตัดสินใจว่าจะทำและเลือกเมื่อแผนการดำเนินการได้อย่างรวดเร็วเลือกแผนการดำเนินการอื่นเมื่อมันช้าทำให้หน้าจอค้าง บนพื้นฐานของเทคโนโลยีที่ลึกฉันจำเป็นต้องรู้ว่าแผนปฏิบัติการคืออะไรและแม่นยำจะจับภาพให้ฉันสมบูรณ์พร้อมกับการประทับวันที่และเวลา นี่คืออันที่รวดเร็วและมีประสิทธิภาพนี่คืออันที่ช้าและไร้ประสิทธิภาพ ตัวกรองนี้เข้าร่วมใช้ CPU มากขึ้นในการปรับยอดเพื่อทำคำสั่ง SQL เฉพาะนี้ พวกเขายังคงมีผลสุดท้ายเหมือนกัน แต่อันนี้โดยทั่วไปมีสูตรที่ช้ากว่าและมีประสิทธิภาพน้อยกว่าสำหรับการส่งชุดผลลัพธ์ ดังนั้นเราก้าวผ่าน เฮ้เรามีเวลาสำหรับอีกสองสามคน?

Eric Kavanagh: ใช่ไปเลย

Bill Ellis: โอเคฉันจะข้ามไปก่อน สิ่งหนึ่งที่ฉันต้องการให้คุณจดบันทึกเราพูดคุยเกี่ยวกับฮาร์ดแวร์พูดคุยเกี่ยวกับ SAP เราพูดคุยเกี่ยวกับ. NET เราพูดคุยเกี่ยวกับ JD Edwards และสภาพแวดล้อม Java-SQL Server นี่คือ SAP ตรงนี้เรากำลังดู PeopleSoft อยู่ เมทริกซ์การสนับสนุนที่แม่นยำนั้นกว้างและลึก หากคุณมีแอปพลิเคชันมากกว่าที่เป็นไปได้เราสามารถนำไปใช้ในการมองเห็นในระดับนี้ หนึ่งในการเปลี่ยนแปลงที่ยิ่งใหญ่ที่สุดที่เกิดขึ้นในขณะนี้คือความคล่องตัว PeopleSoft แนะนำความคล่องตัวด้วย Fluid UI Fluid UI ใช้ระบบที่แตกต่างกันมาก แอปพลิเคชั่นนี้กำลังพัฒนา Fluid UI - สิ่งที่มันทำจากมุมมองการจัดการคือช่วยให้ผู้ใช้สามารถใช้โทรศัพท์ของพวกเขาและเพิ่มประสิทธิภาพการผลิตได้อย่างมาก หากคุณมีพนักงานหลายร้อยหรือหลายพันคนหรือมากกว่านั้นหากคุณสามารถเพิ่มผลผลิตได้ 1-2 เปอร์เซ็นต์คุณสามารถสร้างผลกระทบอย่างมากต่อเงินเดือนและทุกสิ่งอื่น เกิดอะไรขึ้นร้านค้านี้เปิดตัว PeopleSoft Fluid UI ตอนนี้พูดถึงความซับซ้อนนี่คือ PeopleSoft stack แอปพลิเคชั่นหนึ่งอย่างน้อยหกเทคโนโลยีผู้ใช้ปลายทางจำนวนมาก คุณเริ่มได้อย่างไร

ความแม่นยำอีกครั้งจะสามารถติดตามธุรกรรมเหล่านี้ได้ สิ่งที่เราแสดงให้คุณเห็นที่นี่คือกราฟแท่งแบบสแต็กแสดงลูกค้าเว็บเซิร์ฟเวอร์ Java ฐานข้อมูล Tuxedo แอปพลิเคชัน PeopleSoft แผนที่สีเขียวไปยัง J2EE ซึ่งเป็นวิธีที่แปลกใหม่ในการพูด WebLogic นี่คือ cutover ผู้ใช้ปลายทางเริ่มใช้ Fluid UI และเวลาตอบสนองเริ่มจากหนึ่งหรือครึ่งครึ่งสองวินาทีจนถึงประมาณเก้าสิบวินาที สิ่งที่หน้าจอนี้ไม่แสดงคือจำนวนผู้ที่ได้รับ“ ไม่ตอบสนอง” พวกเขาได้รับการหยุดพักหน้าจอในแอปพลิเคชัน ลองดูที่การมองเห็นบางอย่างที่แม่นยำสามารถให้บริการลูกค้าได้

ก่อนอื่นเลยเมื่อฉันดูธุรกรรม PeopleSoft พวกเขาสามารถเห็นได้โดยทั่วไปเราเห็นสิ่งต่าง ๆ บนกระดาน ธุรกรรมทั้งหมดได้รับผลกระทบเช่นเดียวกับที่ตั้งทั้งหมด เมื่อคุณดูที่นี้คุณสามารถดูสถานที่ต่างๆทั่วโลกได้ จากเอเชียแปซิฟิกไปจนถึงยุโรปรวมถึงอเมริกาเหนือ ปัญหาประสิทธิภาพไม่ได้อยู่ที่การทำธุรกรรมโดยเฉพาะอย่างยิ่งหรือที่ตั้งทางภูมิศาสตร์โดยเฉพาะมันกว้างของระบบ เป็นวิธีที่จะบอกว่าการเปลี่ยนแปลงหรือวิธีการที่ Fluid UI นั้นส่งผลกระทบทั่วโลก คุณสามารถดูได้จากจุดยืนที่ปรับขนาดได้ผู้คนกำลังพยายามทำกิจกรรมประเภทเดียวกัน แต่เวลาตอบสนองโดยทั่วไปจะลดลงและลดลง คุณจะเห็นว่าสิ่งต่าง ๆ ไม่ได้ปรับขนาด ทุกอย่างกำลังแย่มาก ตรงนี้เมื่อฉันดูจำนวนแกนและการเชื่อมต่อที่เกิดขึ้นพร้อมกันคุณจะเห็นบางสิ่งที่น่าสนใจมากในแง่ของจำนวนการเข้าถึงและการเชื่อมต่อ ที่นี่เราปรับขนาดได้สูงถึงประมาณ 5, 000 เท่านั้นและคุณกำลังดูอยู่นี่คือจุดเชื่อมต่อที่เกิดขึ้นพร้อมกัน 100 จุด สิ่งนี้ทำหลังจาก; อย่างนี้มาก่อน ความต้องการที่แท้จริงของฉันในระบบถ้าสิ่งนี้สามารถขยายได้อยู่ในช่วง 300, 000 ในสมัยก่อนด้วย UI แบบคลาสสิกคุณกำลังดูการเชื่อมต่อพร้อมกัน 30 ครั้ง

ตอนนี้สิ่งที่บอกคุณคือ Fluid UI ใช้อย่างน้อย 10 เท่าของการเชื่อมต่อพร้อมกัน เราเริ่มดึงสิ่งที่เกิดขึ้นภายใต้ฝาครอบกับ PeopleSoft เพื่อให้คุณสามารถเริ่มเห็นผลกระทบที่เกิดขึ้นกับเว็บเซิร์ฟเวอร์ข้อเท็จจริงที่ว่า SLA กำลังเริ่มละเมิด จะไม่เข้าไปในทุกสิ่ง แต่สิ่งที่เกิดขึ้นคือพวกเขาใช้การส่งข้อความเป็นหลัก พวกเขาออกกำลังกายโดยทั่วไปคือ WebLogic และทำให้เกิดการเข้าคิวภายใน Tuxedo ที่จริงแล้วมีปัญหาการพึ่งพาหลายชั้นที่ปรากฏขึ้นพร้อมกับ Fluid UI แต่แม่นยำสามารถแสดงให้เห็นว่าด้วยสิ่งต่าง ๆ มากมายเราสามารถมุ่งเน้นไปที่ปัญหาที่เกิดขึ้น ปรากฎว่ามีปัญหาในฐานข้อมูลเอง จริงๆแล้วมีไฟล์บันทึกการส่งข้อความและเนื่องจากผู้ใช้ที่ใช้งานพร้อมกันทั้งหมดไฟล์บันทึกนั้นจึงถูกล็อค โดยพื้นฐานแล้วมันมีสิ่งต่าง ๆ ที่ต้องปรับแต่งในทุก ๆ ชั้นภายในแอพพลิเคชัน พูดคุยเกี่ยวกับความซับซ้อนนี่คือเทียร์ Tuxedo ที่แสดงให้คุณเห็นถึงการเข้าคิวและคุณสามารถเห็นประสิทธิภาพลดลงภายในเทียร์นี้เช่นกัน ฉันเห็นกระบวนการ; ฉันเห็นโดเมนและเซิร์ฟเวอร์ ใน Tuxedo สำหรับคนที่จะใช้สิ่งนั้นโดยทั่วไปสิ่งที่คุณทำคือคุณเปิดคิวโดเมนและเซิร์ฟเวอร์เพิ่มเติมเช่นเดียวกับที่ซุปเปอร์มาร์เก็ตเพื่อลดความแออัดเพื่อลดเวลาในการรอคิว ตัวเลือกสุดท้ายและสุดท้ายแม่นยำแสดงข้อมูลจำนวนมาก

ดังที่ฉันได้กล่าวไปแล้วก่อนหน้านี้การทำธุรกรรมที่สำคัญทุกอย่างจะโต้ตอบกับระบบของการบันทึก ทัศนวิสัยในฐานข้อมูลเป็นสิ่งสำคัญยิ่ง แม่นยำแสดงสิ่งที่เกิดขึ้นในฐานข้อมูลภายใน WebLogic ภายใน Java, .NET, ภายในเบราว์เซอร์ แต่สถานที่ที่แม่นยำมากเก่งอยู่ในชั้นฐานข้อมูล นี่เป็นจุดอ่อนของคู่แข่งของเรา ฉันขอแสดงวิธีหนึ่งที่แม่นยำสามารถช่วยคุณทำสิ่งนี้ ฉันจะไม่ใช้เวลากับการเพิ่มประสิทธิภาพฐานข้อมูลรูปสามเหลี่ยม แต่โดยทั่วไปเรากำลังดูการเปลี่ยนแปลงประเภทต้นทุนต่ำความเสี่ยงต่ำไปเป็นขอบเขตกว้างความเสี่ยงสูงและราคาสูงโดยทั่วไป ฉันจะทวีตสไลด์นี้หลังจากนั้นถ้าคนต้องการลองดู ฉันคิดว่ามันเป็นแนวทางที่ใหญ่มากสำหรับการปรับปัญหา นี่คือมุมมองที่แม่นยำสำหรับผู้เชี่ยวชาญ Oracle บนสุดของรายงานการค้นพบผลกระทบ 60 เปอร์เซ็นต์คือคำสั่ง SQL นี้โดยเฉพาะ หากคุณเปิดหน้าจอของกิจกรรมนี้มันจะแสดงขึ้นที่นั่น ฉันสามารถดูคำสั่งที่เลือกนี้มีแผนปฏิบัติการหนึ่งแผน การดำเนินการทุกครั้งใช้เวลาประมวลผล 48, 000 วินาที ซึ่งจะเพิ่มการประหารชีวิตสูงสุด 48, 000 ชั่วโมง

สีน้ำเงินเข้มอีกครั้งคือ CPU สิ่งนี้คือ CPU ที่ถูกผูกไว้ไม่ใช่สถานะรอไม่ใช่บันทึก ฉันเน้นว่าเนื่องจากคู่แข่งบางรายของเราดูเฉพาะสถานะรอและการบันทึกเหตุการณ์ แต่โดยทั่วไปการพูด CPU เป็นสถานะการดำเนินการที่ยุ่งที่สุดและเสนอการซื้อคืนมากที่สุด ทำความเข้าใจกับมุมมองของผู้เชี่ยวชาญ - และฉันจะดำเนินการอย่างรวดเร็ว - สิ่งที่ฉันทำคือดูที่โต๊ะ 100, 000 แถว 37, 000 บล็อก เราทำตารางเต็ม แต่เรามีดัชนีหกตัวสำหรับสิ่งนี้ เกิดอะไรขึ้นที่นี่? ทีนี้เมื่อฉันดูที่ข้อไหนสิ่งที่ส่วนคำสั่งทำคือการแปลงคอลัมน์เป็นตัวพิมพ์ใหญ่และมันบอกว่ามันเท่ากับตัวพิมพ์ใหญ่หาตัวแปร สิ่งที่เกิดขึ้นคือทุกครั้งที่สิ่งนี้ดำเนินการ Oracle ต้องแปลงคอลัมน์นี้เป็นตัวพิมพ์ใหญ่ แทนที่จะทำอย่างนั้นเกือบห้าหมื่นครั้งมันมีประสิทธิภาพมากขึ้นในการสร้างดัชนีนั้นเป็นตัวพิมพ์ใหญ่ของดัชนีตามฟังก์ชันและสามารถใช้ได้ไม่เพียง แต่ในแผนกขององค์กรของออราเคิลเท่านั้น เมื่อคุณทำสิ่งที่คุณสามารถทำได้คือตรวจสอบแผนการดำเนินการออกว่าผู้ใช้ดัชนีใหม่อนุญาตให้ตัวพิมพ์ใหญ่เป็นของฉัน

จากการวัดก่อนและหลังคุณกำลังดูเวลาดำเนินการหนึ่งวินาทีรวมกันได้นานถึง 9 ชั่วโมง 54 นาทีด้วยคำสั่ง SQL เดียวกันนั้น แต่มีดัชนีนั้นเป็นตัวพิมพ์ใหญ่สำหรับประมวลผล 58, 000 ตัวการตอบสนอง เวลาลดลงเป็นมิลลิวินาทีรวมเข้าด้วยกันมันมาถึงเจ็ดวินาที โดยทั่วไปฉันบันทึก CPU สิบชั่วโมงบนเซิร์ฟเวอร์ของฉัน นี่มันใหญ่มาก เพราะถ้าฉันไม่ได้เกิดจากการรีเฟรชเซิร์ฟเวอร์ฉันสามารถอยู่บนเซิร์ฟเวอร์นั้นได้ ฉันลดการใช้เซิร์ฟเวอร์ลง 20 เปอร์เซ็นต์และคุณสามารถดูได้ทั้งก่อนและหลัง นั่นคือประเภทของการมองเห็นที่แม่นยำสามารถให้ได้ นอกจากนี้ยังมีบางสิ่งเพิ่มเติมที่เราอาจมองว่าทำไมคุณมีดัชนีเหล่านี้ทั้งหมดหากไม่ได้ใช้งาน พวกเขาสามารถติดตามได้ มีสถาปัตยกรรมและฉันจะปิดมันเนื่องจากเราไปถึงจุดสูงสุดของชั่วโมง ฉันเป็นผู้เชื่อที่แท้จริงในการแก้ปัญหานี้และเราต้องการให้คุณเป็นผู้เชื่อที่แท้จริง ที่ IDERA เราเชื่อว่าการทดลองสร้างลูกค้าดังนั้นหากคุณสนใจเราสามารถทำการประเมินในไซต์ของคุณ

เมื่อนั้นฉันจะส่งสัญญาณเตือนกลับ

Eric Kavanagh: ใช่นี่เป็นรายละเอียดมากมายที่คุณแสดงให้เห็น มันค่อนข้างน่าสนใจจริงๆ ฉันคิดว่าฉันอาจเคยพูดกับคุณในอดีตว่า - และฉันรู้ว่าในเว็บคาสต์อื่น ๆ ที่เราเคยทำกับ IDERA ฉันได้พูดถึงเรื่องนี้ - ฉันได้รับการติดตามอย่างแม่นยำตั้งแต่ก่อนที่ IDERA ได้มา ตลอดทางจนถึงปี 2008 ฉันคิดว่าหรือปี 2009 ฉันรู้สึกทึ่งกับมันในตอนนั้น ฉันอยากรู้ว่าจะต้องทำงานมากแค่ไหนในการทำงานบนแอพพลิเคชั่นรุ่นใหม่ คุณพูดถึง SAP HANA ซึ่งฉันคิดว่าค่อนข้างน่าประทับใจที่คุณสามารถขุดเข้าไปในสถาปัตยกรรม HANA และทำการแก้ไขปัญหาที่นั่นได้ คุณมีกี่คน มีความพยายามในส่วนของคุณมากน้อยเพียงใดและสามารถทำอะไรได้บ้างในแบบไดนามิกซึ่งหมายความว่าเมื่อเครื่องมือได้รับการปรับใช้คุณจะเริ่มคลานไปรอบ ๆ และมองเห็นสิ่งต่าง ๆ มีจำนวนเท่าไรที่สามารถตรวจสอบโดยใช้เครื่องมือแบบไดนามิกเพื่อให้คุณสามารถช่วยเหลือผู้คนในการแก้ไขปัญหาสภาพแวดล้อมที่ซับซ้อน

Bill Ellis: คุณถามคำถามมากมายที่นั่น

Eric Kavanagh: ฉันรู้ว่าขอโทษ

Bill Ellis: ฉันให้รายละเอียดมากมายเพราะสำหรับแอปพลิเคชันเหล่านี้เมื่อดูที่รหัสปีศาจอยู่ในรายละเอียด คุณต้องมีรายละเอียดในระดับนั้นเพื่อให้สามารถมีสิ่งที่สามารถดำเนินการได้จริงๆ หากไม่มีการวัดที่สามารถดำเนินการได้คุณเพียงแค่รู้เกี่ยวกับอาการ คุณไม่ได้แก้ปัญหาจริงๆ IDERA เป็นเรื่องเกี่ยวกับการแก้ปัญหา การอยู่ด้านบนของรุ่นใหม่และสิ่งต่าง ๆ เป็นความท้าทายที่ยิ่งใหญ่ คำถามเกี่ยวกับสิ่งที่ต้องทำนั่นคือการจัดการผลิตภัณฑ์ ฉันมีทัศนวิสัยไม่มากในทีมที่ทำให้เรารู้ถึงสิ่งต่างๆ ในแง่ของ HANA นั้นเป็นสิ่งที่เพิ่มเข้ามาใหม่ในกลุ่มผลิตภัณฑ์ IDERA มันน่าตื่นเต้นมาก สิ่งหนึ่งที่มีกับ HANA คือให้ฉันพูดเกี่ยวกับงานนี้เป็นครั้งที่สอง ในงานนี้ร้านค้า SAP จะทำเช่นนั้นเพื่อจำลองฐานข้อมูลเพื่อการรายงาน จากนั้นคุณจะต้องให้ผู้คนคืนดีกับสิ่งที่เป็นจริงในปัจจุบัน คุณมีฐานข้อมูลที่แตกต่างกันและพวกเขาจะไม่ซิงค์ตามระดับที่แตกต่างกัน มีเวลาและความพยายามมากมายรวมถึงฮาร์ดแวร์ซอฟต์แวร์และผู้คนในการดูแลรักษาทั้งหมด

แนวคิดของ HANA ที่จะมีฐานข้อมูลในหน่วยความจำแบบขนานสูงโดยทั่วไปเพื่อหลีกเลี่ยงความต้องการฐานข้อมูลซ้ำซ้อน เรามีฐานข้อมูลหนึ่งแหล่งที่มาของความจริงแหล่งข้อมูลที่ทันสมัยอยู่เสมอวิธีที่คุณหลีกเลี่ยงความจำเป็นในการดำเนินการคืนดีทั้งหมด ความสำคัญของประสิทธิภาพการทำงานของฐานข้อมูล HANA เพิ่มขึ้นฉันจะบอกว่า 10x หรืออย่างน้อยก็มีค่ามากกว่าผลรวมของฐานข้อมูลอื่น ๆ เหล่านั้นฮาร์ดแวร์ทรัพยากรสามารถซื้อได้ ความสามารถในการจัดการ HANA ตอนนี้องค์ประกอบนั้นอยู่ในการทดสอบเบต้าในตอนนี้มันเป็นสิ่งที่กำลังจะไป GA เร็ว ๆ นี้ นั่นเป็นเรื่องที่น่าตื่นเต้นสำหรับ IDERA และสำหรับเราที่จะสนับสนุนแพลตฟอร์ม SAP ฉันไม่แน่ใจว่าส่วนอื่นของคำถามของคุณฉันเป็นแบบสั้น แต่ -

Eric Kavanagh: ไม่มีทุกอย่างที่ดีในนั้น ฉันขว้างทั้งกลุ่มมาที่คุณทั้งหมดในครั้งเดียวดังนั้นจึงเสียใจเกี่ยวกับเรื่องนั้น ฉันหลงเสน่ห์จริงๆฉันหมายถึงว่านี่ไม่ใช่แอปพลิเคชันที่ง่ายมากใช่ไหม คุณกำลังขุดลึกลงไปในเครื่องมือเหล่านี้และทำความเข้าใจว่าพวกเขามีปฏิสัมพันธ์กันอย่างไรและตรงประเด็นของคุณคุณต้องเรียงลำดับเรื่องราวเข้าด้วยกันในหัวของคุณ คุณต้องรวมบิตของข้อมูลเพื่อทำความเข้าใจกับสิ่งที่เกิดขึ้นจริงและสิ่งที่ทำให้คุณเกิดปัญหาดังนั้นคุณสามารถเข้าไปที่นั่นและแก้ไขปัญหาเหล่านั้นได้

ผู้เข้าร่วมประชุมคนหนึ่งถามว่าการใช้งาน Precise นั้นยากเพียงใด อีกคนถามว่าใครคือคน - ชัดแจ้ง DBAs - แต่ใครบ้างที่มีบทบาทอื่นในองค์กรที่จะใช้เครื่องมือเหล่านี้

Bill Ellis: ความ แม่นยำมีความซับซ้อนเล็กน้อยในการปรับใช้ คุณต้องมีความรู้เกี่ยวกับสภาพแวดล้อมของแอปพลิเคชั่นในแง่ที่คุณรู้ว่าแอพพลิเคชั่นนี้ทำงานบนฐานข้อมูลนี้มันต้องการหรือ - เว็บเซิร์ฟเวอร์ระดับกลางเป็นต้นฉันคิดว่าความซับซ้อนของบางแอปพลิเคชันเหล่านี้ จริงๆแล้วมันค่อนข้างง่าย หากฉันสามารถใช้เว็บเซิร์ฟเวอร์จนถึงฐานข้อมูลของคุณฉันสามารถทำเช่นนั้นได้ตั้งแต่ต้นจนจบ คุณสังเกตเห็นว่าฉันไม่ได้พูดอะไรเกี่ยวกับการทำเครื่องมือลูกค้าผู้ใช้ปลายทางและนั่นเป็นเพราะสิ่งที่เราทำคือเรารวมแบบไดนามิกดังนั้นคุณไม่จำเป็นต้องเปลี่ยนรหัสของคุณหรือสิ่งอื่นใด JavaScript เข้าสู่กรอบหน้าแอปพลิเคชัน ไม่ว่าผู้ใช้จะอยู่ที่ใดในโลกเมื่อพวกเขาเข้าถึง URL จากแอปพลิเคชันของคุณและพวกเขานำหน้านั้นลงมา ที่ช่วยให้เราสามารถเลือก ID ผู้ใช้ที่อยู่ IP ของพวกเขารวมถึงเวลาการแสดงผลไบต์แรกของเวลาดำเนินการสคริปต์ขององค์ประกอบของหน้าแต่ละหน้าในเบราว์เซอร์ของผู้ใช้ปลายทาง

ในแง่ของการทำธุรกรรมคุณไม่จำเป็นต้องแมปการทำธุรกรรมออกไปเพราะมันเชื่อมโยงกันอย่างแน่นหนา URL นี้กลายเป็นจุดเริ่มต้นของ JVM จากนั้นเรียกใช้ข้อความนี้ส่งผลให้ JVC ติดมาจากฐานข้อมูล เราสามารถจับจุดเชื่อมต่อตามธรรมชาติเหล่านั้นโดยทั่วไปแล้วนำเสนอให้คุณในหน้าจอธุรกรรมที่ฉันแสดงให้คุณเห็นว่าเราคำนวณเวลาเท่าไรหรือเปอร์เซ็นต์เวลาที่ใช้ในแต่ละขั้นตอน ทั้งหมดนี้ทำโดยอัตโนมัติ โดยทั่วไปเราจะจัดสรรเวลา 90 นาทีในการทำ - เพื่อติดตั้งแกนประมวลผลที่แม่นยำแล้วเริ่มการใช้งานแอปพลิเคชัน ขึ้นอยู่กับความรู้เกี่ยวกับแอปพลิเคชันอาจใช้เวลาบางช่วงเพิ่มเติมเพื่อรับใบสมัครทั้งหมด หลายคนใช้เพียงส่วนประกอบฐานข้อมูลของแม่นยำ ไม่เป็นไร. โดยทั่วไปคุณสามารถทำลายสิ่งนี้แบ่งมันเป็นส่วนประกอบที่คุณรู้สึกว่าเว็บไซต์ของคุณต้องการ เราเชื่ออย่างแน่นอนว่าบริบทของการมีแอปพลิเคชันสแต็กทั้งหมดเป็นเครื่องมือเพื่อให้คุณเห็นว่าการพึ่งพาแบบเทียร์ถึงระดับนั้นขยายมูลค่าของการตรวจสอบแต่ละระดับอย่างแท้จริง หากใครต้องการที่จะสำรวจ instrumenting stack ใบสมัครของพวกเขาต่อไปโปรดไปที่เว็บไซต์ของเรา - ฉันเดาว่าเป็นวิธีที่ง่ายที่สุดในการขอข้อมูลเพิ่มเติมและเราจะหารือเกี่ยวกับมันเพิ่มเติมเล็กน้อย

Eric Kavanagh: ฉันจะโยนคำถามสั้น ๆ หนึ่งหรือสองข้อให้คุณ ฉันเดาว่าคุณกำลังรวบรวมและสร้างพื้นที่เก็บข้อมูลในช่วงเวลาที่ผ่านมาทั้งสำหรับลูกค้ารายบุคคลและในฐานะองค์กรโดยรวมของการมีปฏิสัมพันธ์ระหว่างแอปพลิเคชันต่างๆและฐานข้อมูลต่างๆ ในคำอื่น ๆ การสร้างแบบจำลองสถานการณ์ฉันเดาว่าเป็นสิ่งที่ฉันพูดถึง เป็นอย่างนั้นเหรอ? คุณรักษาพื้นที่เก็บข้อมูลของสถานการณ์ทั่วไปจริง ๆ เช่นที่คุณสามารถให้คำแนะนำกับผู้ใช้เมื่อสิ่งบางอย่างเข้ามาเล่น? เช่นเดียวกับ E-Business Suite เวอร์ชันนี้ฐานข้อมูลนี้เวอร์ชันอื่น ๆ - คุณทำอย่างนั้นหรือไม่?

Bill Ellis: ข้อมูลประเภทนั้นถูกสร้างขึ้นในรายงานการค้นพบ รายงานการค้นพบระบุว่าอะไรคือปัญหาคอขวดของประสิทธิภาพและขึ้นอยู่กับเวลาดำเนินการ ส่วนหนึ่งของรายงานการค้นพบนั้นเรียนรู้เพิ่มเติมและคุณจะทำอะไรต่อไป ข้อมูลหรือประสบการณ์จากลูกค้าและอื่น ๆ นั้นโดยทั่วไปจะรวมอยู่ในห้องสมุดของคำแนะนำนั้น

Eric Kavanagh: โอเคมันฟังดูดี คนดีงานนำเสนอที่ยอดเยี่ยมในวันนี้ บิลฉันรักรายละเอียดที่คุณมีอยู่ในนั้น ฉันแค่คิดว่านี่เป็นเรื่องที่ยอดเยี่ยมมากมีความละเอียดข้อมูลที่ละเอียดแสดงให้เห็นว่าสิ่งเหล่านี้ทำขึ้นได้อย่างไร เมื่อถึงจุดหนึ่งมันก็เกือบจะเหมือนเวทมนตร์ดำ แต่จริงๆแล้วมันไม่ใช่ มันเป็นเทคโนโลยีที่เฉพาะเจาะจงที่พวกคุณรวมตัวกันเพื่อทำความเข้าใจกับสภาพแวดล้อมที่ซับซ้อนมากและทำให้ผู้คนมีความสุขเพราะไม่มีใครชอบเมื่อแอปพลิเคชันทำงานช้า

พวกเราจะเก็บเว็บคาสต์นี้ไว้ คุณสามารถกระโดดออนไลน์เพื่อ Techopedia หรือ insideanalysis.com และว้าวขอบคุณสำหรับเวลาของคุณเราจะติดต่อคุณในครั้งต่อไป ดูแลลาก่อน