تسريع التطبيق: أداء أسرع للمستخدمين النهائيين

بواسطة Techopedia Staff ، 2 نوفمبر 2016

الوجبات الجاهزة: يناقش المضيف إريك كافاناغ أداء التطبيق وكيفية تحسين الكفاءة مع الدكتور روبن بلور وديز بلانشفيلد وبيل إليس من المعهد.

أنت لم تسجل الدخول حاليًا. يرجى تسجيل الدخول أو التسجيل لمشاهدة الفيديو.

إريك كافانا: سيداتي وسادتي ، مرحبًا بكم مرة أخرى في Hot Technologies. نعم فعلا! اسمي إريك كافاناغ ، سأكون مضيفك لبث آخر على شبكة الإنترنت اليوم في هذه السلسلة الممتعة والممتعة حقًا التي نتمتع بها كمجاملة لمسلسل غرفة الاجتماعات لدينا. العنوان هو "تسريع التطبيق: أداء أسرع للمستخدمين النهائيين". هيا الناس ، من لا يريد ذلك؟ إذا كنت الشخص الذي ساعد تطبيقك على العمل بشكل أسرع ، فأعتقد أنني الرجل الذي اشتريت البيرة لي في الحانة بعد العمل. يجب أن يكون الأمر رائعًا للمشي وتسريع تطبيق أي شخص.

هناك شريحة تخصك حقًا ، وضربني على TwitterEric_Kavanagh. أحاول دائمًا المتابعة ، وأعد دائمًا تغريدة إذا ذكرت لي ، لذلك لا تتردد في ذكر لي.

الغرض كله من هذا العرض هو التركيز على الجوانب المختلفة لتكنولوجيا المؤسسة والمساعدة حقًا في تحديد تخصصات معينة أو بعض الوجوه ، إذا أردت ذلك. في كثير من الأحيان ، يلتزم البائعون بشروط تسويقية معينة ويتحدثون عن كيفية قيامهم بذلك أو ذاك أو أي شيء آخر. لقد تم تصميم هذا العرض حقًا لمساعدة جمهورنا على فهم ما تحتاج إليه أداة البرنامج حتى تكون رائدة في مساحتها. شكل هذا يجري اثنين من المحللين. كل واحدة تذهب أولاً ، على عكس غرفة الإحاطة حيث يذهب البائع أولاً. يقدم كل منهم ما يعتقد أنه من المهم بالنسبة لك أن تعرفه عن نوع معين من التكنولوجيا.

اليوم نتحدث عن تسريع التطبيق. سوف نسمع من Dez Blanchfield والدكتور روبن بلور - جميعنا في جميع أنحاء العالم اليوم - ومن ثم بيل إيليس في منطقة فرجينيا الكبرى. مع ذلك ، سأسلمها إلى مقدمنا ​​الأول ، الدكتور بلور. لقد قمنا بتغريد هاشتاج #podcast بالمناسبة ، لذلك لا تتردد في التغريد. خذه بعيدا.

الدكتور روبن بلور: حسنًا ، شكرًا جزيلاً على هذه المقدمة. أداء التطبيق ومستويات الخدمة - هذا مجال ، لقد قمت بالكثير من العمل في هذا المجال على مر السنين ، بمعنى أنني قمت بالفعل بالكثير من العمل في مراقبة الأداء وممارسة التمارين في واحد بطريقة أو بأخرى ، وكيفية محاولة وحساب تلك المستويات. يجب القول أنه حتى - اعتدنا أن نعيش هذا العصر ، منذ فترة ، حيث بنى الناس أنظمة في صوامع. في الأساس ، لم يكن حجم العمل الذي يتعين عليهم القيام به فعلًا لجعل أداء النظام جيدًا بشكل معقول إذا كان في صومعة ، في الواقع صعبًا جدًا نظرًا لوجود قدر ضئيل جدًا من المتغيرات التي كان عليك أن تأخذها في الاعتبار. حالما وصلنا بالشبكة بشكل صحيح ، دخل التوجه التفاعلي والخدمة في المعادلة. حصلت صعبة بعض الشيء. يمكن أن يكون الأداء أحادي البعد. إذا كنت تفكر في تطبيق ينفذ مسار رمز معين بشكل متكرر ، فإن القيام بذلك بشكل معقول ، وفي الوقت المناسب ، يبدو وكأنه شيء أحادي البعد. بمجرد أن تبدأ الحديث عن مستويات الخدمة ، فأنت تتحدث بالفعل عن أشياء متعددة تتنافس على موارد الكمبيوتر. يصبح متعدد الأبعاد بسرعة كبيرة. إذا بدأت الحديث عن العمليات التجارية ، فيمكن ربط العمليات التجارية ببعضها من تطبيقات متعددة. إذا كنت تتحدث عن بنية موجهة نحو الخدمة ، فعندئذ يمكن أن يصل تطبيق معين بالفعل إلى إمكانيات تطبيقات متعددة. ثم يصبح شيء معقد للغاية.

نظرت إلى - منذ وقت طويل ، وجهت هذا المخطط. هذا الرسم البياني لا يقل عن 20 سنة. اسميها رسم تخطيطي لكل شيء لأنها طريقة للنظر إلى كل ما هو موجود في بيئة تكنولوجيا المعلومات. إنها حقًا أربع قطع فقط: المستخدمون ، البيانات ، البرامج والأجهزة. بالطبع يتغيرون مع مرور الوقت ، لكنك تدرك بالفعل عندما تنظر إلى هذا أن هناك انفجارًا هرميًا لكل واحدة من هذه القطع. نعم ، يمكن أن يكون الجهاز خادماً ، ولكن يتكون الخادم من عدة وحدات المعالجة المركزية (CPU) ، وتكنولوجيا الشبكات والذاكرة ، وهذا نوع من الكثير من وحدات التحكم ، كما يحدث. إذا نظرت بالفعل إلى هذا ، كل شيء ينقسم إلى أجزاء. إذا كنت تفكر فعلاً في محاولة تنظيم كل ذلك ، فيما يتعلق بالبيانات التي تتغير ، يتغير أداء البرنامج ، لأن الأجهزة تتغير ، وهكذا دواليك وما إلى ذلك ، فأنت تبحث بالفعل عن موقف متعدد الاختلافات صعب للغاية. هذا هو منحنى التعقيد. بالطبع منحنى التعقيد لكل شيء تقريبًا ، لكنني رأيته مرارًا وتكرارًا عند الحديث عن أجهزة الكمبيوتر. بشكل أساسي ، إذا وضعت العقد على أحد المحاور والوصلات المهمة على المحور الآخر ، فسينتهي بك الأمر بمنحنى التعقيد. لا يهم تقريبًا ماهية العقد والتوصيلات وسيؤدي ذلك إذا كنت تريد تمثيلًا لنمو الصوت في شبكة الهاتف.

في الواقع ، عندما تتحدث عن العقد في بيئة الكمبيوتر ، فأنت تتحدث عن أشياء فردية تهتم ببعضها البعض. اتضح أن التعقيد مسألة بنية متنوعة والقيود المختلفة التي تحاول طاعتها. أيضا ، الأرقام. عندما ترتفع الأرقام ، فإنها تصبح مجنونة. أجريت محادثة مثيرة للاهتمام أمس ، كنت أتحدث مع شخص ما - لا أستطيع أن أذكر من كان ، ولكن لا يهم حقًا - لقد كانوا يتحدثون عن موقع يحتوي على 40.000 - أي أربع مرات ، و 40000 - أمثلة لقواعد البيانات في الموقع. مجرد التفكير في ذلك - 40،000 قواعد بيانات مختلفة. بالطبع الشيء الوحيد الذي لدينا - كان من الواضح أن لديهم العديد من الآلاف من التطبيقات. نحن نتحدث عن منظمة كبيرة جدًا ، لكن لا يمكنني تسميتها. نظرت بالفعل إلى ذلك ، وتحاول فعلاً ، بطريقة أو بأخرى ، الحصول على مستويات الخدمة التي ستكون كافية في جميع المجالات لعدة مستخدمين ، مع توقعات متعددة ، إذا كنت ترغب في ذلك. إنه موقف معقد ، وكل ما أقوله حقًا هو ، هذه الأشياء معقدة. زيادة الأرقام دائما. يتم تحديد القيود من خلال العمليات التجارية وأهداف العمل. كنت قد لاحظت تغير التوقعات.

أتذكر بمجرد ظهور Gmail و Yahoo mail و Hotmail ، وجميع أنظمة البريد هذه ، بدأ الناس في توقع أن أنظمة البريد الداخلية الخاصة بهم داخل المؤسسة تستحق مستويات الخدمة لهذه العمليات الضخمة مع مزارع الخوادم الواسعة خارج المنظمة وبدأت في الضغط من أجل تحقيق كل هذا النوع من الأشياء. في الواقع ، تعد اتفاقيات مستوى الخدمة شيءًا ما ، لكن التوقع شيء آخر ويقاتلون بعضهم البعض داخل المنظمة ، وهو أمر محرج. هنا مجرد منظور الأعمال. في بعض الأنظمة ، يكون وقت الاستجابة الأمثل هو عُشر وقت الاستجابة البشرية. عُشر الثانية هو الوقت الذي يستغرقه كوبرا لدغك. إذا كنت تقف أمام كوبرا ، وقررت أن تعضك ، فوات الأوان ، فسوف يحدث ذلك لأنه لا يمكنك الرد في عُشر الثانية. إن عُشر الثانية تقريبًا هو الوقت الذي تستغرقه الكرة لترك يد الجرة للوصول إلى الرجل بالخفافيش. في الأساس ، عندما يرى أن الكرة ألقيت ، يجب عليه أن يرد في تلك اللحظة بالضبط. استجابة الإنسان ، نوع من الشيء المثير للاهتمام. من الواضح أن البرمجيات إلى البرمجيات ، يمكن أن يكون لها توقع أعلى.

ثم تحصل في بعض المواقف التي أعتقد أنها حالات السوق ، حيث تكون أولاً هي حيث تكون قيمة الأعمال. يبدو الأمر كما لو كنت ترغب في بيع سهم معين في البورصة على الأرجح ، على سبيل المثال ، لأنك تعتقد أنها تنخفض وكثير من الناس يعتقدون أنها تنخفض ، يمكنك الحصول على أفضل سعر إذا وصلت إلى السوق أولاً. هناك الكثير من المواقف ، وعرض الإعلانات وأشياء من هذا القبيل ، وموقف مشابه جدًا. لديك هذه الحركة من حيث توقعات مستوى الخدمة. لديك شيء واحد هو نوع من السقف الزجاجي للاستجابة البشرية. بمجرد أن يصبح برنامجًا إلى برنامج ، إذا كان لديك هذا الموقف في السقف ، فلا يوجد أفضل مستوى خدمة. أسرع من أي شخص آخر هو الأفضل.

حسنًا ، أعتقد أن هذا هو الشريحة الأخيرة التي كنت أقوم بها ، ولكن هذا فقط لإعطائك صورة كبيرة عن التعقيد ، بمجرد أن تنظر فعليًا إلى متطلبات المؤسسة ، الخدمة. لقد حصلت على الجانب الأيسر هنا ، ولديك إدارة نظام ، وهي عبارة عن مجموعة من البرامج التي تخدم إدارة الخدمة ، والتي تحاول إدارة مستوى الخدمة. أعلاه لديك إدارة أداء الأعمال. ثم إذا نظرت لأسفل هنا ، منطقة أتمتة إدارة الخدمات ، فإنك تحصل على خدمات مجزأة تتطور إلى خدمات موحدة ، إذا كنت تهتم حقًا بالاستثمار في هذا النوع من الأشياء ، الذي يتطور إلى خدمات متكاملة ، تتطور إلى خدمات محسّنة . معظم ما فعله الناس هو ، فقط في الركن الأيسر السفلي من هذا. ربما قليلا من إدارة الخدمات. إدارة أداء الأعمال ، نادرة جدا. مجزأة ، كل ذلك تقريبا. من شأنه أن عالم مثالي ملء هذه الشبكة. الأجهزة - ذكرت مشكلة التحسين الفرعي. يمكنك تحسين أجزاء النظام وليس مفيدًا للنظام بأكمله. إذا قمت بجعل القلب مثاليًا ، فقد يعمم دمك بسرعة كبيرة على بقية أعضاءك. هذه مشكلة في المنظمات الكبيرة ومستويات الخدمة. من الواضح أنه لن يتم تحقيق أي شيء بدون أدوات متطورة لأن المتغيرات قد حصلت للتو - حسنًا ، هناك العديد من المتغيرات التي يجب تجربتها وتحسينها.

بعد قولي هذا ، سأنتقل إلى Dez الذي سيتحدث عن شيء آخر تمامًا ، كما آمل.

ديز بلانشفيلد: شكرًا لك ، روبن. مثل الدكتور روبن بلور ، لقد أمضيت سنوات عديدة في التفكير في أداء أنظمة معقدة للغاية على نطاق واسع للغاية. ربما ليس بنفس مقياس روبن ، لكن الأداء موضوع يومي وهو جزء من الحمض النووي الخاص بنا الذي يريد الأداء ، للحصول على أفضل ما في كل شيء. في الحقيقة ، لقد استخدمت رسمًا لأحد الأشياء المفضلة في العالم ، سباق سيارات الفورمولا 1 ، حيث يظل الكوكب بأكمله ثابتًا لفترة من الوقت ويشاهد سيارات تدور بسرعة كبيرة. في كل جانب ، لا يوجد جانب في الصيغة I لا يتعلق بالتحديد بالحصول على الأداء. يلجأ الكثير من الناس إلى هذه الرياضة لأنهم يعتقدون أنها مضيعة للمال. اتضح أن السيارة التي نقودها كل يوم لإسقاط الأطفال في كرة القدم في عطلات نهاية الأسبوع والمدرسة في الأيام الأخرى ، مشتقة من التطوير القائم على الأداء والبحث. إنه نوع من حياة سباق سيارات الفورمولا 1. غالبًا ما تأتي التكنولوجيا اليومية ، العلوم اليومية ، من أمثال شيء ركز بشكل محض على الأداء العالي.

على الرغم من ذلك ، فإن الواقع هو أن عالمنا "الدائم دائمًا" ، والذي يتطلب وقت تشغيل بنسبة 100 بالمائة - كما ذكر روبن سابقًا - بأشياء مثل إدخال بريد الويب والخدمات الأخرى التي نتعامل معها كأمر مسلم به في الفضاء المستمر ، ونتوقع الآن أن مشروعنا وبيئة العمل. الحقيقة هي أن كونك دائمًا لا يعني دائمًا أنك تفي باتفاقية مستوى الخدمة. لدي هذا على الحاجة إلى إدارة أداء التطبيقات وتوافر اتفاقيات مستوى الخدمة التوافر قد تحول جذري في العقد الماضي. نحن لا نحاول فقط القلق بشأن أداء نظام واحد بعد الآن. عندما كان العالم أبسط قليلاً ، فقد يكون لدينا موقف حيث يمكن مراقبة خادم واحد يشغل خدمات متعددة بشكل مباشر وكان من السهل نسبياً دعمه. يمكننا - وهنا قلبي ، الأشياء التي اعتدنا أن تقلق بشأنها عندما كنت مسؤول النظام على سبيل المثال ، منذ سنوات عديدة - كنا ننظر حولنا ، هل الخدمة عادة ما تستجيب وتستجيب؟ هل يمكنني تسجيل الدخول إلى محطة على سبيل المثال؟ هل يستجيب نظام التشغيل وهل يمكنني كتابة الأوامر؟ هل التطبيقات قيد التشغيل؟ هل يمكنني رؤية العمليات والذاكرة في فعل الأشياء و I / O عبر الشبكة وما إلى ذلك؟ في أيام أجهزة الكمبيوتر المركزية ، يمكنك سماع الأشرطة التي تنطلق من zip-zip-zip والورق يتساقط منها.

هل تستجيب التطبيقات وهل يمكننا تسجيل الدخول والقيام بالأشياء عليها؟ هل يمكن للمستخدمين الاتصال ببعض هذه الخوادم؟ إنها تستمر. إنها أساسية إلى حد ما ، كما تعلمون. ثم بعض منها مضحك - هل مكتب المساعدة أخضر؟ لأنه إذا لم يكن كذلك ، فكل شيء يسير على ما يرام ، ومن سيحصل على الكعك؟ كانت الحياة بسيطة حقا في تلك الأيام. حتى في تلك الأيام ، وبعد ذلك أتحدث إلى 20-30 عامًا ، كان التعقيد لا يزال مرتفعًا للغاية. يمكننا ، بطريقة واضحة نسبياً ، إدارة اتفاقيات مستوى الخدمة ومراقبة الأداء. لم يعد بإمكاننا القيام بذلك باليد ، كما ألمح روبن. التحدي كبير جدا. الحقيقة هي الوقت الذي يمكن فيه لعدد قليل من التطبيقات الجيدة والمشرفين وشبكة النظام وقاعدة البيانات أن يراقبوا ويوافقوا على اتفاقيات مستوى الخدمة. لقد ولت اتفاقيات مستوى الخدمة الآن حتى أنني كافحت في الليلة الماضية عندما كنت أجمع مذكراتي النهائية معًا حتى لأفكر في العام الماضي عندما تمكنت آخر مرة من إلقاء نظرة على نظام مكدس شديد التعقيد وفهمه وفهم ما كان عليه يحدث تحت غطاء محرك السيارة ، ولقد جئت من خلفية تقنية عميقة. لا أستطيع أن أتخيل ما يشبه مواجهة ذلك على أساس يومي الآن بطريقة إدارية.

ماذا حدث؟ حسنًا ، في عام 1996 ، تم تحويل التطبيقات التي تعتمد على قواعد البيانات مع ازدهار الإنترنت. لقد كان الكثير منا من خلال ذلك. حتى لو لم تكن حول طفرة الإنترنت ، يمكنك بسهولة أن تنظر حولي وتدرك أنه في الحياة اليومية ، نربط كل شيء بالإنترنت الآن. أعتقد أن لدينا محمصة مزودة على ما يبدو بخيار الحصول على Wi-Fi وهو أمر مثير للسخرية ، لأنني لا أحتاج إلى محمصة خبز متصلة بالإنترنت. في 2000s ، ولا سيما أوائل 2000s ، كان علينا أن نتعامل مع هذا النمو الهائل في جولة التعقيد تقديم أداء الخدمة في ازدهار دوت كوم. ثم ظهرت شرارة أخرى مثيرة للسخرية على الويب 2.0 ، حيث ظهرت الهواتف الذكية وأصبحت التطبيقات في متناول أيدينا على مدار الساعة طوال أيام الأسبوع وكانت في وضع التشغيل دائمًا.

إنه عام 2016 الآن ، نحن نواجه مستنقعًا آخر في شكل سحابة وبيانات كبيرة وتنقل. هذه أنظمة كبيرة جدًا لدرجة أنه يصعب في كثير من الأحيان فهمها ووضعها باللغة الإنجليزية البسيطة. عندما نفكر في حقيقة أن بعض الحيدات الكبيرة التي نتحدث عنها تحتوي على عشرات المئات من البيجابايت من البيانات. هذا هو مساحة القرص بالكامل والتخزين فقط لاستيعاب البريد الإلكتروني والصور والوسائط الاجتماعية. أو في بعض الحالات ، في مجال النقل والشحن واللوجستيات ، كل شيء في الخدمات المصرفية أو في مكان وجود أموالك أو في مكان وجودك أو في مكان وجود الشيء الذي اشتريته على موقع eBay. الموجة الكبيرة التالية التي نحن على وشك مواجهتها هي هذا التحدي الثقيل للغاية المتمثل في إنترنت الأشياء.

إذا لم يكن هذا سيئًا بما فيه الكفاية ، فنحن على وشك بناء الذكاء الاصطناعي والحوسبة المعرفية في كل شيء تقريبًا. نتحدث إلى محركات سيري وجوجل هذه الأيام. وأنا أعلم أن الأمازون حصلت على واحدة من تلقاء نفسها. يحتوي بايدو على أحد هذه الأجهزة التي يمكنك التحدث إليها ، ويقوم بتحويلها إلى نص ينتقل إلى نظام عادي ، وقاعدة البيانات تقوم بإجراء استعلام وتعود وتنعكس العملية. فكر في التعقيد الذي يحدث في ذلك. والحقيقة هي أن تعقيد المكدس التطبيق القياسي اليوم هو أبعد من القدرات البشرية. عندما تفكر في كل ما يحدث عندما تضغط على زر على جهازك الذكي أو جهازك اللوحي ، فإنك تتحدث إليه ، وتحول ذلك إلى نص ، وتعمل على طول الطريق إلى الإنترنت إلى نظام خلفي ، وتتلقى الواجهة الأمامية هذا ، يحوله إلى استعلام ، ويدير الاستعلام من خلال مكدس للتطبيق ، ويخضع لقاعدة بيانات ، ويصل للقرص ، ويخرج ، وفي الوسط هناك شبكة للناقلين ، وهناك مركز لحالة الشبكة المحلية. التعقيد مجنون.

نحن نؤكد بشكل فعال هذا كما فرط. تعقيد وسرعة فرط هو مجرد سقي العين. أصبحت التطبيقات وقواعد البيانات كبيرة للغاية ومعقدة للغاية ، بحيث أصبحت إدارة الأداء في الواقع علمًا بحد ذاته. يشير الكثيرون إلى ذلك باعتباره علم الصواريخ. لدينا تقنية في الموقع ، ولدينا تقنية خارج الموقع ، ولدينا مجموعة من خيارات مركز البيانات ؛ المادية والظاهرية. لدينا خوادم فعلية وظاهرية ، لدينا سحابة ، ولدينا بنية تحتية كخدمة ومنصة كخدمة وبرمجيات كخدمة ، أصبحنا الآن أمرا مفروغا منه. أصبح هذا الأخير ، وهو برنامج كخدمة ، مخيفًا لبعض الوقت قبل بضع سنوات عندما أدرك المدير المالي وأجزاء من المنظمة أنه بإمكانهم الحصول على بطاقة الائتمان الخاصة بهم وشراء الأشياء بأنفسهم والالتفاف حول مدير المعلومات ، ولقبناها فعليًا باسم "الظل" IT "و CIOs يحاولون الآن إعادة هذا الوضع وإعادة التحكم في المصارعة مرة أخرى.

في البنية التحتية ، لدينا شبكات محددة بالبرمجيات ، والمحاكاة الافتراضية لوظائف الشبكة ، وأدناه ، ربما لدينا الآن ، لدينا الآن خدمات مصغرة وتطبيقات للخدمات النشطة. عندما تنقر على عنوان URL ، فهناك مجموعة من منطق العمل الذي يقع في نهاية عنوان URL هذا والذي يصف ما يحتاجه لتسليمه بالفعل. ليس بالضرورة أن يكون هناك منطق مُسبق مُنتظر. لدينا قواعد بيانات تقليدية على جانب واحد تتسع بشكل كبير جدًا. لدينا أمثال البنية التحتية Hadoop والنظم الإيكولوجية في الطيف الأخرى التي هي كبيرة جدا بحيث ، كما قلت ، أنت تتحدث عن مئات من بايت من البيانات الآن. لقد حصلنا على قابلية التنقل المعقدة بقدر ما تحمل الأجهزة المحمولة وأجهزة الكمبيوتر المحمولة والهواتف المحمولة والأجهزة اللوحية.

لدينا BYOD في بعض البيئات المغلقة وبشكل متزايد الآن ، لأن الأشخاص ذوي الخبرة في Gen Y يجلبون أجهزتهم الخاصة. لقد سمحنا لهم بالتحدث معهم حول واجهات الويب. إما عبر الإنترنت أو عبر شبكة Wi-Fi ، لدينا خدمة الواي فاي المجانية في المقهى بالطابق السفلي لأنها تتناول القهوة. أو لدينا خدمة الواي فاي الداخلية. آلة لآلة موجودة الآن من أي وقت مضى. هذا ليس جزءًا مباشرًا من إنترنت الأشياء ، ولكنه متصل أيضًا. إنترنت الأشياء هي لعبة جديدة تمامًا من التعقيد وهذا أمر محير. ذكاء اصطناعي ، وإذا كنت تعتقد أن ما نلعب به الآن ، مع كل أجهزة Siri وغيرها من الأجهزة ذات الصلة التي نتحدث إليها معقدة ، فانتظر حتى تصل إلى موقف ترى فيه شيئًا يُدعى Olli وهو ثلاثي الأبعاد الحافلة المطبوعة التي تستوعب حوالي ستة أشخاص وتستطيع أن تقود سيارتها في جميع أنحاء المدينة ويمكنك التحدث باللغة الإنجليزية بشكل عادي ، وسوف تتحدث إليك. إذا وصل إلى حركة المرور ، فستقرر الدوران يسارًا أو يمينًا خارج المنطقة الرئيسية حيث توجد حركة مرور. أثناء الدوران وأنت تشعر بالقلق حيال سبب تحوله إلى اليسار أو إلى اليمين من الطريق الرئيسي ، سيقول لك: "لا تقلق ، أنا على وشك الانعطاف إلى اليسار. هناك حركة مرور إلى الأمام وسأذهب حولها. "

إن إدارة أداء جميع الأنظمة الموجودة هناك وكل التعقيد ، وتتبع أين تذهب هذه البيانات ، سواء كانت تذهب إلى قاعدة البيانات ، وجميع الروابط البينية وجميع البتات ذات الصلة هي مجرد أمر محير. والحقيقة هي أن إدارة الأداء و SLAs بالسرعة والحجم الحاليين تتطلب أدوات وأنظمة ، وهذا لم يعد افتراضيًا مجرد شيء تعتقد أنه سيكون من الجيد أن يكون لديك أداة - إنه شرط أساسي ؛ انها مجرد ضرورة مطلقة. إليك بعض الأمثلة على ذلك ، مثال على قائمة من المخططات التصميمية لتصميم التطبيقات عالية المستوى لسحابة OpenStack ، والمعروفة بالبرمجيات مفتوحة المصدر. هذه مجرد قطعة كبيرة. هذه ليست مجرد خوادم وقاعدة بيانات. هذا هو المكان الذي يمثل كل نقطة زرقاء صغيرة مجموعات من الأشياء. في بعض الحالات ، الملفات والخوادم أو مئات قواعد البيانات أو بالطبع لا تزيد عن عشرات الآلاف من أجزاء صغيرة من منطق التطبيقات قيد التشغيل. هذه نسخة صغيرة. هو حقا العقل محير للغاية عندما تبدأ التفكير في التعقيد الذي يحدث في هذا. اليوم ، حتى في مساحة البيانات الكبيرة فقط ، سأضع بعض لقطات العلامات التجارية فقط. عندما تفكر في جميع القطع التي يتعين علينا إدارتها هنا ، فنحن لا نتحدث فقط عن علامة تجارية واحدة بالضرورة ، فهذه كلها علامات تجارية في المشهد البيانات الكبير والعلامة التجارية العليا ، وليس فقط كل واحدة صغيرة أو مفتوحة المصدر. نظرتم وتعتقد أنه مخطط محير للعقل.

دعنا فقط نلقي نظرة على بضع قطاعات. لنأخذ التسويق ، على سبيل المثال. إليك مخططًا مشابهًا ولكن من خلال مجموعات التكنولوجيا المتوفرة في تكنولوجيا التسويق وحدها. هذا هو الرسم البياني 2011. إليك نسخة 2016. مجرد التفكير في ، هذا هو مجرد عدد العلامات التجارية للمنتجات التي يمكنك تشغيلها للحصول على التكنولوجيا فيما يتعلق بتكنولوجيا التسويق. ليس تعقيد الأنظمة الموجودة داخلها ، وليس مختلف التطبيقات والويب والتطوير والشبكة وغيرها. فقط العلامة التجارية. هناك من قبل ، قبل خمس سنوات ، وهنا اليوم. سوف يزداد الأمر سوءًا. نحن الآن في هذه المرحلة حيث الواقع ، لا يمكن للبشر ببساطة ضمان جميع اتفاقيات مستوى الخدمة. لا يمكننا الغوص في التفاصيل الكافية ، بالسرعة الكافية ، وعلى النطاق الذي نحتاجه. إليك مثال على شكل وحدة التحكم الحالية. هذا يشبه ما يقرب من عشرين من الشاشات الفردية التي يتم لصقها معًا متظاهرًا بأنها شاشة رائعة كبيرة تراقب كل قطعة صغيرة. من المثير للاهتمام هنا ، لن أذكر العلامة التجارية ، لكن منصة المراقبة هذه تراقب تطبيقًا واحدًا في بيئة لوجستية وشحن. تطبيق واحد فقط. إذا كنت تفكر في ما كان يتحدث عنه روبن حيث يمكن للمؤسسات أن تملك 40،000 قاعدة بيانات الآن في بيئات الإنتاج. هل يمكنك فقط تصور 40،000 نسخة من هذه المجموعة من الشاشات التي تراقب تطبيقًا ما يمكن أن تكون؟ إنه عالم شجاع للغاية نعيش فيه. وكما قال روبن وسأردده تمامًا ، فإن 100٪ يردد أنه بدون الأدوات المناسبة وبدون الدعم المناسب والقوم على الطاولة باستخدام تلك الأدوات ، فإن أداء التطبيق لعبة ضائعة للبشر و يجب أن يتم ذلك عن طريق الأدوات والبرامج.

مع ذلك ، سأنتقل إلى أصدقائنا في IDERA.

إريك كافانا: حسنًا ، بيل.

بيل إيليس: شكرًا لك. مشاركة شاشتي هنا. أعتقد أنه يمكن لشخص ما تأكيد أنه يمكنك رؤية شاشتي؟

الدكتور روبن بلور: نعم.

إريك كافانا: يبدو الأمر جيدًا .

بيل إيليس: شكرًا لك. الشيء الوحيد الذي أشار إليه ، كان لا يمكنني الانتظار حتى لو كانت السيارة ذاتية القيادة. الشيء الوحيد الذي لم أسمع أي شخص يتحدث عنه هو ، ماذا يحدث عند تساقط الثلوج؟ أنا أتساءل ما إذا كان المهندسون في كاليفورنيا قد أدركوا أنه في أجزاء أخرى من البلاد تساقطت الثلوج قليلاً جدًا.

ديز بلانشفيلد: أحب ذلك ، سأتذكر ذلك.

إريك كافاناغ: نموذجي ميل واحد في الساعة.

بيل إليس: نحن هنا للحديث عن إدارة أداء التطبيقات في بيئة معقدة. شيء واحد أود التحدث عنه هو ، كثير من الناس ، عندما يتحدثون عن الأداء ، وطبيعة رد الفعل ، هي عدد أكبر من الخوادم ، والمزيد من وحدة المعالجة المركزية ، والمزيد من الذاكرة ، وما إلى ذلك. الجانب الآخر من هذه العملة هو معالجة الكفاءة. حقًا ، هذا وجهان لعملة واحدة وسنلقي نظرة على كلاهما. الهدف النهائي هو تلبية اتفاقات مستوى الخدمة للمعاملات التجارية. في نهاية المطاف كل هذه التكنولوجيا موجودة لرجال الأعمال. تحدثنا عن وجود قاعدة بيانات إدارة الأداء الصناعة الأولى. المثل الأعلى لذلك هو أن يتناسب مع القالب المثالي للأداء وإدارته من بداية دورة حياة التطبيقات.

المواضيع تغلي حقًا إلى أربع قطع ؛ واحد هو عملية إدارة الأداء. تحدثنا إلى الجميع ، وكل شخص لديه الأدوات. إذا لم يكن لديهم أدوات ، لديهم نصوص أو أوامر ، لكن ما يفتقدونه هو السياق. السياق هو مجرد ربط النقاط عبر مكدسات التطبيق. هذه التطبيقات لـ - تعتمد على المستعرض. يتم ربطها بإحكام من المستوى إلى المستوى. كيف تتفاعل الطبقات أمر حيوي أيضًا. ثم ، نحن نتحدث عن الصفقة التجارية. سنوفر الرؤية ليس فقط للأشخاص التقنيين ، ولكن أيضًا لأصحاب التطبيقات ومديري العمليات.

لديّ دراسات حالة زوجين لأشاركها معك في كيفية استخدام العملاء لها. هذا جزء عملي جدًا من العرض التقديمي هنا. دعونا نلقي نظرة على ما يحدث عادة. أحب الرسم - لقد كان مثل مجموعة من التقنيات لا تصدق. لقد نما عدد التقنيات في مركز البيانات ونما ونما. في هذه الأثناء ، لا يهتم المستخدم النهائي بذلك ، ويكون غافلاً عنه. إنهم يريدون فقط ممارسة المعاملة ، إذا كانت متوفرة ، وأكملها بسرعة. ما يحدث عادةً هو أن المهنيين في مجال تكنولوجيا المعلومات غير مدركين أن المستخدمين النهائيين واجهوا مشكلة حتى يقدموا تقريرهم الذاتي. هذا ينطلق من عملية بطيئة تستغرق وقتًا طويلاً وغالبًا ما تكون محبطة. ما يحدث هو ، سيفتح الأشخاص أدواتهم ، وينظرون إلى مجموعة فرعية من مكدس التطبيق الخاص بهم. مع هذه المجموعة الفرعية ، يصبح من الصعب للغاية الإجابة على أبسط سؤال. هل من المعتاد أن تواجهك المشكلة؟ ما الصفقة هو؟ حيث في مكدس التطبيق هو عنق الزجاجة؟ من خلال قضاء كل هذا الوقت ، وتبحث عن فئة ، وعدم القدرة على الإجابة على هذه الأسئلة ، ينتهي بك الأمر إلى إنفاق الكثير من الوقت والطاقة ، والكثير من الموظفين ، والأموال ، ونوع الطاقة في اكتشاف ذلك.

لحل هذه المشكلة ، من أجل توفير طريقة أفضل ، ما تقوم به Precise فعليًا هو أن تأخذ معاملة تتبع المستخدم النهائي ، وتلتقط البيانات الوصفية عنها ، وتتبع المعاملة عبر الشبكة ، في خادم الويب ، إلى مستوى منطق العمل و نحن ندعم .NET و ABAP و PeopleCode و E-Business Suite ، في تطبيقات متعددة المستويات تتفاعل في النهاية جميع المعاملات مع نظام التسجيل. سواء أكان ذلك عملية بحث عن مخزون ، عمل وقت إعداد التقارير ، فهم يتفاعلون دائمًا مع قاعدة البيانات. تصبح قاعدة البيانات أساس أداء الأعمال. قاعدة البيانات ، بدورها ، تعتمد على التخزين. ما إجابات البيانات الوصفية حول المعاملات ، من ، ما المعاملة ، أين في مكدس التطبيق ، ومن ثم لدينا رؤية عميقة على مستوى الكود لتظهر لك ما الذي ينفذ. يتم التقاط هذه المعلومات بشكل مستمر ، وتوضع في قاعدة بيانات إدارة الأداء - والتي تصبح ورقة موسيقية واحدة ليتمكن الجميع من رؤية ما يجري. هناك أشخاص ومنظمات مختلفة يهتمون بما يحدث: الخبراء الفنيون ، ومالكو التطبيقات ، وفي نهاية المطاف العمل نفسه. عند ظهور مشكلة ، فأنت تريد أن تكون قادرًا على استخراج معلومات حول هذه المعاملة.

قبل أن نلقي نظرة على معاملة الاستثمار ، أريد أن أوضح لك كيف يمكن أن يظهر ذلك لأشخاص مختلفين في المؤسسة. في فئة الإدارة ، قد ترغب في الحصول على نظرة عامة على تطبيقات متعددة. قد ترغب في معرفة الصحة التي يتم احتسابها وفقًا لتوافق اتفاقية مستوى الخدمة وتوافرها. أن الصحة لا تعني أن كل شيء يعمل بنسبة 100٪ بشكل مثالي. هناك مجال في هذه الحالة يمكنك أن ترى المعاملة الاستثمارية في حالة التحذير. الآن ، أعمق قليلاً ، ربما في خط العمل ، تريد الحصول على بعض التفاصيل الإضافية حول المعاملات الفردية ، عندما تخرق اتفاقيات مستوى الخدمة ، عدد العمليات ، وما إلى ذلك. سيرغب فريق العمليات في أن يتم إخطارك بذلك من خلال تنبيه لبعض فرز. لدينا تنبيهات الأداء المضمنة. نحن في الواقع قياس الأداء في متصفح المستخدم النهائي. سواء أكان ذلك في Internet Explorer أو Chrome أو Firefox ، وما إلى ذلك ، يمكننا اكتشاف ذلك ، فهذا يجيب على السؤال الأول: هل يواجه المستخدم النهائي مشكلة؟

دعنا نغوص في ونرى ماذا يمكننا أن نظهر حول ذلك. الأشخاص المهتمون بالأداء سيفتحون الدقة. كانوا يقومون بتقييم المعاملات. سيبحثون في عمود SLA لتحديد المعاملات التي لم تكن متوافقة مع SLA. سيكونون قادرين على رؤية المستخدمين النهائيين الذين تأثروا وكذلك ما فعلته تلك الصفقة أثناء تدفقها عبر التطبيق. طريقة فك تشفير هذه الهيروغليفية هي ، هذا هو المتصفح ، عنوان URL ، U هو عنوان URL ، هذه هي نقطة الدخول إلى JVM. الآن هذا JVM خاص يجعل خادم الويب ينادي إلى JVM الثاني الذي ينفذ بعد ذلك عبارة SQL. هذه مشكلة في قاعدة البيانات بوضوح لأن عبارة SQL هذه كانت مسؤولة عن 72 بالمائة من وقت الاستجابة. نحن نركز على الوقت. الوقت هو عملة الأداء. إنها كيفية تجربة المستخدمين النهائيين سواء كانت الأمور تسير ببطء أم لا ، وهو مقياس لاستهلاك الموارد. انه مفيد جدا. إنه نوع من المقياس الفردي الأكثر أهمية لتقييم الأداء. عندما يتم تسليم هذه المشكلة إلى DBA ، فهي ليست مجرد مشكلة في قاعدة بيانات ، إنها عبارة SQL هذه. هذا هو السياق الذي كنت أتحدث عنه.

الآن مسلحًا بهذه المعلومات ، أنا قادر على الدخول وتحليل ما حدث. أستطيع أن أرى أولاً وقبل كل شيء ، المحور ص هو وقت على مدار اليوم. إسمح لي ، المحور ص هو وقت الاستجابة ، المحور س هو الوقت على مدار اليوم. أستطيع أن أرى أن هناك مشكلة في قاعدة البيانات ، وهناك حادثان ، والعودة إلى هذا التدفق ، والتقاط بيان SQL هذا والدخول إلى طريقة عرض الخبير ، حيث يستطيع Precise أن يوضح لك ما يحدث ، وعناصر التحكم فيه ، والمدة التي تستغرقها هذه الشفرة إلى نفذ - اعدم. في مستوى قاعدة البيانات ، إنها خطة التنفيذ. ستلاحظ أن Precise اخترت خطة التنفيذ الحقيقية التي تم استخدامها في وقت التنفيذ ، والتي تتميز عن الخطة المقدرة ، والتي ستكون عند تقديم الخطة وليس أثناء وقت التنفيذ. قد يعكس أو لا يعكس أن قاعدة البيانات بالفعل.

الآن إلى هنا ، هو تحليل وقت الاستجابة لبيان SQL. تسعين في المئة من الوقت الذي يقضيه في التخزين ؛ تم استخدام عشرة في المئة في وحدة المعالجة المركزية. أستطيع أن أرى نص عبارة SQL وكذلك تقرير النتائج. يبدأ نص عبارة SQL بالفعل في الكشف عن بعض مشكلات الترميز. هو اختيار نجمة. التي تعيد جميع الصفوف - عفوا ، كل الأعمدة من الصفوف التي تم إرجاعها. نحن نرجع الأعمدة الإضافية التي قد يحتاجها التطبيق أو لا يحتاجها. هذه الأعمدة تستهلك مساحة وموارد للمعالجة. إذا قمت بتشغيل SAP ، فإن أحد التغييرات الكبيرة ، لأن قاعدة بيانات HANA هي عموديًا ، هو أن إعادة كتابة SAP بشكل أساسي لا تختار تحديد النجمة بحيث يمكنها تقليل استهلاك الموارد بشكل كبير. هذا بشكل أساسي شيء يحدث كثيرًا من الوقت أيضًا في التطبيقات المحلية ، سواء Java أو .NET أو إلخ.

هذه الشاشة ، يوضح لك من وماذا ومتى وأين ولماذا. السبب في ذلك ، مثل عبارة SQL وخطة التنفيذ التي تسمح لك بحل المشاكل. نظرًا لأن Precise يعمل بشكل مستمر ، يمكنك القياس فعليًا قبل وبعد ، على مستوى بيان SQL ، على مستوى المعاملة ، بحيث يمكنك إما قياس نفسك ، وكذلك من خلال مالكي التطبيق والإدارة ، لحل المشكلة . هذه الوثائق مفيدة حقا. هناك الكثير من التعقيد في مكدس التطبيق هذا. من بين العديد من التطبيقات ، في الواقع ، كل شخص تحدثنا معه ، يعمل على الأقل جزءًا من حزمة التطبيقات ضمن برنامج VMware. في هذه الحالة ، يبحثون في تطبيق خدمة العملاء ، وينظرون في وقت المعاملة ، ويربطون بينه وبين التباطؤ حدث افتراضي. المسارات الدقيقة لجميع الأحداث الافتراضية. لدينا مكون إضافي لـ vCenter لالتقاط ذلك.

نحن أيضا قادرون على اكتشاف التنافس. خلاف يختلف عن الاستخدام. تظهر فعليًا عندما يؤثر أحد الجيران الصاخبين على الضيف VM الخاص بك ، في سياق تطبيق خادم العميل. الآن ، أنا قادر على البحث عن المعلومات والحصول عليها ، ويمكنني في الواقع رؤية جهازي VMs المتنافسين ، في هذه الحالة ، على موارد وحدة المعالجة المركزية. هذا يسمح لي برؤية حتى أتمكن من النظر إلى الجدولة. يمكنني وضع ضيف VM على خادم فعلي مختلف. كل هذه الأنواع من الأشياء التي قد تستجيب لها ، وبعد ذلك ، بالإضافة إلى ذلك ، يمكنني في الواقع أن أنظر إلى كفاءة الشفرة ربما لجعلها تستخدم وحدة CPU أقل. أعتقد أن لدي مثالًا جيدًا في هذا العرض التقديمي حول كيفية تمكن شخص ما من تقليل استهلاك وحدة المعالجة المركزية بأوامر من حيث الحجم.

كان ذلك برنامج VMware. دعنا نذهب إلى رمز نفسه ، رمز التطبيق. سيكون بإمكان Precise أن يوضح لك ما يحدث داخل Java و .NET ورمز ABAP و E-Business و PeopleCode وما إلى ذلك. هذه هي نقاط الدخول إلى WebLogic ، في هذه الحالة. في الأسفل ، يوجد تقرير بالنتائج يخبرني أن هذه الأدوات التي تحتاج إلى النظر إليها ، ستخبرني أنك قد حصلت على هذا النظام. مرة أخرى ، قم بالتمرير لأسفل داخل مستوى منطق العمل ، لإظهار ما يجري. في هذه الحالة ، أنا أنظر إلى حالات معينة ؛ أنا أيضا دعم المجموعات. إذا كان لديك العديد من JVMs قيد التشغيل ، يمكنك إما النظر إلى المجموعة ككل ، أو إلقاء نظرة على الاختناقات داخل JVM الفردية.

كما تحصل في تأمين ، يمكنني الدخول في استثناءات. الاستثناء مختلف قليلاً عن مشكلة الأداء. عادة ، يتم تشغيل الاستثناءات بسرعة كبيرة. نظرًا لوجود خطأ منطقي ، وعندما تضغط على هذا الخطأ المنطقي ، ينتهي. كنا قادرين على التقاط تتبع مكدس في بداية الاستثناء ، وهذا يمكن أن يوفر الكثير من الوقت لأنه يمر يحاول معرفة ما يحدث ، لديك فقط تتبع المكدس ، هناك. نحن أيضا قادرون على التقاط تسرب الذاكرة كذلك. يتضمن الحل أيضًا قاعدة بيانات المستوى ، يمكنني الدخول ، يمكنني تقييم مثيل قاعدة البيانات. مرة أخرى ، يكون المحور ص هو المكان الذي تم إنفاق الوقت فيه ، المحور س هو الوقت على مدار اليوم. يوجد تقرير بالنتائج يخبرني تلقائيًا بما يحدث في النظام وما الذي قد أطلع عليه.

أحد الأشياء حول تقرير نتائج Precise ، لا ينظر فقط إلى السجلات أو حالة الانتظار - إنه يبحث في جميع حالات التنفيذ بما في ذلك وحدة المعالجة المركزية ، وكذلك إرجاع المعلومات من التخزين. يعد التخزين جزءًا مهمًا للغاية من مكدس التطبيقات ، خاصة مع ظهور الحالة الصلبة. الحصول على المعلومات على هذه الخطوط يمكن أن يكون مفيدًا للغاية. بالنسبة إلى وحدات تخزين معينة ، يمكننا بالفعل البحث عن ما يحدث على مستوى الجهاز الفردي وإظهاره. هذا النوع من المعلومات - مرة أخرى ، هو رؤية عميقة ؛ إنه واسع النطاق - لإعطائك معلومات كافية فقط للحصول على مزيد من الفاعلية لسحب كمحترف أداء التطبيق ، بحيث يمكنك تحسين التطبيقات الخاصة بك على أساس نهاية إلى نهاية لتلبية تلك المعاملات التجارية.

لديّ بضع دراسات حالة أردت مشاركتها معك. نحن نبحر بسرعة كبيرة. آمل أن أذهب بوتيرة جيدة. الحديث عن التخزين ، والجميع مع مرور الوقت يغير الأجهزة. هناك ضمان الأجهزة. هل حقا تسليم ما قاله لك البائع؟ يمكنك تقييم ذلك بدقة. أتيت ، وما حدث هنا ، وضعوا في الأساس وحدة تخزين جديدة ، ولكن عندما نظر مسؤولو التخزين إلى مستوى وحدة التخزين ، رأوا الكثير من الخلاف ويعتقدون أنه قد يكون هناك مشكلة في وحدة التخزين الجديدة هذه . النظر إلى المزيد من منظور نهاية إلى نهاية ، على وجه التحديد لإظهار مكان حدوث ذلك بالفعل. لقد انتقلوا فعليًا من حوالي 400 ميجابايت في الثانية ، حيث كان التخزين مسؤولًا عن 38 بالمائة من وقت الاستجابة ، لذلك فهو مرتفع جدًا. من خلال وحدة التخزين الجديدة ، قمنا في الواقع بزيادة الإنتاجية إلى ستة وسبعمائة ميغابايت في الثانية الواحدة ، بحيث تتضاعف بشكل أساسي ، ويمكننا خفض مساهمة مستوى التخزين في وقت المعاملة إلى النصف. أنا في الواقع قادر على رسم بياني لذلك من قبل ، هذه هي فترة التحول ، ثم بعد ذلك.

لذلك ، مرة أخرى ، وثائق لإثبات أن الاستثمار في الأجهزة كان يستحق كل هذا العناء وتم تسليمها كما توقع ذلك البائع المعين. هناك كل شيء ، نظرًا للتعقيد وعدد الأشياء ، هناك كل أنواع الأشياء التي يمكن أن تحدث. في هذه الحالة ، كان لديهم بالفعل موقف كان فيه الجميع يلومون DBA ، وكان DBA مثل "حسنًا ، ليس سريعًا جدًا." هنا نحن نبحث فعليًا عن تطبيق SAP ، أعتقد أن هذا النوع من السيناريو شائع جدًا . ما حدث كان ، كانوا يقومون بتطوير معاملة مخصصة للمستخدم. يشبه المستخدم ، "هذا بطيء جدًا". قال مشفر ABAP - هذه هي لغة البرمجة في SAP - "هذه مشكلة في قاعدة بيانات." انتهى الأمر بفتح "دقيقة" ؛ وقاسوا ذلك المستخدم النهائي 60 ثانية ، لذلك أكثر من دقيقة. أمضى ثلاثة وخمسون ثانية في النهاية الخلفية. لقد قاموا بالتنقيب في النهاية الخلفية وكانوا قادرين على كشف بيان SQL المقدم بترتيب تنازلي.

عبارة SQL الأعلى المسؤولة عن 25 بالمائة من استهلاك الموارد ، متوسط ​​وقت التنفيذ بها ملي ثانية. لا يمكنك إلقاء اللوم على قاعدة البيانات. أنت تعرف ، مهلا ، ليس بهذه السرعة ، يا رجل. والسؤال هو ، لماذا يوجد الكثير من عمليات الإعدام؟ حسنًا ، ارتدوا إلى ABAP ، وذهب إلى هناك ، ونظروا في تداخل الحلقة ، واكتشفوا أنهم كانوا يتصلون بقاعدة البيانات في المكان الخطأ ، لقد قاموا بالتغيير بشكل أساسي ، واختبروا التغيير والآن حان وقت الاستجابة الجديد خمس ثواني. بطيئة بعض الشيء ، لكنهم يمكن أن يتعايشوا مع ذلك. أفضل بكثير من 60 ثانية. في بعض الأحيان ، مجرد الخروج ، هل هو رمز التطبيق ، هل هو قاعدة البيانات ، هل هو التخزين؟ هذه هي المجالات التي يوجد فيها Precise ، من خلال الحصول على سياق المعاملات الشاملة ، حيث يأتي Precise. كنت أساسا إنهاء تلك الأشياء.

أنا أبحث في ذلك الوقت ، يبدو أنه لا يزال أمامنا القليل من الوقت لاستعراض المزيد منها. أنا أتدفق من خلال هذه. كان هذا التطبيق قيد التطوير لأكثر من عام. عندما ذهبوا إلى QA ، كانوا يرون أن خوادم الويب بلغوا الحد الأقصى 100 في المئة ويبدو أن التطبيق لا يمكن أن يعمل تحت برنامج VMware. أول شيء قاله الجميع هو: لا يمكن أن يعمل تحت برنامج VMware. "عرضت عليهم الدقة طرقًا إضافية لحل المشكلة. نظرنا في المعاملات ، ورأينا مكالمة خادم الويب ، كما يأتي في ASMX في IIS.NET. كشفت فعلا الكود الأساسي. ترى هذا حيث أشير؟ هذا هو 23 يوما ، 11 ساعة. واو ، كيف يكون ذلك ممكنا؟ حسنًا ، تستغرق كل دعوة 9.4 ثانية ويتم استدعاء هذا الشيء 215000 مرة. لكل دعوة ، فإنه يستخدم 6 ثوان من وحدة المعالجة المركزية. هذا هو السبب ، هذا الرمز هو السبب في أن هذا الشيء لا يمكن أن يتوسع أبداً. في الواقع ، لا يمكن أن الحجم في المادية.

ماذا فعلوا ، هل عادوا إلى مطوريهم وقالوا ، "هل يمكن لأي شخص إجراء تغيير؟" لقد خاضوا نوعًا من المسابقة ، واختبروا الاقتراحات المختلفة وتوصلوا إلى اقتراح كان قادراً على تشغيل الكثير أكثر كفاءة. أكملت النقطة الجديدة نقطة واحدة ، أقل بقليل من ثانيتين ، مع مائتي ثانية من الثانية في وحدة المعالجة المركزية. الآن يمكن أن يتوسع هذا ويمكن تشغيله في مزرعة VMware. تمكنا من توثيق ذلك بشكل أساسي في كل من مستوى الرمز وكذلك مستوى المعاملة. هذا هو نوع من قبل ، وبعد ذلك. الآن يمكنك أن ترى هنا في الرسم البياني شريط المكدس الذي يعرض الويب و. NET وقاعدة البيانات ، والآن أنت تتفاعل مع قاعدة البيانات. هذا ملف تعريف تتوقع أن تشاهده للتطبيق الذي كان يعمل بشكل طبيعي أكثر.

حسنًا ، أنا أختار وأختار من حيث الأشياء الإضافية التي يمكنني إظهارها لك. كثير من الناس يحبون هذا لأن هذا يبهر العديد من المتاجر. إذا كنت غير قادر على تلبية اتفاقية مستوى الخدمة التجارية ، وكان الجميع مثل "ساعدنا" ، فقد واجه هذا المتجر موقفًا حيث كانت اتفاقية مستوى الخدمة التجارية في الطلبات التي تم استلامها بحلول الساعة 3 مساءً ، ويتم شحنها في ذلك اليوم. من المهم جدًا أن يحصلوا على الطلبات ، والمستودع مشغول جدًا. شاشة طلب مبيعات JD Edwards ، كانت متجمدة ويمكنك الحصول على فكرة جيدة جدًا عن أن هذا نظام لإدارة مخزون التجزئة في الوقت المناسب. الرفوف الفارغة غير مقبولة في تجارة التجزئة. حصلت على البضائع هناك من أجل بيعها. ما فعلناه هو أننا تراجعنا ، في هذه الحالة ، نحن نبحث في قاعدة بيانات خادم SQL. الشكل والمظهر هو نفسه سواء أكان SQL أو Oracle أو DB2 أو Sybase.

لقد حددنا الاختيار من PS_PROD ونحن قادرون على التقاط المدة ، وحقيقة أنها تنفذ الكثير. يقابل اللون الأزرق الغامق المفتاح الذي قال إنهم لا ينتظرون بعض حالة الانتظار أو بعض قطع الأشجار أو حتى التخزين - يرتبط هذا الشيء بوحدة المعالجة المركزية. قمنا بتتبع عبارة SQL بحلول 34301 ، لذا في كل مرة يتم تنفيذ ذلك ، نقوم بزيادة عداداتنا لتتبعها. هذا يعني أنه لدينا سجل مفصل ويمكنني الوصول إليه من خلال النقر على زر النغمة هذا. وهنا علامة التبويب التاريخ. تعرض هذه الشاشة هنا متوسط ​​المدة مقابل التغييرات. الأربعاء والخميس والجمعة ، كان متوسط ​​المدة حوالي عُشر الثانية. يتجمد عدد قليل جدًا من الشاشة ، فهم قادرون على تلبية اتفاقية مستوى الخدمة التجارية. تعال إلى يوم 27 فبراير ، تغير شيء ما وفجأة ، فقد حان وقت التنفيذ ، وهذا في الواقع بطيء بما فيه الكفاية لإحداث مهل ، مما يؤدي إلى توقف الشاشة. دقيق ، من خلال الاحتفاظ بسجل مفصل ، بما في ذلك خطة التنفيذ والتغييرات العامة في فهارس الجدول إذا كانت SQL قيد الاستخدام. تمكنا من تحديد أن خطة الوصول قد تغيرت في 27 فبراير. من الاثنين إلى الأسبوع الجمعة السيئة. تأتي 5 مارس ، تغيرت خطة الوصول مرة أخرى. هذا اسبوع جيد هذا النجم الوردي يخبرنا عن حجم تحديثها.

يمكنك أن ترى هنا عدد الصفوف في الجداول الأساسية آخذ في الازدياد وهذا هو الحال بالنسبة للأعمال التجارية. تريد الجداول الخاصة بك لتنمو. الشيء هو أن العبارات يتم تحليلها ، وعبارات SQL تأتي ، ويتعين على المُحسِّن أن يقرر ما يجب القيام به واختيار متى تكون خطة التنفيذ سريعة ، واختيار خطة تنفيذ أخرى عندما تكون بطيئة ، مما يؤدي إلى تجميد الشاشة. على أساس التكنولوجيا العميقة ، أحتاج إلى معرفة ماهية خطة التنفيذ والتقاطها بدقة لي مع استكمال التاريخ والوقت. هذا هو الذي كان سريعا وفعالا ، هذا هو الذي كان بطيئا وغير فعال. يستخدم هذا الرابط تصفية ببساطة وحدة المعالجة المركزية أكثر من ذلك بكثير للتوفيق ، للقيام هذا البيان مزود معين. لا يزال لديهم نفس التأثير النهائي ، ولكن هذا الأساس يحتوي على وصفة أبطأ وأقل كفاءة لتقديم مجموعة النتائج. لذلك ، نحن نخطو. مهلا ، لدينا وقت لبضعة أكثر؟

إريك كافانا: نعم ، اذهب من أجل ذلك.

بيل إيليس: حسنًا ، سوف أتخطى ذلك إلى الأمام. شيء واحد أريدك أن تحيط به ، تحدثنا عن الأجهزة ، تحدثنا عن SAP ، تحدثنا عن .NET ، تحدثنا عن JD Edwards وبيئة Java-SQL Server. هذا هو SAP ، هنا ننظر إلى PeopleSoft. دقة مصفوفة الدعم واسعة وعميقة. إذا كان لديك تطبيق ، أكثر من المحتمل ، فيمكننا استخدامه لتوفير مستوى الرؤية هذا. أحد أكبر التغييرات التي تحدث الآن هو التنقل. قدمت PeopleSoft إمكانية التنقل من خلال واجهة المستخدم المرنة. يستخدم Fluid UI نظامًا مختلفًا تمامًا. هذا التطبيق يتطور. واجهة المستخدم المرنة - ما تفعله من منظور الإدارة هو أنها تتيح للمستخدمين النهائيين استخدام هواتفهم وزيادة الإنتاجية بشكل كبير. إذا كان لديك المئات أو الآلاف أو حتى أكثر من الموظفين ، إذا كنت تستطيع زيادة إنتاجيتهم بنسبة 1-2 في المائة ، فيمكنك أن يكون لها تأثير كبير على جدول الرواتب وكل شيء آخر. ما حدث هو أن هذا المتجر الخاص قد طرح واجهة مستخدم PeopleSoft Fluid UI. الآن ، نتحدث عن التعقيد ، هذا هو مكدس PeopleSoft. تطبيق واحد ، ما لا يقل عن ستة تكنولوجيا ، العديد من المستخدمين النهائيين. كيف تبدأ؟

مرة أخرى ، ستتمكن Precise من متابعة هذه المعاملات. ما نعرضه لك هنا هو رسم بياني لشريط مكدس يعرض العميل ، خادم الويب ، جافا ، قاعدة بيانات Tuxedo ، مكدس تطبيق PeopleSoft. خرائط خضراء ل J2EE ، وهو نوع من وسيلة خيالية لقول WebLogic. هذا هو التحول. يبدأ المستخدمون النهائيون في استخدام واجهة المستخدم المرنة (Fluid UI) ، ويمتد وقت الاستجابة من واحد إلى نصفين ، أو ثانيتين ، إلى حوالي تسع أو عشر ثوان. ما لا تظهره هذه الشاشة هو عدد الأشخاص الذين "لا يستجيبون". لقد تم تجميد الشاشة بالفعل في التطبيق. دعونا نلقي نظرة على بعض الرؤية التي تستطيع شركة Precise توفيرها لهذا العميل.

بادئ ذي بدء ، عندما أنظر إلى معاملات PeopleSoft ، يمكنهم أن يروا بشكل أساسي ، رأينا هذا النوع من الأشياء في جميع المجالات. تأثرت جميع المعاملات ، وكذلك جميع المواقع. بالمناسبة ، عندما تنظر إلى هذا ، يمكنك بالفعل رؤية المواقع في جميع أنحاء العالم. من آسيا والمحيط الهادئ ، إلى أوروبا وكذلك أمريكا الشمالية. لم تكن مشكلة الأداء موجودة في معاملة معينة ، أو موقع جغرافي معين ، فهي واسعة على مستوى النظام. إنها طريقة لقول أن التغيير أو الطريقة التي كان بها تأثير واجهة الموائع عالمية. يمكنك أن ترى هنا من وجهة نظر قابلية التوسع ، أن الناس يحاولون القيام بنفس نوع النشاط ، لكن وقت الاستجابة قد تدهور وتدهور بشكل أساسي. يمكنك أن ترى أن الأمور لا تحجيم. الأمور تسير بشكل سيء للغاية. هنا ، عندما أنظر إلى عدد المحاور والاتصالات المتزامنة ، ترى شيئًا مثيرًا للاهتمام من حيث عدد مرات الوصول والاتصالات. نحن هنا نرتب ما يصل إلى حوالي 5000 ونظرتم إليه ، وهذا يتجاوز 100 اتصال متزامن. يتم ذلك بعد. هذا من قبل. إذن ما مطلب حقيقي على النظام ، إذا كان هذا الشيء يمكن أن نطاق ، هو في حدود 300000. في الأيام الخوالي ، مع واجهة المستخدم الكلاسيكية ، تنظر إلى 30 اتصال متزامن.

الآن ما يقوله لك هذا هو أن واجهة مستخدم Fluid تستخدم ما لا يقل عن 10x أرقام الاتصالات المتزامنة. نبدأ في سحب ما يحدث تحت الأغطية مع PeopleSoft حتى تتمكن من البدء في رؤية التأثير على خوادم الويب ، حقيقة أن اتفاقيات مستوى الخدمة بدأت في الاختراق. لن أذهب إلى كل شيء ، ولكن ما يحدث في النهاية هو أنهم يعتمدون بشكل أساسي على المراسلة. هم أساسا ممارسة WebLogic ويسبب طابور داخل سهرة. في الواقع كانت هناك مشكلة تبعية متعددة المستويات ظهرت مع واجهة المستخدم المرنة ، لكن شركة Precise كانت قادرة على إظهار أنه بمجموعة كاملة من الأشياء المختلفة ، يمكننا التركيز على المشكلة. اتضح أن هناك أيضا مشكلة في قاعدة البيانات نفسها. يوجد بالفعل ملف سجل رسائل ، وبسبب جميع المستخدمين المتزامنين ، تم تأمين ملف السجل هذا. كان يحتوي على أشياء يتم ضبطها بشكل أساسي ، في كل طبقة داخل حزمة التطبيق. تحدث عن التعقيد ، إليك في الواقع طبقة Tuxedo التي تظهر لك قائمة الانتظار ويمكنك أن ترى الأداء مهينًا ضمن هذه الفئة أيضًا. أستطيع أن أرى العمليات ؛ أستطيع أن أرى المجالات والخوادم. في Tuxedo ، لكي يستخدم الناس ذلك ، عادة ما تفعله هو فتح قوائم انتظار إضافية ومجالات وخوادم ، كما هو الحال في السوبر ماركت لتخفيف الازدحام ، لتقليل وقت الانتظار. الخيار الأخير والأخير ، يعرض Precise الكثير من المعلومات.

كما ذكرت سابقًا ، كل معاملة مهمة تتفاعل مع نظام السجلات. الرؤية في قاعدة البيانات أمر بالغ الأهمية. يُظهر Precise ما يحدث داخل قاعدة البيانات ، داخل WebLogic ، داخل Java ، .NET ، داخل المستعرض ، ولكن المكان الذي تتفوق عليه Precise حقًا هو في مستوى قاعدة البيانات. هذا يحدث أن يكون ضعف منافسينا. اسمح لي أن أوضح لك إحدى الطرق التي يمكن أن تساعدك بها Precise على متابعة ذلك. لن أقضي وقتًا في مثلث تحسين قاعدة البيانات ، لكننا نبحث في الأساس عن تغييرات في النوعية منخفضة التكلفة وعالية المخاطر وعالية التكلفة وعالية التكلفة. أنا في الواقع سوف تغرد هذه الشريحة بعد ذلك إذا أراد الناس أن يحاولوا إلقاء نظرة عليها. إنه دليل كبير جدًا ، كما أعتقد ، من أجل ضبط المشكلات. فيما يلي عرض الخبراء الدقيق لـ Oracle. أعلى على تقرير النتائج ، 60 في المئة تأثير هذا هو بيان SQL معين. إذا قمت بفتح شاشة النشاط هذه ، فسيظهرها هناك. أستطيع أن أنظر إلى بيان الاختيار هذا ، هناك خطة تنفيذ واحدة. كل عملية إعدام تستغرق 48000 عملية إعدام. وهذا يضيف ما يصل إلى 48000 ساعة من عمليات الإعدام.

الأزرق الداكن ، مرة أخرى ، هو وحدة المعالجة المركزية. هذا الشيء مرتبط بوحدة المعالجة المركزية ، وليس حالة انتظار ، وليس سجل. وأؤكد أنه نظرًا لأن بعض منافسينا ينظرون فقط إلى حالات الانتظار وأحداث تسجيل الدخول ولكن بصفة عامة ، فإن وحدة المعالجة المركزية هي أكثر حالات التنفيذ ازدحامًا وتوفر أقصى عمليات إعادة الشراء. الوصول إلى وجهة نظر الخبراء هذه - وأنا أذهب بسرعة كبيرة - ما فعلته هو أنني نظرت إلى الطاولة ، و 100000 صف ، 37000 قطعة. نحن نقوم بجدول كامل ، ولكن لدينا ستة فهارس حول هذا الشيء. ماذا يجري هنا؟ حسنًا ، عندما أنظر إلى جملة "أين" ، ما تفعله هذه العبارة هو أنها تقوم فعليًا بتحويل عمود إلى أحرف كبيرة وتقول أين تساوي الأحرف الكبيرة ، ابحث عن متغير. ما يحدث هو في كل مرة يتم تنفيذ هذا الشيء ، يتعين على Oracle تحويل هذا العمود إلى أحرف كبيرة. بدلاً من القيام بذلك ما يقرب من خمسين ألف مرة ، يكون إنشاء هذا الفهرس كبيرًا بدرجة كبيرة في الفهرس القائم على الوظيفة وهو أكثر فاعلية ، وهو متاح ليس فقط في قسم Oracle Enterprise ، وكذلك القسم القياسي. عند القيام بذلك ، ما يمكنك القيام به بعد ذلك هو التحقق من خطة التنفيذ بإصدار مستخدم الفهرس الجديد إلى أحرف كبيرة ، وكان ذلك مجرد نوع من الأشياء الخاصة بي.

بعد ذلك ، من خلال القياس المسبق وبعد النظر ، يمكنك النظر في وقت التنفيذ لمدة ثانية واحدة ، حيث يتم تجميع ما يصل إلى 9 ساعات و 54 دقيقة ، مع نفس عبارة SQL بالضبط ، ولكن مع بناء هذا الفهرس في أحرف كبيرة لتنفيذ 58000 عملية تنفيذ ، فإن الاستجابة ينخفض ​​الوقت إلى مللي ثانية ، ويتجمع معًا ، ويصل إلى سبع ثوانٍ. أنا أساسا حفظ عشر ساعات من وحدة المعالجة المركزية على الخادم الخاص بي. هذا ضخم. لأنه إذا لم أكن بسبب تحديث الخادم ، فأنا قادر على العيش على هذا الخادم. أنا في الواقع إسقاط استخدام الخادم بنسبة 20 في المئة ويمكنك أن ترى في الواقع قبل وبعد. هذا هو نوع الرؤية التي يمكن أن تقدمها الدقة. هناك أيضًا بعض الأشياء الإضافية التي قد ننظر إليها ، لماذا لديك كل هذه الفهارس إذا لم يتم استخدامها؟ يمكنهم متابعة ذلك. هناك بنية ، وسأنهيها ، لأننا وصلنا إلى قمة الساعة. أنا مؤمن حقيقي في هذا الحل ونريدك أن تكون مؤمنًا حقيقيًا. في IDERA ، نعتقد أن التجربة تجعل العميل ، لذلك إذا كنت مهتمًا ، فيمكننا إجراء تقييمات في موقعك.

مع ذلك ، سأمرر منارة الظهر.

إريك كافاناغ: نعم ، لقد كانت هذه تفاصيل هائلة أظهرتها هناك. انها حقا رائعة جدا. أعتقد أنني قد ذكرت لك في الماضي ذلك - وأنا أعلم في بعض البث الشبكي الآخر الذي قمنا به مع IDERA ، لقد ذكرت ذلك - لقد كنت أتتبع Precise منذ قبل أن تحصل عليها IDERA ، على طول الطريق إلى عام 2008 ، على ما أعتقد ، أو عام 2009. لقد فتنت به في ذلك الوقت. أشعر بالفضول لمعرفة مقدار العمل المتبقي للبقاء على رأس الإصدارات الجديدة من التطبيقات. لقد ذكرت أن SAP HANA ، والتي أعتقد أنها رائعة حقًا أنه يمكنك فعلاً البحث في بنية HANA والقيام ببعض استكشاف الأخطاء وإصلاحها هناك. كم من الناس لديك؟ ما مقدار الجهد المبذول من جانبك وكم يمكن القيام به بشكل حيوي إلى حد ما ، وهذا يعني عند نشر الأداة ، هل تبدأ في الزحف حولك ورؤية أشياء مختلفة؟ ما مقدار ذلك الذي يمكن أن يتم التحقق منه ديناميكيًا أو نوعًا ما ، من خلال الأداة ، بحيث يمكنك مساعدة الأشخاص على استكشاف الأخطاء وإصلاحها في البيئات المعقدة؟

بيل إيليس: لقد طرحت الكثير من الأسئلة هناك.

إريك كافانا: أعرف ، آسف.

بيل إليس: لقد قدمت الكثير من التفاصيل لأن هذه التطبيقات ، بالنظر إلى الكود ، الشيطان هو في التفاصيل. يجب أن يكون لديك هذا المستوى من التفاصيل لتتمكن حقًا من الحصول على شيء عملي. بدون مقاييس قابلة للتنفيذ ، تعرف تمامًا الأعراض. أنت لست في الواقع حل المشاكل. IDERA يدور حول حل المشاكل. البقاء على اطلاع على الإصدارات الجديدة والأشياء يشكل تحديا كبيرا. مسألة ما يلزم للقيام بذلك ، وهذا هو حقا لإدارة المنتجات. ليس لدي الكثير من الرؤية في الفريق الذي يبقينا على اطلاع دائم بالأمور. من حيث HANA ، هذه في الواقع إضافة جديدة لخط إنتاج IDERA ؛ انها مثيرة للغاية. أحد الأشياء مع HANA هي - اسمحوا لي أن أتحدث عن المهمة لفترة ثانية. في هذه المهمة ، ستفعل متاجر SAP أنها ستقوم بتكرار قاعدة البيانات لأغراض إعداد التقارير. ثم عليك أن تجعل الناس يتصالحون مع ما هو في الواقع الحالي. سيكون لديك قواعد بيانات مختلفة وستكون غير متزامنة حسب مستويات مختلفة. هناك الكثير من الوقت والجهد ، بالإضافة إلى الأجهزة والبرامج والناس للحفاظ على كل ذلك.

فكرة أن يكون لدى HANA قاعدة بيانات متوازية للغاية في الذاكرة لتجنب الحاجة إلى قواعد بيانات مكررة. لدينا قاعدة بيانات واحدة ، ومصدر واحد للحقيقة ، دائمًا ما يكون محدثًا ، وبهذه الطريقة تتجنب ما يلزم للقيام بكل هذا المصالحة. ترتفع أهمية أداء قاعدة بيانات HANA - سأقول 10x أو على الأقل أكثر قيمة من مجموع جميع قواعد البيانات الأخرى ، الأجهزة ، الموارد التي يمكن شراؤها. أن تكون قادرًا على إدارة HANA ، الآن هذا المكون هو في الواقع في مرحلة اختبار بيتا في الوقت الحالي ، إنه شيء سينتقل إلى GA قريبًا. هذا مثير جدًا بالنسبة لـ IDERA ولدينا الدعم الأساسي لنظام SAP. لست متأكدًا من الأجزاء الأخرى من سؤالك التي اختصرتها ولكن -

إريك كافانا: لا ، كل هذه الأشياء جيدة هناك. رميت باقة كاملة عليك في وقت واحد ، لذلك آسف لذلك. أنا فقط مفتون ، حقًا ، أعني أن هذا ليس تطبيقًا بسيطًا للغاية ، أليس كذلك؟ أنت تعمق في هذه الأدوات وتفهم كيف تتفاعل مع بعضها البعض ومن وجهة نظرك ، عليك أن تجمع القصة معًا في رأسك. عليك أن تجمع بين أجزاء من المعلومات لفهم ما يحدث بالفعل وما يسبب لك المشكلة ، حتى تتمكن من الذهاب إلى هناك وحل هذه المشاكل.

أحد الحضور يسأل ، ما مدى صعوبة تطبيق "دقيق"؟ سأل شخص آخر ، من هم الأشخاص - من الواضح أنهم DBAs - ولكن من هم بعض الأدوار الأخرى في المنظمة الذين يستخدمون هذه الأداة؟

بيل إيليس: الدقة أكثر تعقيدًا قليلاً في النشر. يجب أن يكون لديك بعض المعرفة ببيئة التطبيق ، من حيث ، كما تعلمون ، يعمل هذا التطبيق على قاعدة البيانات هذه ، أو يحتاج - أو خوادم الويب من المستوى المتوسط ​​، إلخ. أعتقد أنه نظرًا لتعقيد بعض هذه التطبيقات ، انها فعلا سهلة نسبيا. إذا كان بإمكاني تشغيل خادم الويب حتى قاعدة البيانات الخاصة بك ، فيمكنني القيام بذلك من البداية إلى النهاية. لاحظت أنني لم أقل شيئًا حول صياغة عميل للمستخدم النهائي وهذا لأن ما نقوم به هو أننا نقوم بالفعل بتضمينها ديناميكيًا ، لذلك لا يتعين عليك تغيير الكود أو أي شيء آخر. ينتقل JavaScript إلى إطار صفحة التطبيق. بغض النظر عن مكان وجود المستخدم في العالم ، عندما يصل إلى عنوان URL من التطبيق الخاص بك ويقومون بإسقاط تلك الصفحة ، يأتي الجهاز مزودًا بدقة. يتيح لنا ذلك اختيار معرف المستخدم وعنوان IP الخاص به وأيضًا وقت عرض البايت الأول لكل مرة من وقت تنفيذ البرنامج النصي لمكونات الصفحة داخل متصفح المستخدم النهائي.

فيما يتعلق بالمعاملات ، لا يتعين عليك تحديد المعاملات لأنها مرتبطة بإحكام. يصبح عنوان URL هذا بمثابة نقطة دخول إلى JVM ثم يتم استدعاء هذه الرسالة ، مما يؤدي إلى اكتشاف JVC من قاعدة البيانات. نحن قادرون بشكل أساسي على التقاط نقاط الاتصال الطبيعية هذه ومن ثم تقديمها لك في شاشة المعاملة التي أوضحت لك فيها حيث قمنا أيضًا بحساب مقدار الوقت ، أو النسبة المئوية للوقت الذي تم إنفاقه في كل خطوة على حدة. كل ذلك يتم تلقائيا. بشكل عام ، نحن نخصص 90 دقيقة للقيام - لتثبيت الأساس الدقيق ثم نبدأ في تنفيذ التطبيق. بناءً على معرفة التطبيق ، قد يستغرق الأمر منا بعض الجلسات الإضافية للحصول على التطبيق بالكامل. يستخدم العديد من الأشخاص فقط مكون قاعدة البيانات من الدقة. هذا جيد. يمكنك تقسيم هذا بشكل أساسي ، وتقسيمه إلى المكونات التي تشعر بأن موقعك يحتاج إليها. نحن نعتقد بالتأكيد أن سياق امتلاك مكدس التطبيق بالكامل مصمم بحيث يمكنك أن ترى أن التبعية من الطبقة إلى المستوى تضخيم قيمة مراقبة المستوى الفردي فعليًا. إذا أراد أي شخص استكشاف أداة مكدس التطبيقات الخاصة به بشكل أكبر ، فالرجاء الانتقال إلى موقعنا على الويب - أعتقد أن هذه هي أسهل طريقة لطلب معلومات إضافية ، وسنناقشها قليلاً.

إريك كافانا: دعني أطرح عليك سؤالًا أو سؤالين سريعين. أظن أنك تقوم بتجميع وبناء مستودع بمرور الوقت ، لكل من العملاء الأفراد وككيان عام للشركة ، للتفاعلات بين التطبيقات المختلفة وقواعد البيانات المختلفة. بمعنى آخر ، فإن تصميم السيناريو ، على ما أعتقد ، هو ما أشير إليه. هل هذا هو الحال؟ هل تحتفظ فعلاً بنوع من مستودع السيناريوهات الشائعة بحيث يمكنك تقديم اقتراحات للمستخدمين النهائيين عندما تدخل بعض الأشياء في الاعتبار؟ مثل هذا الإصدار من E-Business Suite ، هذا الإصدار من قاعدة البيانات هذه ، إلخ - هل تفعل الكثير من هذا؟

بيل إليس: حسنًا ، هذا النوع من المعلومات مدمج في تقرير النتائج. يوضح تقرير النتائج ما هي اختناقات الأداء ، ويستند إلى وقت التنفيذ. جزء من تقرير النتائج هذا هو معرفة المزيد وماذا تفعل بعد ذلك. يتم دمج المعلومات أو تجربة العملاء وما إلى ذلك بشكل أساسي في مكتبة التوصيات تلك.

إريك كافانا: حسنًا ، هذا يبدو جيدًا. حسنا الناس ، عرض رائع اليوم. بيل ، لقد أحببت كم التفاصيل التي لديك هناك. لقد اعتقدت أن هذه المعلومات رائعة حقًا وشجاعة ومحببة ، توضح كيف يتم كل هذه الأشياء. في مرحلة معينة ، يشبه السحر الأسود ، لكنه في الحقيقة ليس كذلك. إنها تقنية محددة للغاية وضعتموها معًا لفهم بيئات شديدة التعقيد وإرضاء الناس لأن لا أحد يحب تشغيل التطبيقات ببطء.

حسنا الناس ، سنقوم بأرشفة هذا البث الشبكي. يمكنك الانتقال عبر الإنترنت إلى Techopedia أو insideanalysis.com و wow ، شكرًا على وقتك ، وسنتواصل معك في المرة القادمة. رعاية وداعا وداعا.