البحث في الموقع

ينتشر استخدام MySQL وMariaDB كثيرا لإدارة قواعد البيانات العلاقيّة، وتستخدم الاثنتان استعلامات SQL لإدخال البيانات في القاعدة واستخراجها منها. على الرغم من أنّ استعلامات SQL في مجملها أوامر سهلة يمكن تعلّمها بيُسر، إلا أن الاستعلامات ودوالّ قواعد البيانات لا تعمل بنفس الكفاءة. تصبح كفاءة استعلامات SQL أكثر أهميّة مع ازدياد كميّة البيانات التي تخزّنها؛ وازدياد شعبيّة موقعك، في حال كنت تستخدم قاعدة البيانات في موقع ويب. يناقش هذا الدليل إجراءات بسيطة تمكّن من تسريع تنفيذ الاستعلامات في MySQL وMariaDB. سنفترض أنّ لديك قاعدة بيانات MySQL أو MariaDB مثبّتة على خادومك. مبادئ عامّة في تهيئة الجداول Tables تبدأ فعاليّة قاعدة البيانات بتصميم بنية جداول تحترم معايير مجرَّبة لتحسين الأداء. يعني هذا أنه يجب عليك التفكير في أفضل طريقة لتنظيم بياناتك قبل البدء في استخدام البرنامج. في ما يلي بضعة أسئلة تساعدك في إيجاد طريقة مثلى لتهيئة مخطّط الجداول في قاعدة البيانات. ما هو الاستخدام الأساسي للجدول؟ تُملي معرفةُ الكيفية التي ستُستغَل بها البيانات الموجودة في الجدول مستقبلا أفضلَ مقاربة لتخطيط الجداول في قاعدة البيانات. إذا كانت بعض البيانات ستُحدَّث باستمرار فإن الأفضل غالبا هو وضعها في جدول خاصّ بها. يوجد في برامج إدارة قواعد البيانات تخبئة Cache داخليّة تُحدَّث ويُعاد بناءها مع كل تغيير على الجدول، فإن كانت البيانات المُحدَّثة في جدول مستقل فإن البرنامج لن يُضطر لتحديث بقيّة البيانات في كلّ مرة وهو ما يعني جهدا أقل ووصولا أسرع. تكون عمليّات التحديث عموما أسرع بكثير عند تنفيذها على جداول صغيرة، بينما يُفضَّّل تنفيذ تحليل البيانات المعقّدة على الجداول الكبيرة، بدلا من تجميع الكثير من الجداول الصغيرة، عبر تعليمات join مثلا. ما هي أنواع البيانات المطلوبة؟ يُمكن أحيانا اقتصاد الكثير من الوقت على المدى الطويل إن استطعت تطبيق قيود سلفا على أحجام البيانات المطلوبة. إن كانت لديك، على سبيل المثال، قيم محدودة لأحد الحقول النصيّة فيمكنك استخدام نوع البيانات enum لهذا الحقل بدلا من varchar. البيانات من النوع البيانات enum ذات حجم صغير وبالتالي يُنفَّذ الاستعلام عنها بسرعة كبيرة. يصلُح النوع enum - مثلا - لحقل يُخزّن أدوار المستخدِمين في منتدى: مدير Admin، مشرف Moderator، مستخدم فعّال Poweruser أو مستخدم عادي User. ماهي الحقول التي ستستعلِم عنها؟ تساهم المعرفة القبْليّة للحقول التي ستبحث عن قيمها باستمرار في التحسين المعتبر لسرعة تنفيذ الاستعلامات، وذلك بفهرسة Indexing حقول البحث. يُضاف الفهرس على حقل على النحو التالي عند إنشاء الجدول: CREATE TABLE example_table ( id INTEGER NOT NULL AUTO_INCREMENT, name VARCHAR(50), address VARCHAR(150), username VARCHAR(16), PRIMARY KEY (id), INDEX (username) ); لاحظ التعليمة INDEX أعلاه. يفيد الفهرس على الحقل username كثيرا إذا كنا نعرف أن زوّار موقعنا سيبحثون عن المستخدمين بأسماء حساباتهم. يُنشئ الاستعلام أعلاه جدول example_table يمكن عرض خاصيّاته كالتالي: explain example_table; +----------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(50) | YES | | NULL | | | address | varchar(150) | YES | | NULL | | | username | varchar(16) | YES | MUL | NULL | | +----------+--------------+------+-----+---------+----------------+ 4 rows in set (0.00 sec) يوجد لدينا - كما يظهر - فهرسان. الأول المفتاح الرئيس Primary key ويوجد على حقل المعرِّف id، أما الثاني فهو الذي عرّفناه ويوجد على الحقل username. يعني هذا أن البحث عن المستخدمين بأسماء حساباتهم سيكون أسرع كثيرا من البحث عنهم بأحد الحقول المتبقيّة. من المهمّ جدا، من وجهة نظر التصميم البرمجي، التفكير في الحقول التي يجب أن تُفهرَس وفعل ذلك مع إنشاء الجدول؛ إلا أن بالإمكان ايضا إضافة فهارس إلى جداول موجودة سلفا على النحو التالي: CREATE INDEX index_name ON table_name(column_name); توجد طريقة أخرى للحصول على نفس النتيجة: ALTER TABLE table_name ADD INDEX ( column_name ); استخدام الدالة explain لإيجاد حقول لفهرستها إذا كان برنامجك يطلب تنفيذ استعلامات منتظمة يمكن التنبؤ بها فيجب عليك تحليل هذه الاستعلامات للتأكد من أن الاستعلامات تستخدم حقولا بها فهارس كلما كان ذلك ممكنا. تساعد الدالة explain في هذه المهمة. سنستورد قاعدة البيانات التجريبية الموجودة في المرفق employees_db.zip لتطبيق بعض الأمثلة عليها. نزّل الملف المضغوط ثم نفّذ الأمرين التاليين لفكّ ضغطه والانتقال إلى المجلّد employees_db الناتج عن فك الضغط: tar xjvf employees_db-full-1.0.6.tar.bz2 cd employees_db ثم ننفّذ اﻷمر التالي لاستيراد القاعدة إلى MySQL (ينبغي أن يكون عميل MySQL - حزمة mysql-client - مثبتا لديك): mysql -u root -p -t < employees.sql ستُطلب منك كلمة سرّ خادوم MySQL. نسجّل الدخول إلى خادوم MySQL: mysql -u root -p ننفّذ الأمر التالي داخل المحثّ Prompt الخاص بـMySQL لتحديد قاعدة البيانات التي استوردناها للتو: use employees; نحتاج أولا لإخبار MySQL ألا يستخدم تخبئته الداخليّة ليمكننا الحكم بدقّة على الوقت اللازم لتنفيذ هذه المهامّ. SET GLOBAL query_cache_size = 0; SHOW VARIABLES LIKE "query_cache_size"; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | query_cache_size | 0 | +------------------+-------+ 1 row in set (0.00 sec) يمكننا الآن تشغيل استعلام بسيط على مجموعة كبيرة من البيانات: SELECT COUNT(*) FROM salaries WHERE salary BETWEEN 60000 AND 70000; +----------+ | count(*) | +----------+ | 588322 | +----------+ 1 row in set (0.80 sec) يطلُب الاستعلام أعلاه عدَّ الموظفين ذوي الدخل المحصور بين 60000 و70000. تُظهر النتيجة وجود 588322 موظف في هذا المجال. نستفيد الآن من الدالة explain لرؤية كيف نُفِّذ الاستعلام السابق وذلك بإضافة الكلمة EXPLAIN أمام الاستعلام الذي طبّقناه للتو: EXPLAIN SELECT COUNT(*) FROM salaries WHERE salary BETWEEN 60000 AND 70000; +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | 1 | SIMPLE | salaries | ALL | NULL | NULL | NULL | NULL | 2844738 | Using where | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ 1 row in set (0.00 sec) يظهر في نتيجة استخدام التعليمة EXPLAIN أن قيمة الحقل key هي NULL، ما يعني أنه لم يُستخدَم أي فهرس في الاستعلام السابق. فلنضف فهرسا على الحقل salary، ثم لنعد نفس الاستعلام ولننظر إن كان ذلك يُسرّع من تنفيذه: ALTER TABLE salaries ADD INDEX ( salary ); SELECT COUNT(*) FROM salaries WHERE salary BETWEEN 60000 AND 70000; النتيجة: +----------+ | count(*) | +----------+ | 588322 | +----------+ 1 row in set (0.14 sec) يمكن ملاحظة أن سرعة تنفيذ الاستعلام تحسّنت كثيرا من 0.80 ثانية قبل إضافة الفهرس إلى 0.14بعد إضافته. قاعدة مهمّة أخرى عند استخدام الفهارس هي أنه ينبغي الانتباه إلى ربط الجداول (عبر التعليمة join مثلا)؛ إذ يجب أن تُنشَأ فهارس للحقول المستخدمة في الربط، كما يجب أن تشترك هذه الحقول في نوع البيانات. على سبيل المثال، إن كان لديك جدول يحوي وصفات طعام (وليكن اسمه cheeses) وآخر لمكوّنات كلّ وصفة (وليكن اسمُه ingredients) فإن ربط الجدوليْن يمكن أن يكون حسب حقل من النوع INT (عدد طبيعي) يحوي معرّف المكوّن (وليكن اسمُه ingredient_id) موجود في الجدوليْن. يمكننا بعدها إنشاء فهرس على كل من الحقليْن ingredient_id وبالتالي تسريع استعلامات join كثيرا. تحسين الاستعلامات لتسريع تنفيذها يتعلّق الجزء الثاني من معادلة تسريع الاستعلامات بتحسين الاستعلامات نفسها. تتطلّب بعض التعليمات قدرات حسابية أعلى من تعليمات أخرى، كما يمكن في أحيان كثيرة الحصول على نفس النتيجة بأكثر من طريقة، مع اختلاف في الكلفة الحسابية لكلّ طريقة. يمكن ألا تحتاج إلا إلى نتائج قليلة العدد، حسب الغرض الذي ستستخدم فيه نتيجة الاستعلام. إذا أردت على سبيل المثال معرفة ما إذا كان هناك موظَّف بدخل أقل من 40000 في قاعدة البيانات التي نزّلناها سابقا، فالاستعلام التالي يجيبك: SELECT * FROM SALARIES WHERE salary < 40000 LIMIT 1; النتيجة: +--------+--------+------------+------------+ | emp_no | salary | from_date | to_date | +--------+--------+------------+------------+ | 10022 | 39935 | 2000-09-02 | 2001-09-02 | +--------+--------+------------+------------+ 1 row in set (0.00 sec) يُنفَّّذ الاستعلام سريعا لأنه يكتفي بأول تسجيلة تحقّق الشرط المطلوب. إن كان الاستعلام - مثلا - يستخدم عامل المقارنة OR وكان عنصرا المقارنة يختبران حقولا مختلفة فإن الاستعلام قد يأخذ وقتا أكثر من اللازم. على سبيل المثال، إن أردت البحث عن جميع الموظفين الذين تبدأ أسماءهم الشخصية والعائلية بـBre فستبحث عن قيم حقليْن مختلفيْن (first_name وlast_name). يكون الاستعلام باستخدام العامل OR على النحو التالي: SELECT * FROM employees WHERE last_name like 'Bre%' OR first_name like 'Bre%'; إلا أن الاستعلام قد يكون (حسب طبيعة البيانات في الجدول) أسرع إن بحثتَ عن الأسماء الشخصيّة أولا في استعلام خاصّ ثم عن الأسماء العائلية ثانيا ودمجت الاثنين: SELECT * FROM employees WHERE first_name like 'Bre%' UNION SELECT * FROM employees WHERE last_name like 'Bre%'; خاتمة عرضنا في هذا المقال لبضعة حيّل تساعدك في البدء في تحسين الاستعلامات الموجهة لقاعدة بيانات MySQL (أو MariaDB). توجد الكثير من الحيّل الأخرى التي ستساعدك في الرفع من أداء قاعدة البيانات وبالتالي أداء تطبيقك أو موقعك. يوفّر نظاما إدارة قواعد البيانات MySQL وMariaDB توثيقا جيّدا حول كيفية تحسين استعلاماتك وإعداد قاعدة البيانات لأداء أعلى. يجب أن تتذكّر أن تحسين أداء قاعدة البيانات مرتبط ارتباطا وثيقا بطبيعة استخدامها والبيانات المخزّنة فيها، لذا كلّ ما كانت سيناريوهات الاستخدام أوضح وأكثر انتظاما كلّ ما كان تحسين الاستعلامات أسهل. ترجمة - بتصرف - للمقال How To Optimize Queries and Tables in MySQL and MariaDB on a VPS لصاحبه Justin Ellingwood.

يُدرك القادة الأكثر حنكة أن فرقهم هي التي تصنع نجاحاتهم، وكونك قائد فريق يعني أن تقضي الكثير من وقتك للتأكّد من أنّ فريقك يعمل بتوافق وانسجام. فتعمَد إلى وضع أهداف طموحة، بناء ثقافة شركة تفاعلية وممتعة، السعي لتجنّب النزاعات، والتأكّد من أنّ أفراد الفريق يتشاركون المسؤوليات ويستخدمون أقصى طاقاتهم. لكن، ولسبب ما، تفشل في جعل فريقك عالي الأداء بالرغم من كل الوقت والجهد الذي بذلته لتحقيق ذلك. فتجد أنّ هناك فرق عمل تنتج أفضل من غيرها. والسبب في ذلك هو أنّ أفراد تلك الفرق مقرّبون من بعضهم، ويثق في بعضهم البعض بدرجة أفضل مقارنة بفريقك. صفات الفريق عالي الأداء نحن جميعًا نرغب في العمل في فِرق عالية الأداء، لكن السؤال هو ما هي صفات هذه الفرق؟ لحسن الحظ، تجيبنا Google عن هذا السؤال من خلال دراسة أجرتها حول ما يشكّل الفريق الجيّد. بدأ فريق الموارد البشرية في Google مشروعًا أسموه أرسطو Aristotle، حيث درسوا الملايين من الفِرق في Google لمعرفة ما يجعلهم يعملون معًا بفاعلية. كانت أولى نظرياتهم أنّه يمكنهم تشكيل فريق مثالي إذا استطاعوا العثور على خليط من أفضل المهارات، فالاعتقاد السائد هو أنّ أفضل مسوّق، وأفضل مطوّر، وأفضل مصمم جرافيك يمكن أن يشكلوا أفضل فريق، أليس كذلك؟ في الحقيقة هذا غير صحيح، فالشخص الذي تضمّه إلى الفريق ليس له سوى تأثير صغير على مدى نجاح الفريق ككل، إذ أنّ الأمر كله يعتمد على كيفية تفاعل أفراد الفريق مع بعضهم، والأهم من ذلك، كيف ينظر كل فرد منهم إلى مساهماته في الفريق. توصلت Google إلى خمسة أمور أساسية لبناء فريق ناجح. الجزء الأكثر إثارة للاهتمام في دراستهم هو البند الأول، الأمن النفسي، وهو، إلى حدّ كبير، الأكثر أهمية في القائمة، فبدونه لن يكون للبنود الأخرى تلك الأهمية الكبيرة. فكّر في هذا السؤال وأجب عنه بصراحة: هل تراجعت من قبل عن مشاركة شيء ما يتعلّق بالعمل (كشيء كنت تعمل عليه، فكرة خطرت على بالك، شكوى…إلخ) لأنّك كنت خائفًا من ردّة فعل الناس؟ إذا أجبتَ بــ “لا” فهذا يعني إمّا أنّك واثق جدًا من نفسك، أو أنّك تخفي الحقيقة. فمن الطبيعي أن تشعر بالتوتر والقلق من أنّك ستبدو غير مؤهّل أو غير مهتم. إذ تتولد لدينا الكثير من المخاوف حول مقدار المعرفة التي يجب أن نكتسبها في العمل. وفي معظم المواقف، من الأسهل أن تلتزم الصمت، آملًا ألّا يلاحظك أحدٌ، بدلًا من الاعتراف بأنّك لا تعرف. لذلك نسعى جميعنا إلى تجنّب المواقف التي من شأنها التأثير سلبا على صورتنا في أذهان المديرين والزملاء. وجدت Google في دراستها أنّ أداء الفريق تحسّن في كل جوانب العمل تقريبًا بازدياد شعورهم بالأمان تجاه بعضهم، حيث أصبحوا: أكثر قابلية للاعتراف بأخطائهم، شركاء أفضل لزملائهم، أقل احتمالًا لترك الشركة، أكثر احتمالًا للانفتاح وتقبّل الأفكار المتنوّعة. إذًا، يصبح السؤال الآن: كيف يمكننا فعليًا أن نبني فريقًا عالي الأداء؟ كيفية بناء فريق عالي الأداء تتشكل الفرق عالية الأداء من أفراد يحترم حقًا بعضهم البعض ويساعد بعضهم البعض، يعملون معًا ويتعاونون بدون نزاع أو خصومات. ويرجع ذلك كله في نهاية المطاف إلى الثقة، الأمان، والاحترام. فيما يلي بعض الأمور التي يمكنك كقائد القيام بها لبناء فريق عالي الأداء. أولًا: ابنِ الثقة في فريقك تُكتسب الثقة وتُبنى بمرور الزمن، ولن تفوز بثقة الناس بك ما لم تثق بهم في المقام الأول. يمكنك بناء الثقة مع فريقك بثلاث خطوات: ابن علاقة مع مرؤوسيك وأظهر اهتمامًا حقيقيًا بهم، وحاول أن تتعرّف عليهم على مستوى شخصي من خلال تفاعلاتك الشخصية وغير الرسمية معهم. كن على دراية بما تتحدّث عنه، فنحن لا نثق بأشخاص لا يعرفون عمّا يتحدثون. التزم بوعودك، فمن الصعب الوثوق بالشخص الذي لا يفي بوعوده ويتراجع عن كلامه، أو الذي يفعل ما لا يقول. ثانيًا: عزّز الأمن النفسي في فريقك يحتاج الأفراد ، حسب دراسة Google، إلى الشعور بالأمان في الفريق؛ ومن واجبك كقائد أن تزيل أيّة مخاوف وتتأكد من عدم تعرض أي فرد من أفراد الفريق إلى السخرية أو الملامة على الأخطاء، أو الوقوع في مشكلة عند فشل تجربة أو محاولة ما. إذ يجب التشجيع على الفشل في العمل، وينبغي لك بوصفك قائد فريق أن تكون ذا صدر رحب ومنفتحًا لتقبّل الأخطاء. حاولت الفِرق في دراسة Google تحسين الأمن النفسي من خلال بدء اجتماعات أسبوعية مع كل فرد من أفراد الفريق لتقاسم إحدى مخاطر الأسبوع السابق. وقد استطاعت هذه الفرق التي ساهمت في تقاسم المخاطر أن تحسّن تقييم الأمن النفسي لها بنسبة 6%. ثالثًا: ضع أهدافًا طموحة يتحفّز أفراد الفريق عالي الأداء بإمكانيات الوصول إلى هدفٍ استثنائي، لذا اعمل مع فريقك على وضع هدفٍ طموح وشجّعوا بعضكم لتحقيق تلك الأرقام التي خططتم لها. يجب أن يفهم كل فرد في الفريق دوره الذي يلعبه في تحقيق ذلك الهدف، كما يجب عدم معاقبة أي شخص إذا ما لم يتحقق الهدف لسبب من الأسباب. تحفيز أفراد الفريق أمر حاسم لتحسين الأداء، لكن بشرط ألّا ينتج عن ذلك ترويع لهم أو تعريضهم لضغوطات غير ضرورية، لذا عليك هنا أن تحقق التوازن بين الأمرين. رابعًا: حسّن مهارات التواصل التواصل الشفاف والصريح من الأمور الأساسية لبناء الثقة، لذا يجب أن يتحلّى كل فرد من أفراد الفريق بالقدرة على التواصل مع الآخرين بطريقة مهذّبة وبناءة. هناك الكثير من العوامل الصغيرة التي يمكن بسهولة أن تضرّ بعملية التواصل، لذا يجب أن تبذل جهدك لتدريب كل أفراد الفريق على عادات التواصل السليم، الكلمات المحظورة…إلخ. والأهم في كلّ ذلك أن يكون التواصل بتهذيب واحترام. خامسًا: ساعد مرؤوسيك على بناء الثقة من الأمور المهمة التي يجب أن تضعها في اعتبارك هو الدور الذي تلعبه المسؤولية الشخصية في بناء الفريق الجيّد. وبقدر كونها مسؤولية القائد أن يساعد أفراد الفريق على الارتياح في الفريق، يجب أن يتمتع كل فرد بالمسؤولية الشخصية للتغلب على مخاوفه الخاصّة. ساعد مرؤوسيك على تقبّل الفشل وكونهم معرضين لارتكاب الأخطاء أحيانا. اعتبر التغذية الراجعة أمرًا إيجابيًا، حوّل الأفكار السلبية إلى أفكار إيجابية، تفهّم أن الجميع يرتكب الأخطاء. سادسًا: استمع إلى مرؤوسيك يجب أن تُشعِر مرؤوسيك بأنّ كلماتهم مسموعة، وأنّ أفكارهم واقتراحاتهم تؤخذ في الاعتبار. فمن المستحيل أن تبني فريقًا عالي الأداء إن كانت أصواتهم مهمّشة وأدوارهم غير متكافئة. نحن نسعى في Officevibe إلى منح الجميع ثقة التعبير عن آرائهم وأفكارهم والتأكّد من جعلهم يشعرون بأنّ كلماتهم مسموعة. هل تعمل في فريق عالي الأداء؟ شاركنا في صندوق التعليقات أدناه طريقتك في تحفيز أفراد الفريق وكيف بناء الثقة معهم وبينهم. ترجمة- بتصرّف - للمقال The Simple Secret To A High-Performing Team حقوق الصورة البارزة لـ Freepik

مقدمة قبل أن ندخل في صلب الموضوع، دعني أطلعك على بعض مشاكل تصميم البرمجيات التي قد تواجهك. قبل بضعة أيام اشتكى أحد العملاء من بطء كبير جدًا في تحميل بعض صفحات موقعه. لذلك قرّرت أن أتفحّص تلك الصفحة وقد صدمني ما وجدته. فقد أظهر قسم الاستعلامات(query section) بأنّه تمّ تنفيذ أكثر من 16500 استعلام على تلك الصفحة لوحدها! وجدت الشيفرة البرمجية المسبّبة لتلك المشكلة. لقد كانت ثلاث حلقات من نوع foreach تستعلم عن صفةattribute معينة وعن الصّفات المتعلقة بها. كانت هذه الحلقات تعمل بشكل جيّد حتى أصبح هناك ما يقارب من 5500 عُنصر في قاعدة البيانات. إليك ما كان يحصل: $main_object = MainObject::all(); foreach($main_object as $object) { echo $object->some_property; foreach($object->related_object as $related) { echo $related->some_property; echo $related->another_property; } foreach($object->another_related as $another) { echo $another->some_property; echo $another->another_property; } } إذا كانت $main_object = MainObject::all(); تقوم بإرجاع 5500 نتيجة، فإنّ أوّل حلقة foreach سوف تُنفَّذ 5500 مرة وكذلك الحال بالنّسبة للحلقتين الثانية والثالثة. عند استعمال ما يُسمى بمخطّط الكائن العلائقيّة ORM ، يقوم أغلب المطورين بكتابة استعلامات قواعد بيانات غير فعّالة، ويُصعّب استخدام الـORM مُهمّة اكتشاف هذه الأخطاء. تُسمّى هذه المشكلة بمشكلة N+1 وأعتقد بأنّ المُطوّر السّابق لم ينتبه لذلك. ولنتفادى هذه المشكلة سنقوم باستعمال التحميل النّشط(eager loading). ما هو التحميل النّشط(eager loading)؟ يمكنك القول بأنّ التّحميل النّشط هو طريقة لفعل كلّ شيء عند الطّلب. وهو أيضًا عكس التحميل الخامل(lazy loading) بحيث يتمّ تنفيذ المهام عند الحاجة إليها. يساعد التحميل النّشط على تفادي الوقوع في مشاكل الأداء. حتى تتضح الصورة بشكل أفضل تخيّل معي الحالة التّالية: يوجد لدينا نموذج علاقة كائنيّة مُعزّزة enhanced entity-relationship model يحتوي على ثلاث وحدات/كائنات مترابطة. يمكننا قراءة هذا النموذج كالتالي: كل عضو(member) يمكنه أن يملك أكثر من متجر(store) ولكن المتجر الواحد ينتمي إلى عضو واحد فقط. كل متجر يمكن أن يحتوي على أكثر من مُنتَج(product) ولكن المنتَج الواحد ينتمي إلى متجر واحد فقط. الخطوة التّالية هي إنشاء نماذج eloquent لهذه الوحدات/الكائنات. عضو(member): <?php namespace App; use Illuminate\Database\Eloquent\Model; class Member extends Model { /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['username', 'email', 'first_name', 'last_name']; public function stores() { return $this->hasMany('App\\Store'); } } متجر(store): <?php namespace App; use Illuminate\Database\Eloquent\Model; class Store extends Model { /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['name', 'slug', 'site', 'member_id']; public function member() { return $this->belongsTo('App\\Member'); } public function products() { return $this->hasMany('App\\Product'); } } مُنتَج(product): <?php namespace App; use Illuminate\Database\Eloquent\Model; class Product extends Model { /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['name', 'short_desc', 'long_desc', 'price', 'store_id', 'member_id']; public function store() { return $this->belongsTo('App\\Store'); } } تخيّل بأنّك تقوم ببناء تطبيق ما وأنّ هذا التطبيق يسمح للمستخدمين بإنشاء متجر خاص بهم. بكل تأكيد وكما هو الحال في جميع المتاجر، فسيكون لدى المستخدمين القدرة على إنشاء أكثر من مُنتج. وما نريده أيضًا هو إنشاء صفحة لعرض جميع المتاجر وأفضل المنتجات الموجودة في كلّ متجر. شيء يشبه التالي: قد ينتهي بك المطاف بشيء كهذا في المتحكم(controller) الخاص بك: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->all(); return \View::make('stores.index')->with('stores', $stores); } } في الـView تريد أن تظهر تلك البيانات: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span> <br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/> ======================== <br/> @endforeach وتكون النتيجة كالتالي: في هذا المثال، قُمت بإعطاء قاعدة البيانات 5 أعضاء و3 متاجر و4 منتجات. الاستعلام الأول هو لجلب جميع المتاجر من قاعدة البيانات وهذا هو الجزء “+1” من المشكلة N+1. وفي هذا المثال تحديدًا، فإنّ الحرف “N” يُمثّل عدد المتاجر التي سيقوم الاستعلام الأول بإرجاعها، وسيتم تنفيذ استعلام select *from بنفس العدد على جداول المنتجات والأعضاء. ولأنّ هناك 3 متاجر، فهذا يعني بأنّنا سنقوم بإجراء 3 استعلامات على جدول الأعضاء و3 استعلامات أخرى على جدول المنتجات، وبالتالي يصبح عدد الاستعلامات التي تمّ تنفيذها بالكامل هو 3+3+1. تخيّل معي الآن ماذا كان سيحصل لو كان هناك 5 آلاف أو 10 آلاف متجر؟ سيكون هناك من 10 آلاف إلى 20 ألف استعلام في كلّ مرّة يزور أحدهم تلك الصفحة. وماذا لو كان هناك 10 آلاف أو 100 ألف زائر خلال 24 ساعة فقط؟ سيكون ذلك بمثابة كابوسٍ مرعبٍ بلا شك. يظهر الآن وبكلّ وضوح بأنّ هذه الطّريقة غير مجدية وقاتلة للأداء(performance killer). لن يهم أي قاعدة بيانات تستخدم أو قوّة الخادوم فستكون هناك دائمًا نقطة ما لن يستطيع العتاد القوي التعامل معها. يمكنك تحسين الأداء عن طريق التخزين المؤقت(caching) للاستعلامات؛ باستخدام Redis على سبيل المثال. سيعمل ذلك جيّدًا ولكن بشكل مؤقّت. ستقوم بتلك الطّريقة فقط بتأخير النّهاية الحتميّة التي ستكلّفك الكثير من المال والوقت وقد تخسر أيضًا الكثير من المستخدمين. وهنا يأتي دور التّحميل النّشط. فاستعمال التحميل النّشط في Laravel يُعدّ أمرًا في غاية السهولة. فعن طريق استخدام تابع with تقوم بتحديد العلاقات التي تريد أن يتمّ تحميلها تحميلاً نشطًا: $stores = Store::with('member','products')->get(); باستعمال التحميل النّشط، قمنا بتقليص عدد الاستعلامات من 7 إلى 3 فقط، كما توضح الصورة التالية: وحتى لو كان هناك 10 آلاف مُدخل للمتجر، فإنّ عدد الاستعلامات لن يتغير وسيبقى 3 فقط. وكما ترى، فإنّ استخدام التّحميل النّشط بالشّكل المناسب قد يُحسّن من الأداء بصورة كبيرة. وحتى نرى تحسّنًا فعليًا، فإنّه يجب أيضًا أن يكون هناك مؤشّر/فهرس(index) على حقول المُعرّفات(id fields) في جداول الأعضاء والمنتجات. فمع وجود الكثير من السجلات(records) فإنّ تنفيذ in( ‘1’, ‘2’, … ) على حقول غير مفهرسة(non-indexed) قد يأخذ بعض الوقت. بعد هذه المقدمة السّريعة عن التحميل النّشط، لنرى كيف يمكننا استعمال العلاقات(relations) مع المستودعات(repositories). تمديد فئة المستودع سأريك الآن طريقة واحدة لكيفية استعمال العلاقات (relations) في فئات المستودع. هذا مثال لنتيجة نهائية: function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); .... } فكما ترى في الأعلى، هناك تابع with ليمكننا من سلسلة نموذج العلاقات. هذا التابع سيكون شبيها بالتّابع with الخاصة بمُنشئ الاستعلامات في Laravel(Laravel’s Query Builder). public function with($relations) { if (is_string($relations)) $relations = func_get_args(); $this->with = $relations; return $this; } نحتاج الآن لربط كل علاقة(relation) إلى النموذج: protected function eagerLoadRelations() { if(!is_null($this->with)) { foreach ($this->with as $relation) { $this->model->with($relation); } } return $this; } ما تبّقى علينا الآن هو تحديث تابع المستودع all() (وأي توابع أخرى تريدها) لتستخدم التحميل النّشط: public function all($columns = array('*')) { $this->applyCriteria(); $this->newQuery()->eagerLoadRelations(); return $this->model->get($columns); } وكما ذكرت مسبقًا، يمكنك إضافة علاقات متعدّدة داخل وسيلة with(). وهذا مثال على StoresController: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); return \View::make('stores.index')->with('stores', $stores); } } يمكنك في الـView أن تعرض أيّ بيانات بالطريقة التي تريدها. لأغراض التّجريب سيكون التالي كافيًا: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span> <br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/> ======================== <br/> @endforeach يوجد الآن 3 استعلامات فقط كما هو متوقع: خاتمة كما رأيت، يمكنك باستعمال التحميل النّشط أن تُحسّن من أداء التطبيق الخاص بك. ولكن ضع في الحسبان بأنّه عندما يكبر تطبيقك، فإنّ التحميل النّشط لوحده لن يكون كافيًا للحصول على أفضل النتائج. ترجمة -وبتصرّف- للمقال Using Repository Pattern In Laravel 5 – Eloquent Relations And Eager Loading لصاحبه Mirza Pasic

قمت قبل عدّة سنوات ببناء موقع عميل لا يزال ناجحًا حتى اليوم ولكنّه أصبح بطيئًا بشكل محبط، فقاعدة البيانات مليئة بالفوضى وتستغرق بعض الصفحات 26 ثانية لتحميلها نظرًا لعدد الصور والطلبات الأخرى التي تقوم بها إلى الخادوم. قرّرنا أنّه حان الوقت لفعل شيء حول هذا الموضوع وإعادة بناء الموقع، وتطبيق تقنيات السرعة المُجرَّبة، والتي قلّلت زمن التحميل إلى ثانيتين على الصفحات المعقدة، وإلى 800 ميلي ثانية على الصفحات البسيطة. سنتحدّث في هذه السلسلة عن الإصلاحات التي فعلناها لكي تقوم بتحسين زمن تحميل موقعك الخاص، بما في ذلك تحسينات السرعة العامة والتحسينات المرتبطة بالتطوير. هذه السلسلة هي ليست مجرّد درس لتقديم بعض النصائح حول زيادة سرعة WordPress، ففي هذه السلسلة الشاملة سنتعلّم خطوة بخطوة ونمر على كل جانب لتحسين وزيادة سرعة موقع WordPress. أهمية سرعة الصفحةلن تتحمل تجاهل سرعة الصفحة إن كنت تكسب لقمة العيش من موقعك، فقد قام موقع Loadstorm بوضع بعض نتائج الأبحاث في رسم بياني جميل يُظهِر أنّ زيادة ثانية واحدة في زمن تحميل الصفحة page load تقود إلى خسارة 7% من التحويلات، مشاهدات للصفحة أقل بنسبة 11%، وانخفاض بنسبة 16% في رضا الزبائن. وبقلب هذه الإحصائية يتضح أنّ تقليل زمن تحميل موقعنا بمقدار ثانية واحدة قد يؤدي بسهولة إلى زيادة في الربح بمقدار 7%. قد ينسى الناس أيضًا أنّ جودة خدمة الإنترنت ليست موحّدة في أرجاء العالم، حتى لو استخدمنا CDN (شبكة تسليم محتوى) وقمنا بتحسين كل شيء. فربّما يتم تحميل صفحتنا خلال ثانيتين في نيويورك، وتستغرق 2.3 ثانية عند شخص يعيش في دبلن، ولكن ربّما يتم تحميلها في 4-5 ثوان في الهند. فبتحسين الأمور ربّما نقلل زمن تحميل الصفحة في الولايات المتحدة بمقدار 0.3 ثانية، ولكن ربّما يقلّل ذلك من زمن التحميل بمقدار 1.8 ثانية في الهند والذي يؤدي إلى زيادة في المبيعات، يجب ألّا ننسى أنّ الويب ضخم وأي رقم يتم عرضه هو معدّل وأي عدد نتعامل معه هو عيّنة واحدة من مجموعة متنوعة بشكل كبير. وبالإضافة إلى الفوائد المباشرة فمن المعروف أنّ سرعة الصفحة لها تأثير كبير على تهيئة الموقع لمحركات البحث SEO، لقد أبقت Google هذه التفاصيل مبهمة عن قصد، ولكن تسلّط بعض الأبحاث الضوء على الارتباطات الممكنة، على أيّة حال هنالك شيء واحد مؤكّد وهو أنّ السّرعة الأفضل تعني مرتبة أعلى في نظر Google. إن كنت مهتمًا بمجال البيئة فتستطيع التفكير بهذا كتمرين لتقليل انبعاثات الكربون، ينتج الموقع الأسرع عادة عن معالجة أقل، طلبات أقل، وبيانات أقل، وهذا يعني أن الحواسيب التي تتعامل مع موقعنا تعمل بشكل أقل، مما يؤدي إلى تقليل الحرارة المنبعثة عنها وبالتالي يعني تقليل حاجتها للتبريد، لن يلاحظ هذا التأثير غالبًا على مستوى خادوم وحيد ولكن يمكن قياسه على نطاق واسع. كيفية البدءسنقسم هذه السّلسلة إلى ثلاثة أجزاء، سنتحدث في هذا الجزء حول بعض الاعتبارات العامّة ونجرب ونحصل على الفروق الدقيقة لمشاكل السرعة وأسباب بطء الموقع، سيركز القسمان اللاحقان على التحسينات التي يستطيع أي مستخدم القيام بها والتحسينات التي يستطيع المبرمج القيام بها، سيكون هناك بعض التداخل في القسمين الأخيرين، ونحث غير المبرمجين على الاطلاع على كلا القسمين، يمكن تطبيق العديد من خطط زيادة السرعة عن طريق إرشادات بسيطة بالرغم من أنّها قد تمتلك بعض الشيفرة المتعلقة بها. نأمل في النهاية أن يأخذ الجميع بعض الأفكار ويطبقها مباشرة كي يصبح الويب مكانًا أسرع للجميع. لماذا يكون موقع الإنترنت بطيئا؟إنّ فهم هذا الأمر هو المفتاح لاتّخاذ قرارات ذكيّة، يوجد فرق كبير بين موقع يعمل ببطء لأنّه موجود على خادوم قليل التكلفة، وبين موقع يعمل ببطء بسبب عدم كفاءة الشيفرة أو تحميل الصور بشكل هائل. لاحظ أنّ القائمة التالية لا تحتوي على عناصر يمكن إصلاحها دومًا، سندرج كافة الطبقات المنفصلة التي تضيف إلى سرعتنا، ستكون وظيفتنا لاحقًا هي تحسين هذه السرعة، فلنتعلم الآن حول كافّة المكونات. تقنيات بسيطةتحدّد اللغة والتقنية البسيطة التي نستخدمها لتشغيل موقعنا مدى سرعة معالجة الشيفرة على الخادوم، إن استخدمنا HTML فقط فلن تكون هناك مشكلة، ولكن تستخدم معظم المواقع لغة برمجة من ناحية الخادوم server side programming. قد نستخدم ASP.net، PHP أو ربّما HHVM لتنفيذ شيفرة PHP، لا يوجد الكثير مما يمكننا القيام به لزيادة السرعة في اللغات الأساسيّة. ورغم أنني لست خبيرًا أعتقد أنّ ASP.net تمتلك تقنيًّا القدرة على أن تكون أسرع من PHP، لكن الاختلافات تبقى طفيفة. بدأت HHVM تفوق PHP منذ صدورها، ولكن كلا التقنيتان بدأتا بخوض حرب (وديّة) ويبدو الآن أنّ PHP 7 الجديدة ستتفوق على HHVM والتي نأمل أن تحفّز حلقة زيادة أداء من هاتين التقنيتين تجعلنا نحن المستخدمون النهائيون في غاية السعادة. ومن النقاط التي قد تصنع فرقًا هي الطريقة التي تمّ بها إعداد خادومنا، يمكن على سبيل المثال إعداد الخواديم لترسل البيانات بصيغة مضغوطة معروفة بضغط gzip، وهو إعداد بسيط يمكننا تشغيله وإيقافه، حيث أنّ تشغيله بوضوح يزيد سرعتنا، سننظر إلى مثل هذه التقنيات لاحقًا. نظام إدارة المحتوى Content Management Systemكقاعدة عامّة أي نظام إدارة محتوى CMS أبطأ من موقع ثابت static مصنوع بشكل مناسب بواسطة HTML، ومع أنّه صحيح أنّ التخزين المؤقّت لكامل الصفحات total page caching قد يقلّل فروقات السرعة ففي بعض الأحيان تحتاج التخزينات المؤقّتة إلى نهاية صلاحيتها، ولا يحصل المستخدمون قيد تسجيل الدخول عادةً على إصدارات مُخزّنة مؤقّتًا، كما يستهلك محتوى الإدارة موارد أكثر دومًا. يفيد نظام إدارة المحتوى المبني جيّدًا أكثر ممّا يضر بكثير، فهو أكثر أمانًا ونكون قادرين من خلاله على إضافة المحتوى بسهولة أكثر ويزوّدنا بالكثير من الميّزات التي نستطيع تطبيقها في أي وقت، تندرج جميع أنظمة إدارة المحتوى المعروفة تحت تصنيف مصنوعة بشكل جيّد، لذا فإنّ WordPress، Joomla، Drupal وأنظمة أخرى جيّدة من وجهة نظر السرعة. قد تكون مشاكل السرعة شائعة أكثر في بعض الأنظمة من الأنظمة الأخرى، ولكن يتعلّق هذا عادةً بالشيفرة الإضافيّة التي يتم استخدامها مثل القوالب themes، الإضافات plugins، المُلحقات extensions وما يشابهها، والتي سنلقي نظرة عليها لاحقًا. إنّ السبب الذي يجعل من أنظمة إدارة المحتوى أبطأ من المواقع الثابتة هو أنّها تحتاج إلى الاتصال إلى الخادوم، ويحتاج الخادوم إلى معالجة الطلب وتوليد شيفرة HTML ومن ثمّ إرسالها إلى المتصفّح، وقد توجد خلال هذه العمليّة العديد من استعلامات قواعد البيانات database queries التي تحتاج إلى تنفيذها والتي تزيد أيضًا من زمن التحميل. تمتلك معظم الأنظمة آليات لتحسين هذه العملية ولهذا تميل المواقع إلى تحميلها خلال عدّة ثوان، ممّا يجعل من هذه الأنظمة حلًّا عمليًّا. الملحقات Extensionsونقصد هنا المُلحقات بشكل عام، أي شيفرة مستخدمة على نظام إدارة المحتوى لدينا، تعني هذه بالنسبة لـ WordPress القوالب themes والإضافات plugins، وتُدعى في Joomla وDrupal القوالب templates والمُلحقات extensions. في كثير من الأحيان لا يتم إنشاء القوالب والإضافات من قبل نفس الأشخاص الذين صنعوا نظام إدارة المحتوى، ويعني هذا أنّه إن لم يكن المطورون على دراية بأفضل الأساليب المستخدمة حاليًّا فربّما يرتكبون بعض الأخطاء. توجد أثناء البرمجة العديد من الطرق التي نحصل من خلالها على شيفرة دون المستوى الأمثل بدون ظهور أخطاء فعليًّا. على سبيل المثال إن فكرنا باحتياجاتنا للبيانات ربّما نجد طريقة لاستعلام قاعدة البيانات مرّة واحدة خلال عمليّة ما. وإن لم نفكر جيّدًا ربّما نستخدم ثلاثة استعلامات، وفي الحقيقة قد تكون الاستعلامات الثلاثة أحيانًا أسرع من استعلام واحد بحسب احتياجاتنا، لذا فإنّ اختيار الطرق بعناية هام جدًّا. سنلقي نظرة على التقنيات المحدّدة للبرمجة والتي تبطّئ شيفرتنا، حاليًّا يجب أن نعلم أنّ المُلحقات تضيف طبقة من زمن التحميل لموقعنا. في WordPress يتم تضخيم السلبيات إلى حد ما بسبب حقيقة أن مجتمع WordPress مفتوح جدًّا، وهذا هو الجانب الرائع لـ WordPress والتي لا يجب أن يتم تغييرها ولكن يوجد لها عيوبها، فهي تجعل من السهل المساهمة بشيفرة سيئة، فلن يتمكن شيء من إيقافك (ولا ينبغي أن يوقفك أي شيء) من إنشاء قالب مُبرمَج بشكل سيء ومن ثم بيعه إن أردت. الخواديم والاستضافةالخادوم هو مكوّن كبير في تحديد سرعة الموقع، خاصّة الفترات التي يكون لديك فيها زيارات كثيرة، فلنقم بفصل هذين المصطلحين أولًا ونتعلّم المزيد كيف يؤثران على السرعة. إنّ خادومنا هو عبارة عن حاسوب حقيقي في مكان ما ويمتلك خصائص مشابهة للحواسيب المنزلية، فهو يمتلك ذاكرة، معالج، قرص صلب ومعاملات أخرى تحدّد كيفيّة عمله. إنّ خطة الاستضافة hosting plan هي أساسًا عبارة عن حزمة من الخدمات مربوطة بالخادوم، وتتضمن أشياء مثل النسخ الاحتياطيّة التلقائيّة، إدارة الخادوم، إلخ. ومن أجل زيادة سرعة موقعنا فإنه يجب أن نعرف أهم عامل يتعلّق بخطة الاستضافة، يعني هل موقعك مُستضاف على خطة مشتركة (shared plan)، خادوم VPS، أو خادوم مخصّص. خطة مشتركة، VPS، والخادوم المخصّصتمثل هذه المصطلحات الثلاث أنواعًا مختلفة من منهجيات الاستضافة، وهي تحدّد بشكل مُبسّط عدد الأشخاص الذين يستخدمون نفس الخادوم لاستضافة موقاعهم كما تفعل أنت. على الخدمات المشتركة قد تجد مئات الأشخاص على نفس الخادوم، ويعني هذا تشارك مئات الأشخاص لنفس مساحة القرص الصلب، الذاكرة، سرعة المعالج والتّدفّق bandwidth، لا تتم مشاركة الموارد بالتساوي، فقد يستخدم أحد المواقع حتى 80% من موارد الخادوم، تاركًا 99 مستخدم آخر على الـ 20% الباقية أو حتى أسوأ.تتم مشاركة الـ VPS (الخادوم الخاص الافتراضي Virtual Private Server)، ولكن عادةً بين أعداد مستخدمين أقل مع تقسيم الموارد بالتساوي، فإن كان هناك 5 مستخدمين على نفس الخادوم فسيحصل كل واحد منهم على 20% من الذاكرة على سبيل المثال، وإن حاول أحد المستخدمين تجاوزها فسيفشل موقعه ولكن تبقى مواقع المستخدمين الآخرين تعمل بشكل جيد.على الخادوم المخصّص تكون أنت المستخدم الوحيد للخادوم وكافّة موارده، وهذا يلغي تأثير الجيران السيئين الذي يحصل في الخدمات المشتركة وتمتلك المزيد من الموارد تحت تصرفك من الـ VPS (عادةً).إعدادات الخادوم Server Parametersيمتلك الخادوم الذي يوجد عليه موقعنا بعض الخصائص الرئيسية كما أشرنا والتي تحدد سرعته، وبشكل أساسي كلّما زاد أداء الخادوم كلما تحسّن أداء الموقع الموجود عليه. هناك طبعًا بعض الاستثناءات لهذا، فإن كنّا نملك موقع WordPress صغير مع عدد زيارات يُقدّر بعشرات الآلاف شهريًّا فلن يهمّنا حقًّا إن كانت ذاكرة خادومنا 1 غيغابايت أو 8 غيغابايت، عندما ننظر لاحقًا إلى الأشياء التي يمكن فعلها لزيادة السرعة سنتحدث متى يتم تغيير المضيفين والخواديم، سنناقش هذه المشكلة لاحقًا. ومن إحدى الخصائص التي تصنع فرقًا في السرعة هي مكان الخادوم، وهو أمر منطقي إلى حد ما، فإن كان الخادوم في سان فرانسيسكو سنتلقى البيانات منه بشكل أسرع إن كنّا في سان دييغو (على بُعد 500 ميل) ممّا لو كنّا في ملبورن في أستراليا (على بُعد 8000 ميل). تكون البيانات سريعة جدًّا عندما تمر في كابلات الألياف الضوئيّة وتصل تقريبًا لسرعة الضوء، ولكن حالما تقترب من منزلنا تخفف من سرعتها إلى سرعة مزودات خدمة الإنترنت ISP لدينا، تحتاج أيضًا إلى المرور عبر الجدران الناريّة firewalls والموجّهات routers والأجهزة الأخرى التي تبطّئ من سرعتها. تؤثر المسافة على السرعة عندما يكون هنالك طلبات أكثر، نقصد بهذا أنّ تنزيل ملف بحجم 1 غيغابايت من ملبورن سيستغرق تقريبًا نفس المدّة التي سيستغرقها إن تمّ تنزيله من سان دييغو، ولكن تنزيل 1024 ملف وكل ملف منها حجمه 1 ميغابايت سيأخذ وقتًا أطول بكثير إن كانت المسافة بعيدة. لماذا يهمنّا هذا؟ عندما يتم تحميل الموقع قد يقوم بعدد كبير من الطلبات، يتضمّن هذا ملفّات التنسيق، الصور، ملفّات javascript وملفّات أخرى، وبتقليل الطلبات نستطيع زيادة السرعة إلى الحد الأقصى. حاسوب العميليؤثّر الحاسوب القديم الذي نستخدمه بشكل كبير على سرعة الاتصال المتصوّرة، فمثلًا عند تجربة iPad 2 ستكون سرعة الاتصال عليه أبطأ من iMac. توجد العديد من الأسباب لهذا، ولكن السبب الرئيسي هو عمر الحاسوب، فقد أدّى تدهور مكوّنات iPad في المثال السابق إلى استخدامه الذاكرة بشكل أقل فاعليّة، لذلك فهو يعالج المحتوى بشكل أبطأ وأقل استجابة بشكل عام. لم تكن هذه مشكلة كبيرة حتى وقت قريب لأنّ معظم الحوسبة كانت تتم على الخادوم، ولكن مع ظهور أجهزة عملاء أقوى وتقنيّات ويب جديدة أصبحت المواقع تعتمد على قوّة المعالجة من ناحية العميل client side processing. على سبيل المثال يعني هذا تحريكًا أكثر نعومة وسرعة، ولكن يعني أيضًا معاناة الأجهزة البطيئة. بالمحصلة يتم تحديد سرعة أي موقع عن طريق التقنية الرئيسية المستخدمة فيه، نظام إدارة المحتوى، الخادوم والاستضافة، وحاسوب العميل. الخاتمةتحدّثنا في هذا الجزء عن أسباب بطء الموقع، سنكمل في الأجزاء اللاحقة حول طرق زيادة السرعة بالنسبة لغير المطورين وبالنسبة للمطورين. ترجمة -وبتصرّف- لـ THE ULTIMATE MEGA GUIDE TO SPEEDING UP WORDPRESS لصاحبه Daniel Pataki.

المراقبة هي جزء مهم من إدارة الخواديم والخدمات الأساسية؛ تُراقَب معظم الخدمات الشبكية للأداء (performance) أو التوفر (availability) أو كليهما؛ سيَشرح هذا الفصل طريقة تثبيت وضبط Nagios لمراقبة التوفر، و Munin لمراقبة الأداء. سنستخدم في أمثلة هذا الفصل خادومين بأسماء server01 و server02؛ سيُضبَط server01 مع Nagios لمراقبة الخدمات التي عليه وعلى الخادوم server02؛ وسيُضبَط server01 مع Munin لجمع المعلومات من الشبكة، باستخدام حزمة munin-node، وسيُضبَط server02 لكي يُرسِل المعلومات إلى server01. نأمل أن تساعدك هذه الأمثلة البسيطة في مراقبة الخواديم والخدمات الإضافية في شبكتك. Nagiosالتثبيتأولًا، ثبت الحزمة nagios على خادوم server01، وذلك بإدخال الأمر الآتي في الطرفية: sudo apt-get install nagios3 nagios-nrpe-pluginسيُطلَب منك إدخال كلمة مرور لمستخدم nagiosadmin، تصاريح المستخدم مخزنة في ‎/etc/nagios3/htpasswd.users. ولتعديل كلمة مرور nagiosadmin أو إضافة مستخدمين آخرين إلى سكربتات Nagios CGI، فاستخدم htpasswd الذي هو جزء من حزمة apache2-utils. على سبيل المثال، لتغيير كلمة المرور لمستخدم nagiosadmin: sudo htpasswd /etc/nagios3/htpasswd.users nagiosadminلإضافة مستخدم جديد: sudo htpasswd /etc/nagios3/htpasswd.users steveالآن على خادوم server02، ثبِّت الحزمة nagios-nrpe-server؛ بتنفيذ الأمر الآتي على server02: sudo apt-get install nagios-nrpe-serverملاحظة: سيسمح NRPE لك بتنفيذ فحوصات محلية على الأجهزة البعيدة، هنالك طرق أخرى للقيام بذلك عبر إضافات Nagios أخرى. لمحة عن الضبطهنالك عدة مجلدات تحتوي على ضبط Nagios وملفات التحقق (check files). ‎/etc/nagios3: يحتوي على ملفات الضبط لعمل عفريت nagios، وملفات CGI، والمضيفين ...إلخ.‎/etc/nagios-plugins: يحتوي ملفات الضبط للتحقق من الخدمات.‎/etc/nagios: في المضيفين البعيدين، ويحتوي على ملفات ضبط nagios-nrpe-server.‎/usr/lib/nagios/plugins/‎: المكان الذي تخزَّن فيه ملفات التحقق الثنائية، استخدم الخيار ‎-h لمشاهدة المساعدة لتحققٍ ما. مثال: ‎/usr/lib/nagios/plugins/check_dhcp -hهنالك وفرة في التحققات التي يمكن ضبط Nagios ليجريها على أي مضيف؛ سيُضبَط Nagios في هذا المثال للتحقق من مساحة القرص الصلب المتوفرة و DNS و MySQL؛ سيُجرى تحقق DNS على server02 وتحقق MySQL على server01 و server02. هنالك بعض المصطلحات التي عندما تُشرَح ستُسهِّل فهم ضبط Nagios: المضيف (host): خادوم أو محطة عمل (workstation)، أو جهاز شبكي ...إلخ. الذي يُراقَب.مجموعة مضيفين (host group): مجموعة من المضيفين المتشابهين؛ على سبيل المثال، تستطيع أن تُجمِّع كل خواديم الويب أو خواديم الملفات ...إلخ.الخدمة (service): الخدمة التي تُراقَب في المضيف، مثل HTTP أو DNS أو NFS ...إلخ.مجموعة الخدمات (service group): تسمح لك بجمع عدِّة خدمات متشابهة مع بعضها بعضًا، هذا مفيد لتجميع عدّة خدمات HTTP على سبيل المثال.جهة الاتصال (contact): الشخص الذي سيُنبَّه عندما يحدث حدثٌ ما؛ يمكن ضبط Nagios ليرسل بريدًا إلكترونيًا أو رسائل SMS ...إلخ.افتراضيًا، يكون ضبط Nagios ليتحقق من HTTP، والمساحة التخزينية المتوفرة في القرص، و SSH، والمستخدمين الحاليين، والعمليات، والحِمل على localhost؛ سيتحقق Nagios أيضًا من البوابة بعمل ping لها. تثبيتات Nagios الضخمة قد يصبح ضبطها معقدًا جدًا، لذلك من الأفضل عادةً البدء بمضيف واحد أو اثنين ثم التوسع بعد ضبطهما جيدًا. الضبطأولًا، أنشئ ملف ضبط للمضيف للخادوم server02؛ ما لم يُذكر عكس ذلك، فعليك تنفيذ هذه الأوامر على server01؛ أدخِل ما يلي في الطرفية: sudo cp /etc/nagios3/conf.d/localhost_nagios2.cfg \ /etc/nagios3/conf.d/server02.cfgملاحظة: في الأوامر السابقة أو التالية استبدل «server01» و «server02» و 172.18.100.100 و 172.18.100.101 بأسماء المضيفين وعناوين IP لخادومَيك. ثم عدِّل الملف ‎/etc/nagios3/conf.d/server02.cfg: define host{ use generic-host ; Name of host template to use host_name server02 alias Server 02 address 172.18.100.101 } # check DNS service. define service { use generic-service host_name server02 service_description DNS check_command check_dns!172.18.100.101 }أعد تشغيل عفريت nagios لتفعيل الضبط الجديد: sudo service nagios3 restartأضف الآن تعريفًا للتحقق من MySQL بإضافة ما يلي إلى ‎/etc/nagios3/conf.d/‎ services_nagios.cfg: # check MySQL servers. define service { hostgroup_name mysql-servers service_description MySQL check_command check_mysql_cmdlinecred!nagios!secret!$HOSTADDRESS use generic-service notification_interval 0 ; set > 0 if you want to be renotified }يجب الآن تعريف مجموعة المضيفين mysql-servers؛ عدِّل الملف ‎/etc/nagios3/conf.d ‎/hostgroups_nagios2.cfg مضيفًا: # MySQL hostgroup. define hostgroup { hostgroup_name mysql-servers alias MySQL servers members localhost, server02 }يحتاج Nagios لأن يستوثق إلى MySQL، فأضف مستخدم nagios إلى MySQL بإدخال الأمر: mysql -u root -p -e "create user nagios identified by 'secret';"ملاحظة: يجب أن يتواجد المستخدم nagios في كل المضيفين في مجموعة mysql-servers. أعد تشغيل nagios ليبدأ التحقق من خواديم MySQL: sudo service nagios3 restartأخيرًا، اضبط NRPE للتحقق من المساحة الفارغة في القرص على الخادوم server02. أضف التحقق من الخدمة في server01 في ملف ‎/etc/nagios3/conf.d/server02.cfg: # NRPE disk check. define service { use generic-service host_name server02 service_description nrpe-disk check_command check_nrpe_1arg!check_all_disks!172.18.100.101 }الآن على الخادوم server02، عدِّل الملف ‎/etc/nagios/nrpe.cfg مغيّرًا: allowed_hosts=172.18.100.100ثم في منطقة تعريف الأمر أضف ما يلي: command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -eفي النهاية، أعد تشغيل nagios-nrpe-server: sudo service nagios-nrpe-server restartوأيضًا على الخادوم server01 أعد تشغيل nagios: sudo service nagios3 restartيجب أن تكون قادرًا على رؤية المضيف والتحقق من الخدمات في ملفات Nagios CGI؛ للوصول إليهم، وجِّه متصفحك إلى http://server01/nagios3؛ ثم ستُسأل عن اسم مستخدم nagiosadmin وكلمة مروره. مصادرلم يشرح هذا القسم من الدرس إلا القليل من ميزات Nagios؛ تحتوي الحزمتين nagios-plugins-extra و nagios-snmp-plugins على المزيد من تحققات الخدمات. للمزيد من المعلومات، راجع موقع Nagios، تحديدًا موقع «التوثيق».هنالك قائمة بالكتب المتعلقة بمراقبة الشبكة و Nagios.صفحة ويكي أوبتتو «Nagios» فيها بعض التفاصيل الإضافية.Muninالتثبيتقبل تثبيت Munin على server01، فيجب أن يُثبَّت قبله apache2؛ الضبط الافتراضي كافٍ لتشغيل خادوم munin. أولًا، ثبت munin على الخادوم server01 بإدخال الأمر: sudo apt-get install muninالآن ثبِّت الحزمة munin-node على الخادوم server02: sudo apt-get install munin-nodeالضبطعدِّل الملف ‎/etc/munin/munin.conf على الخادوم server01 مُضيفًا عنوان IP للخادوم server02: ## First our "normal" host. [server02] address 172.18.100.101ملاحظة: استبدل server02 و 172.18.100.101 باسم المضيف وعنوان IP الحقيقي لخادومك. الآن اضبط munin-node على الخادوم server02، بتعديل ‎/etc/munin/munin-node.conf للسماح بالوصول إلى الخادوم server01: allow ^172\.18\.100\.100$ملاحظة: استبدل ‎^172\.18\.100\.100$ بعنوان IP لخادوم Munin الخاص بك. أعد تشغيل munin-node على server02 لكي تأخذ التعديلات مجراها: sudo service munin-node restartفي النهاية، وجِّه متصفحك إلى http://server01/munin، يجب أن ترى روابط إلى مخططات بيانية جميلة تعرض معلومات من الحزمة القياسية munin-plugins للقرص والشبكة والعمليات والنظام. ملاحظة: لما كان هذا التثبيت حديثًا، فربما ستحتاج لبعض الوقت لعرض معلومات مفيدة. إضافات أخرىتحتوي حزمة munin-plugins-extra على تحققات من أداء خدماتٍ إضافية مثل DNS و DHCP، وسامبا ...إلخ. أدخل الأمر الآتي لتثبيت هذه الحزمة: sudo apt-get install munin-plugins-extraتأكد من تثبيت هذه الحزمة على جهازَيّ الخادوم والعقدة. مصادرراجع موقع Munin لمزيدٍ من التفاصيل.تحديدًا صفحة «توثيق Munin» التي تحتوي على معلومات عن الإضافات الأخرى، وكيفية كتابة إضافات ...إلخ.مصدر آخر هو صفحة ويكي أوبنتو «Munin».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Monitoring.

من بين جميع اختصارات العبارات المتعلقة بالشبكات الاجتماعية، أظن أنّ الاختصار KPI هو أكثر ما يربكني. ربما لأن العبارة "مؤشر الأداء الرئيسي key performance indicator" تشعرني وكأنني بحاجة إلى ارتداء لباس رسمي والوقوف أمام عرض PowerPoint تقديمي لغرض قولها. لكن عندما آتي إلى الواقع فهي بسيطة للغاية، إذ تمثل مؤشرات الأداء الرئيسية الأشياء المهمة التي ينبغي لي التركيز عليها وقياسها. بشكل عام، تعتبر مؤشرات الأداء الرئيسية لوسائل التواصل الاجتماعي، أو مقاييس وسائل التواصل الاجتماعي، مهمة جدًا لعملك مهما كانت تلك المقاييس، وهي تلك الأهداف والمعايير القياسية التي تساعدك على تحديد جودة أداء حملاتك واستراتيجياتك. يمكن أن تكون مؤشرات الأداء الرئيسية مقدار التفاعل engagement أو المشاركات التي تحصل عليها على شبكات التواصل الاجتماعي الخاصة بك. كما بإمكانك تتبع النقرات التي يحصل عليها موقعك عبر وسائل التواصل الاجتماعي أو التحويلات conversions بمجرد وصول الزّوّار إليه. في الواقع، هناك العديد من مؤشرات الأداء الرئيسية المختلفة، وفي بعض الأحيان يكون من الصعب تحديدها والتمييز بينها. سنلقي نظرة في هذا المقال على مجموعة متنوعة من مقاييس وسائل التواصل الاجتماعي يمكنك الاختيار من بينها والتركيز عليها، مع توضيح مختصر لكل منها وكيفية قياسها. لمحة سريعة إلى قمع التواصل الاجتماعي Social Media Funnelتستحق الأقماع لوحدها مقالًا منفصلًا، لكن يكفي هنا أن نكوّن تصورًا عن رحلة العميل النموذجية مع العلامة التجارية أو المنتج. ألق نظرة على هذا الرسم التوضيحي من Intersection Consulting: هناك فرص للقياس في كل مرحلة من مراحل الرحلة، وهي الأقسام الخمسة الكبيرة التي سنركز عليها في هذا المقال: النشاط Activity: نتاج الفريق الاجتماعي الخاص بك.الوصول Reach: جمهورك والجمهور المحتملون.التفاعل Engagement: التفاعل والاهتمام بعلامتك التجارية.الاكتساب Acquisition: بناء علاقة.التحويل Conversion: الإجراءات، المبيعات والنتائج.الإدامة والتأييد Retention and advocacy: العملاء الراضون والمتحمسون حول دعم علامتك التجارية.مقاييس النشاط: نتاج الفريق الاجتماعي الخاص بكوهي الأرقام التي تعرض نتائج جهود فريق إدارة حسابات وسائل التواصل الاجتماعي الخاصة بك، وتتضمن النشر، الجدولة، تحسين المحتوى، الإجابة على الأسئلة وحل المشاكل. قد تبدو هذه المقاييس بسيطة، ولكن سيصبح قياسها مهمًا كلما جربت أشياءً جديدة. من الجيد أن تكون قادرًا على تحديد فيما إذا كانت الزيادة في أنشطتك تُنتج زيادة في بعض المقاييس الأخرى التي سنذكرها لاحقا في هذا المقال. متوسط زمن الإجابة Average response timeالوقت الذي يستغرقه الفريق أو ممثل العلامة التجارية للرد على التعليقات والاستفسارات من جمهور العلامة التجارية على الشبكات الاجتماعية. معدل المحتوى Content rateعدد المُحتويات الذي تنتجه لكل فترة. قد ترغب في تجزئة مقياس معدل المحتوى إلى عدة مقاييس حسب نوع المحتوى الذي تركز عليه، مع التركيز على: مقالات المدونة لكل فترة زمنية.العروض التقديمية لكل فترة زمنية.الفيديوهات لكل فترة زمنية.الكتب الإلكترونية لكل فترة زمنية.الأوراق البيضاء لكل فترة زمنية.الإنفوجرافيك لكل فترة زمنية.الأنواع الأخرى من إنشاء المحتوى لكل فترة زمنية.معدل النشر Post rateعدد المنشورات على شبكات التوصل الاجتماعي لكل فترة زمنية. ربما ترغب في تجزئة مقياس معدل النشر حسب الشبكات التي تنشط عليها، مع التركيز على: التغريدات لكل فترة زمنية.منشورات فيس بوك لكل فترة زمنية.تحديثات لينكدإن لكل فترة زمنية.تحديثات Google+ لكل فترة زمنية.منشورات Pinterest(Pins) لكل فترة زمنية.منشورات إنستجرام لكل فترة زمنية.منشورات المنتديات لكل فترة زمنية.وغيرها من شبكات التواصل الاجتماعي التي تستخدمها باستمرار.مزيج مواضيع المنشورات Post topic mixالنسبة المئوية للمقالات في كل شبكة اجتماعية لكل فترة زمنية مقسمة حسب موضوع المحتوى (مثلا، الصّور، العروض الخاصة، مقالات المدونة، إلخ). مزيج أنواع المنشورات Post type mixالنسبة المئوية للمقالات في كل شبكة اجتماعية لكل فترة مقسمة حسب نوع المحتوى (مثلا، الصور، الروابط، الفيديوهات، النصوص، الاستفتاءات، إلخ). معدل الإجابة Response rateالنسبة المئوية للأسئلة، التعليقات، أو المشاكل من الناس الذي يتحدثون حول علامتك التجارية والتي تقوم بالرد عليها خلال فترة زمنية محددة. ميزانية التسويق عبر شبكات التواصل الاجتماعيمقدار المال التي يصرفه فريقك لكل فترة زمنية. مقاييس الوصول: جمهورك وجمهورك المحتملوهي المقاييس التي تركز على حجم الجمهور والجمهور المحتمل ومعدل نموه، بالإضافة إلى عدد مرات وصول رسائلك إليهم وأدائها في التأثير عليهم. توفر العديد من أدوات إدارة شبكات التواصل الاجتماعي (مثل Buffer) عددا من المقاييس من هذا النوع. معدل نمو الجمهور Audience growth rateوهو المعدل الذي تقوم فيه الإعلانات بإضافة (أو فقدان) أفراد الجمهور لكل وسيلة من وسائل التواصل الاجتماعي. ويتم إيجاد المعدل بقسمة عدد أفراد الجمهور الجدد على مجموع الأفراد الكلي. متوسط الموضع Average positionوهو الموضع الذي تظهر فيه إعلانات العلامة التجارية على صفحة نتائج محرك البحث. (1 لما يظهر الإعلان في أعلى الصّفحة) الوعي بالعلامة التجارية Brand awarenessالعدد الكلي للإشارات mentions إلى العلامة التجارية على الإنترنت لكل فترة زمنية. CPM Cost per thousandالكلفة لكل ألف ظهور للإعلان في الإعلانات المدفوعة. المعجبون/المتابعونالعدد الكلي للأشخاص في شبكاتك المختلفة لكل فترة زمنية. نقاط التأثير Influence scoreتوفَر هذه النقاط من قبل مزودين مثل Klout وKred، وهي مقياس لمدى تأثير الشخص أو العلامة التجارية على شبكة معينة. تواتر الكلمة المفتاحية Keyword frequencyعدد مرات ظهور كلمة مفتاحية أو عبارة معينة في المخطط الاجتماعي للعلامة التجارية. الوصول للمنشور Post reachالعدد المتوقع للناس الذين يشاهدون محتوى معينًا على الأقل مرة واحدة خلال فترة زمنية محددة. الانطباعات المحتملة Potential impressionsعدد المرات التي يمكن فيها عرض محتوى معين خلال فترة زمنية، بغض النظر عما إذا كان الجمهور يتفاعل معه أم لا. الوصول المحتمل Potential reachالعدد المحتمل من الناس من ضمن جمهور العلامة التجارية، مضافا إليه أصدقاء أفراد الجمهور أو الآخرين في المجتمع الذين قد يمتلكون الفرصة لرؤية محتوى معين خلال فترة زمنية. حصة العلامة التجارية من الجمهور Share of audienceالنسبة المئوية للأشخاص الذي تصلهم العلامة التجارية مقارنة بمنافسيها. حصة العلامة التجارية من التفاعل Share of engagement كيفية مقارنة مقاييس التفاعل للعلامة التجارية مع مقاييس العلامات التجارية الأخرى في مجالات مشابهة. حصة العلامة التجارية من الأصوات Share of voiceوهو مقياس لكمية الحديث المتداول حول العلامة التجارية في المحادثات مقارنة مع العلامات التجارية الأخرى في نفس المجال. الشعور/الرأي Sentimentالنسبة المئوية للإشارات الكلية للعلامة التجارية سواء كانت إيجابية، محايدة، أو سلبية في الرأي. مشاهدات الفيديو Video viewsعدد المشاهدات التي يحصل عليها المحتوى من نوع فيديو على قنوات مثل يويتيوب، Vimeo، أو فيس بوك. مقاييس التفاعل: التفاعل والاهتمام بالعلامة التجاريةوهي المقاييس التي تركز على كيفية تفاعل الناس مع المحتوى الذي تنشره على الشبكات الاجتماعية، مشاركته، وإعادة مشاركته. معدل التضخيم Amplification rateعدد المشاركات في المتوسط لكل منشور. قد ترغب في تجزئة مقياس معدل التضخيم حسب الشبكات التي تنشط عليها، مع التركيز على: إعادة تغريد التغريدات.مشاركات فيس بوك.مشاركات Google +.مشاركات لينكدإن.إعادة النشر (repin) على Pinterest.إعادة النشر (regram) على إنستجرام.معدل التصفيق Applause rateعدد إجراءات الاستحسان، أو "التصفيق" الافتراضي الذي تحصل عليه من جمهورك لكل فترة. ويشتمل على الإعجاب، التفضيلات، +1، التأييد، إلخ. متوسط معدل التفاعل Average engagement rateالنسبة المئوية لعدد الجمهور الكلي الذي تفاعل مع المحتوى الذي تنشره بأي طريقة كانت على الوسائل الاجتماعية خلال فترة التقرير. معدل التعليق Comment rateمتوسط عدد التعليقات الذي يحصل عليه المحتوى لكل منشور. معدل المحادثات Conversation rateعدد المحادثات الجارية لكل منشور على وسائل التواصل الاجتماعي. تتمثل هذه المحادثات بالتعليقات على فيس بوك، Google+، لينكدإن، Pinterest، وإنستجرام. أما على تويتر فهي تتمثل بالردود. التفاعل كنسبة مئوية من الجمهورالمجموع الكلي لإجراءات التفاعل على جميع الشبكات الاجتماعية مقسومًا على عدد الجمهور الكلي. التفاعل لكل معجب/متابعالمجموع الكلي لإجراءات التفاعل لشبكة واحدة مقسومًا على عدد المعجبين (أو المتابعين) على تلك الشبكة. الفيروسية Viralityمعدل انتشار محتوى معين (كالفيروس) عبر الشبكة الاجتماعية. من الوسائل الجيدة لقياس الفيروسية هي عدد المشاركات الكلي لكل محتوى. مقاييس الاكتساب: بناء العلاقاتفي هذه المرحلة ربما يبدأ الأشخاص الذي يتحدثون معك على تويتر أو فيس بوك بالتعمق أكثر في علاقتهم مع علامتك التجارية، وربما يقومون بزيارة موقعك لمعرفة ما تقدمه. تركز مقاييس الاكتساب على تجربة الزّوّار وفيما إذا كان جمهورك يتوافق مع ما توفره أو القيمة التي تقدمها. تزودك بعض الأدوات التحليلية مثل Google Analytics بالعديد من هذه المقاييس. مشتركو المدونة Blog subscribersعدد الأشخاص المشتركين في مدونتك. معدل الارتداد Bounce rateالنسبة المئوية للزائرين الذين يزرون صفحة واحدة فقط في موقعك، ثم يغادرون إلى المكان الذي قدموا منه بدلا من نقر المزيد من الروابط في موقعك. النقرات Click-throughsعدد النقرات على رابط محدد في منشور على شبكة اجتماعية محددة. معدل النقرات Click-throughs rateالمعدل قيام الجمهور بالنقر على رابط معين في منشور على شبكة اجتماعية محددة. ويُحسب بقسمة عدد النقرات على منشور على عدد مرات ظهور المنشور. CPC cost per clickالكلفة لكل نقرة (للبحث أو الإعلان الاجتماعي المدفوع). اشتراكات البريد الإلكتروني Email subscriptionsعدد المشتركين في قائمتك البريدية. العملاء المحتملون Leadsعدد اتصالات المبيعات المحتملة خلال وسائل التواصل الاجتماعي لكل فترة زمنية. الروابط Linksعدد الصفحات التي تشير بروابط إلى صفحة معينة على موقعك. التحويلات الدقيقة Micro-conversionsأي نشاط قابل للقياس ينخرط فيه مستخدمو العلامة التجارية باستمرار قبل عملية التحويل. مشاهدات الصفحة Pageviewsعدد الصفحات التي تتم مشاهدتها أو النقر عليها على موقعك خلال زمن معين. النسبة المئوية للزيارات الاجتماعية Percentage of social visitsالنسبة المئوية للتدفق القادم إلى موقعك والذي تمت إحالته من وسائل التواصل الاجتماعي. الرتبة لكل كلمة مفتاحية Rank per keywordمتوسط الموضع الذي يحصل عليه المحتوى في محرك البحث لكل كلمة مفتاحية أو عبارة محددة. الجلسات (الزائرون الفريدون) Sessionsمجموعة من التفاعلات التي تحدث على موقعك خلال نطاق زمني محدد (يمكن أن تحتوي الجلسة الواحدة على شاشة متعددة أو مشاهدات الصفحة، أحداث، أو تفاعلات اجتماعية). مدة الجلسة (الزمن المستغرق في الموقع) Session durationالمدة الكلية لجميع الجلسات (بالثواني) مقسومة على عدد الجلسات. التدفق Trafficعدد الزيارات والزّوّار الذين تحيلهم وسائل التواصل الاجتماعي إلى موقعك لكل فترة زمنية. نسبة التدفق Traffic ratioالنسبة المئوية للتدفق من كل من الشرائح الرئيسية الثلاث: الزّوار المباشرون: الأشخاص الذي يزورون موقعك بكتابة عنوان الموقع مباشرة في شريط العنوان لمتصفحاتهم.الزّوار من خلال البحث: الأشخاص الذي يزورون موقعك استنادا إلى طلبات البحث.الزّوار من خلال الإحالة: الأشخاص الذين يصلون إلى موقعك من خلال مدونة أخرى أو موقع آخر.مقاييس التحويل: الإجراءات، المبيعات، والنتائجأقصى هدف تأمل في أن يقوم الزائر بتحقيقه من خلال تعامله مع علامتك التجارية هو التركيز على مقاييس التحويل. يمكن أن يكون التحويل بيعا، اشتراكا، تنزيلا، تسجيلا، أو العديد من الإجراءات الأخرى. مجددا، تعتبر تحليلات جوجل من الأدوات المفيدة في توفير هذا النوع من المقاييس. متوسط قيمة الشراء/متوسط قيمة الطلب Average purchase value/average order valueمتوسط القيمة لكل عملية شراء تتم بواسطة عملائك. متوسط الإيرادات لكل عميل Average revenue per customerمقدار ما ينفق متوسط العملاء مع العلامة التجارية، ويُحسب بقسمة الإيرادات السنوية على عدد العملاء السنوي. التحويلات Conversionsعدد التحويلات لكل فترة زمنية. يمكن أن تعرّف التحويلات بأنّها الإجراء النهائي الذي ترغب في أن يتخذه المستخدمون على موقعك. من الأمثلة على ذلك اشتراكات البريد الإلكتروني، التنزيلات، التسجيلات، تنصيب أداة، إلخ. معدل التحويل Conversion rateالنسبة المئوية للمستخدمين الذين يقومون باتخاذ إجراء التحويل المرغوب، ويُحسب بقسمة عدد التحويلات على التدفق الكلي لكل فترة زمنية. الكلفة لكل اكتساب أو الكلفة لكل إجراء cost per acquisition or cost per action CPAالمبلغ الذي تدفعه العلامة التجارية لغرض الحصول على عميل محتمل. الكلفة لكل تحويل Cost per conversionالمبلغ الذي تدفعه العلامة التجارية لاكتساب تحويل. تحويلات الزّوّار الجدد New visitor conversionsعدد التحويلات التي تحدث لكل فترة زمنية بواسطة الزّوار الجدد لموقع العلامة التجارية. تحويلات الزّوّار المتكررين Return visitor conversionsعدد التحويلات التي تحدث لكل فترة زمنية بواسطة الزّوّار المتكررين لموقع العلامة التجارية. الإيراد لكل نقرة Revenue per click RPCمتوسط الإيرادات المتولدة عن كل نقرة في الإعلانات المدفوعة. معدل التحويل عبر وسائل التواصل الاجتماعيالنسبة المئوية للتحويلات الكلية التي تعزى إلى وسائل التواصل الاجتماعي. وتُحسب بقسمة تحويلات التواصل الاجتماعي على التحويلات الكلية. عائد الاستثمار Return on investment ROIالإيرادات المتولدة بواسطة الجهود على وسائل التواصل الاجتماعي مقسومة على جميع نفقات وسائل التواصل الاجتماعي المعروفة. مقاييس الإدامة: العملاء الراضون والمتحمسون حول دعم العلامة التجاريةتغطي مؤشرات الأداء الرئيسية هذه، والتي تتجاوز كونها مقاييس تقليدية لوسائل التوصل الاجتماعي إلى مقاييس عامة للأعمال، المرحلة الأخيرة، وربما الأكثر أهمية، من رحلة العملاء. هذه هي المرحلة التي تنشئ فيها قاعدة من العملاء السعداء الذين يمكن أن يتحولوا إلى أهم القوى المولدة لمبيعات العلامة التجارية. وبعبارة أخرى نقوم بقلب القمع رأسا على عقب. المتحمسون للعلامة التجارية Brand evangelistsعدد العملاء الذين يمكن اعتبارهم متحمّسين لدعم العلامة التجارية بناءً على تأييدهم لها على حسابات التواصل الاجتماعي الخاصة بهم. القيمة السنوية للعميل Customer annual or lifetime valueصافي الربح المتوقع والذي ينسب إلى كامل العلاقة المستقبلية مع العميل. معدل إدامة العميل Customer retention rateالنسبة المئوية للعدد الكلي للعملاء الذين تم الاحتفاظ بهم إلى العملاء الذين تم إلغاؤهم. تقييمات العملاء Customer reviews/ratingsعدد التقييمات الإيجابية أو السلبية التي يتم تلقيها من قبل العملاء لكل فترة زمنية. رضا العملاء Customer satisfactionمقياس لمدى تلبية المنتجات أو الخدمات المقدمة من قبل شركة ما لتوقعات العملاء أو تجاوزها لتلك التوقعات. معدل رضا العملاء Customer satisfaction rateوهي عبارة عن علامة يعبر عنها كنسبة مئوية من 0 إلى 100. تمثل النسبة 100% رضا العميل بالكامل. وعادة ما يتم إيجاد هذا المقياس من خلال سؤال واحد في استطلاع متابعة على غرار السؤال: بكم تقيم رضاك العام عن الخدمة التي تلقيتها؟ معدل دوران العملاء Customer turnover rate/churnمقياس لعدد العملاء الذين يغادرون خلال فترة زمنية محددة. عامل K-factorمقياس لمعدل نمو المواقع، التطبيقات، أو قاعدة العملاء. صافي نقاط الترويج/المروج Net Promoter Scoreيتم إيجاد هذا المقياس من إجابة العملاء على السؤال: ماهي احتمالية أن تقوم بتوصية [خدمة/منتج الشركة] لصديق أو زميل؟ باستخدام نقاط من 0 إلى 10. كلفة الدعم لكل تذكرة Support cost pet ticketإجمالي نفقات التشغيل السنوية لفريق الدعم مقسوما على حجم التذاكر الشهري. نصيحة ختاميةربما لاحظت عند اطلاعك على هذا المقال أنّ هناك العشرات من المقاييس التي يمكنك تحليلها. لكن أنت وحدك من يعرف المقاييس المناسبة التي تخبرك أنّ استراتيجياتك ناجحة. لا تنسَ أنّك أنت الخبير، وتأكّد من أن المقاييس التي تستخدمها تصلح لك، وليس العكس. هل هناك مقاييس لم تُذكر في هذا المقال؟ وما هي المقاييس المهمة بالنسبة لك ولعلامتك التجارية؟ ترجمة -وبتصرّف- للمقال 61Key Social Media Metrics, Defined لصاحبته: Courtney Seiter.

إنّ Mytop هي أداة سطر أوامر مفتوحة المصدر open source تُستخدَم لمراقبة أداء MySQL، وهي مستوحاة من أداة مراقبة نظام لينِكس التي تُدعى top ومُشابِهة لها في الشّكل والمظهر، تتصل Mytop إلى خادوم MySQL وتقوم بشكل دوري بتشغيل الأمرين show processlist و show global status، وتقوم بعدها بتلخيص المعلومات بشكل مفيد، نستطيع باستخدام Mytop مراقبة (بشكلٍ آني real-time) مناقشات MySQL threads، الاستعلامات queries، وزمن التشغيل uptime، بالإضافة إلى أنّها ترى أي مستخدم يقوم بتنفيذ استعلامات على أي قاعدة بيانات، وأي الاستعلامات تجري ببطء والمزيد من ذلك، نستطيع استخدام كل هذه المعلومات لتحسين أداء خادوم MySQL. سنناقش في هذا الدّرس كيفيّة تثبيت، إعداد، واستخدام mytop. المتطلبات الأساسيةقبل البدء في هذا الدرس ينبغي أن نمتلك ما يلي لدينا: CentOS 7 64-bit Droplet (تعمل أيضًا مع CentOS 6).مستخدم غير جذري non-root مع صلاحيّات sudo سيتم تنفيذ جميع الأوامر عن طريق هذا المستخدم.خادوم MySQL يعمل على الـ Droplet.الخطوة الأولى – تثبيت Mytopفلنقم بتثبيت الحِزَم المطلوبة من أجل mytop. نحتاج في البداية إلى تثبيت مستودع yum الذي يُدعى (EPEL (Extra Packages for Enterprise Linux على الخادوم، إنّ EPEL هي مجموعة ذات اهتمامات مشتركة بتوزيعة Fedora تقوم بإنشاء، إدارة، والحفاظ على مجموعة حِزَم برمجيّة إضافيّة add-on مفتوحة المصدر عالية الجّودة من أجل Enterprise Linux، نقوم بتنفيذ الأمر التالي لتثبيت وتمكين مستودع EPEL على خادومنا: على CentOS 7: sudo rpm -ivh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpmعلى CentOS 6: sudo rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmوقبل المتابعة نتحقّق أنّه تم تمكين المستودع EPEL باستخدام: sudo yum repolistإن تمّ تمكينه سنشاهد في الخَرْج ما يلي: epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64فلنقم بعد ذلك بحماية الحِزَم الأساسيّة من EPEL باستخدام إضافة yum plugin التي تُدعى protectbase: sudo yum install yum-plugin-protectbase.noarch -yالغرض من الإضافة protectbase هو حماية بعض مستودعات yum من تحديثات المستودعات الأخرى، فلن يتم تحديث أو تجاوز override الحِزَم الموجودة في المستودعات المحميّة بواسطة الحِزَم في المستودعات غير المحميّة حتى ولو كان المستودع غير المحمي يملك إصدارًا أحدث. نحن الآن مستعدون لتثبيت حِزمة mytop، فلنقم بتنفيذ الأمر التالي لتثبيتها: sudo yum install mytop -yسيقوم هذا الأمر بتثبيت حِزمة mytop بالإضافة إلى جميع اعتمادياتها dependencies والتي هي في معظمها وحدات perl modules. الخطوة الثانية – ضبط إعدادات Mytopنقوم قبل استخدام mytop بإنشاء ملف إعدادات مُخصَّص من أجل mytop يُدعى mytop.، وذلك بكتابة الأمر التالي: sudo nano /root/.mytopنضيف المحتوى التالي إلى الملف ونقوم بحفظه وإغلاقه: root/.mytop/ host=localhost db=mysql delay=5 port=3306 socket= batchmode=0 color=1 idle=1سيتم استخدام ملف الإعدادات عندما نقوم بتشغيل mytop بشكل مباشر كمستخدم جذري root وعندما نقوم بتشغيلها باستخدام الأمر sudo كمستخدم غير جذري يملك صلاحيّات sudo. نستطيع القيام بتغييرات إلى ملف الإعدادات اعتمادًا على احتياجاتنا، على سبيل المثال يُحدِّد الخيار delay الفترة الزمنيّة مقدرةً بالثانية بين تحديثات العرض display، فإن كُنّا نرغب بتحديث عرض mytop كل 3 ثوان بإمكاننا تحرير الملف root/.mytop/ باستخدام: sudo nano /root/.mytopومن ثمّ تغيير ما يلي: root/.mytop/ delay=3يُحدِّد المُعامِل idle إذا ما كان سيسمح للمناقشات threads الخاملة idle (النائمة) بالظهور في قائمة شاشة عرض mytop، الوضع الافتراضي هو إظهار المناقشات الخاملة، إن تمّ حذف المناقشات الخاملة سينعكس ترتيب الفرز sorting الافتراضي بحيث تظهر أطول الاستعلامات قيد التشغيل في أعلى القائمة، إن كُنّا نرغب في فعل هذا نُحرّر الملف root/.mytop/ ونغيّر ما يلي: root/.mytop/ idle=0نستطيع الرجوع إلى صفحات mytop اليدويّة للمزيد من المعلومات عن جميع المُعامِلات في ملف الإعدادات والتي تحتوي على وصف لكل مُعامِل، للوصول إلى الصفحات اليدويّة نستخدم الأمر: man mytopنستطيع كتابة q للخروج من الدّليل. الخطوة الثالثة – الاتصال إلى Mytopسنناقش في هذا القسم كيفيّة الاتصال إلى mytop واستخدامها لعرض استعلامات MySQL. تتطلّب Mytop اعتمادات credentials للنفاذ إلى قاعدة البيانات، والتي يمكن تزويدها عبر مُحِث prompt في سطر الأوامر أو عبر تخزينها في ملف الإعدادات، سنستخدم من أجل أمان أفضل الخيار prompt-- والذي يسأل كل مرّة عن كلمة السّر. فلنتصل إلى mytop باستخدام: sudo mytop --promptونُدخِل كلمة سر المستخدم root في MySQL في المُحِث، بإمكاننا أيضًا استخدام العديد من مُعطيات arguments سطر الأوامر مع الأمر mytop، نرجو الرجوع إلى الصفحات اليدويّة من أجل الحصول على قائمة كاملة بها، على سبيل المثال إن كُنّا نرغب باستخدام مستخدم mysql مُختلف مثل sammy للاتصال إلى mytop نقوم باستخدام الأمر التالي: sudo mytop -u sammy --promptوللاتصال ومراقبة قاعدة بيانات مُحدّدة فقط نستخدم الأمر التالي: sudo mytop -d databasename --promptللخروج من mytop والعودة إلى مُحث الصّدفة shell prompt نكتب q. الخطوة الرابعة – عرض وتفسير شاشة عرض Mytopسنرى في هذا القسم كيفيّة تفسير شاشة عرض mytop والميزات المختلفة التي تُقدّمها هذه الأداة. حالما نتصل إلى mytop باستخدام mytop --prompt سيتم أخذنا إلى طريقة عرض المناقشات thread view، والتي ستظهر خَرْج مشابه لما يلي: Output of mytop MySQL on localhost (5.5.41-MariaDB) up 0+00:05:52 [01:33:15] Queries: 148 qps: 0 Slow: 0.0 Se/In/Up/De(%): 09/00/00/00 qps now: 2 Slow qps: 0.0 Threads: 6 ( 5/ 0) 67/00/00/00 Key Efficiency: 2.0% Bps in/out: 14.7/320.7k Now in/out: 192.5/731.8k Id User Host/IP DB Time Cmd Query or State -- ---- ------- -- ---- --- ---------- 2 root localhost mysql 0 Query show full processlist 16 root localhost 0 Sleep 17 root localhost testdb 0 Query SELECT * FROM dept_emp 18 root localhost testdb 0 Query SELECT * FROM dept_emp 19 root localhost testdb 0 Query SELECT * FROM dept_emp 20 root localhost testdb 0 Query SELECT * FROM dept_empنستطيع العودة إلى طريقة العرض هذه إن كُنّا في طريقة عرض أخرى بكتابة t. تُقسم شاشة العرض السّابقة إلى قسمين، تُؤلّف الأسطر الأربعة الأولى الترويسة header والتي يُمكن تشغيلها وإيقافها بضغط SHIFT-H، تحتوي الترويسة على معلومات موجزة حول خادوم MySQL لدينا. يُحدِّد السطر الأول اسم المضيف hostname للخادوم وإصدار MySQL الموجود، يُظهر القسم الأيمن منه زمن التشغيل uptime لعمليّة خادوم MySQL بصيغة الأيام+السّاعات:الدّقائق:الثواني (days+hours:minutes:seconds) بالإضافة للوقت الحالي.يعرض السطر الثاني العدد الكلّي للاستعلامات التي قام الخادوم بمعالجتها (148 في حالتنا)، متوسط عدد الاستعلامات في الثانية، عدد الاستعلامات البطيئة، والنسبة المئوية للاستعلامات اختيار Select، إدخال Insert، تحديث Update، وحذف Delete.يُظهِر السطر الثالث قيم آنيّة real-time منذ التحديث refresh الأخير لـ mytop، إنّ زمن التّحديث (التأخير) الطبيعي في mytop هو 5 ثوان، لذا إن تمّ إجراء 100 استعلام خلال آخر 5 ثوان منذ التحديث سيكون عدد qps now هو 20، الحقل الأول هو عدد الاستعلامات في الثانية (qps now: 2). القيمة الثانية هي عدد الاستعلامات البطيئة في الثانية، يُشير القسم Threads: 6 ( 5/ 0) إلى وجود 6 مناقشات threads مُتّصلة، 5 منها نشطة (واحدة منها نائمة) وعدم وجود أي مناقشات (الرقم 0) في الذّاكرة المؤقّتة cache للمناقشات، يُظهر الحقل الأخير في السّطر الثالث النّسبة المئويّة للاستعلام، كما هو الحال في السّطر السابق، ولكن منذ التحديث الأخير لـ mytop.يعرض السّطر الرّابع فعاليّة key buffer (وهو عدد المرات التي فيها قراءة المفاتيح keys من الـ buffer بدلًا من القرص) وعدد البايتات التي أرسلتها واستقبلتها MySQL، كلاهما بالمجمل ومنذ آخر تحديث لـ mytop. تُظهِر Key Efficiency: 2.0% أنّه يتم قراءة 2% من المفاتيح من الـ buffer وليس من القرص، تُظهِر Bps in/out: 14.7/320.7k أنّه منذ بدء التشغيل تلقّت MySQL ما يُعادِل 14.7kbps من حركة البيانات traffic الواردة و 320.7kbps من حركة البيانات الصادرة، يُظهِر Now in/out حركة البيانات أيضًا ولكن منذ آخر تحديث لـ mytop.يعرض القسم الثاني من شاشة العرض مناقشات MySQL الحاليّة مع فرزها بحسب زمن خمولها (الأقل خمولًا أولًا)، نستطيع عكس ترتيب الفرز بضغط O عند الحاجة لذلك، يتم هنا أيضًا عرض مُعرِّف المناقشة thread id، اسم المستخدم، المُضيف الذي يتصل منه المستخدم، قاعدة البيانات التي يتصل إليها المستخدم، زمن الخمول مُقدّرًا بالثانية، الأمر الذي تقوم المناقشة بتنفيذه (أو حالة المناقشة)، والقسم الأول من معلومات الاستعلام، إن كانت المناقشة في حالة استعلام Query (أي يعرض العمود Cmd القيمة Query) فسيعرض العمود التالي الذي يُدعى Query or State القسم الأول من الاستعلام الذي يتم تنفيذه، أمّا إن كانت حالة الأمر هي نائم Sleep أو خامل Idle فسيكون العمود Query or State فارغًا عادةً، في مثال الخَرْج السّابق لدينا فإنّ المناقشة ذات المُعرِّف id 2 هي فعليًّا mytop والتي تقوم بتشغيل الاستعلام show processlist لجمع المعلومات، والمناقشة ذات المُعرِّف 16 نائمة (أي لا تقوم بمعالجة استعلام ولكنّها تبقى متصلة)، والمناقشة ذات المُعرِّف 17 تقوم بتشغيل استعلام SELECT على قاعدة البيانات testdb. الآن وقد فهمنا أساسيّات شاشة عرض mytop، سنرى كيفيّة استخدامها لجمع المزيد من المعلومات حول مناقشات واستعلامات MySQL، فلنلقِ نظرة على شاشة عرض mytop التّالية: [secondary_output Output of mytop] MySQL on localhost (5.5.41-MariaDB) up 0+00:13:10 [23:54:45] Queries: 2.8k qps: 4 Slow: 51.0 Se/In/Up/De(%): 45/00/00/00 qps now: 17 Slow qps: 0.0 Threads: 52 ( 51/ 0) 96/00/00/00 Key Efficiency: 100.0% Bps in/out: 215.4/ 7.6M Now in/out: 2.0k/16.2M Id User Host/IP DB Time Cmd Query or State -- ---- ------- -- ---- --- ---------- 34 root localhost testdb 0 Query show full processlist 1241 root localhost 1 Sleep 1242 root localhost testdb 1 Query SELECT * FROM dept_emp 1243 root localhost testdb 1 Query SELECT * FROM dept_emp 1244 root localhost testdb 1 Query SELECT * FROM dept_emp 1245 root localhost testdb 1 Query SELECT * FROM dept_emp 1246 root localhost testdb 1 Query SELECT * FROM dept_emp 1247 root localhost testdb 1 Query SELECT * FROM dept_empتكون الاستعلامات مبتورة في طريقة عرض المناقشات thread view (طريقة العرض الافتراضيّة)، ولمشاهدة كامل الاستعلام بإمكاننا أن نضغط F وسيتم سؤالنا كما يلي: Full query for which thread id:نُدخِل مُعرِّف المناقشة thread id التي نريد عرض استعلامها، على سبيل المثال نكتب 1244 وسنشاهد ما يلي: Thread 1244 was executing following query: SELECT * FROM dept_emp WHERE ... -- paused. press any key to resume or (e) to explain --نستطيع كتابة e لشرح explain الاستعلام، والذي يقوم بشرح الاستعلام الذي يتم تنفيذه حتى نعرف إذا ما كان هذا هو الاستعلام الأمثل، إنّ EXPLAIN هي واحدة من أقوى الأدوات لفهم وتحسين استعلامات MySQL الصعبة، على سبيل المثال: EXPLAIN SELECT * FROM dept_emp: *** row 1 *** table: dept_emp type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 332289 Extra: NULL -- paused. press any key to resume --بإمكاننا أن نضغط على أي مفتاح للخروج من هذا الوضع أو نكتب t للعودة إلى طريقة عرض المناقشات الافتراضيّة. ومن طرق العرض المفيدة الأخرى المتاحة في mytop هي طريقة عرض الأوامر command view، وللوصول إليها نكتب c، ستبدو مشابهة لما يلي: Command Total Pct | Last Pct ------- ----- --- | ---- --- select 1782 55% | 100 8% show status 723 22% | 533 45% show processlist 708 22% | 532 45% change db 2 0% | 0 0% show variables 1 0% | 0 0% Compression 0 0% | 0 0%يُظهِر العمود Command نوع الأمر أو الاستعلام الذي يتم تنفيذه، يرمز العمود Total إلى العدد الإجمالي لهذا النوع من الأوامر التي تم تنفيذها منذ بدء تشغيل الخادوم، ويُظهِر العمود Pct نفس ما سبق ولكن بالنسبة المئوية. وعلى الناحية الأخرى من الخط العمودي نجد العمود Last والذي يُخبرنا بعدد هذا النوع من الأوامر التي تم تشغيلها منذ آخر تحديث لـ mytop، تُعطينا هذه المعلومات فكرة عمّا يقوم به خادوم MySQL على المدى القريب والبعيد. ناقشنا في هذا الدّرس بعضًا من ميّزات mytop الهامّة والمفيدة، هناك العديد من الميّزات الأخرى المتاحة، ولعرض قائمة كاملة من الخيارات نستطيع أن نضغط المفتاح أثناء تشغيل mytop. الخاتمةيجب أن يكون لدينا الآن معرفة جيّدة حول كيفيّة استخدام mytop لمراقبة خادوم MySQL لدينا، وهي أيضًا نقطة انطلاق لإيجاد مشاكل استعلامات SQL وتحسينها، وبالتالي زيادة الأداء الإجمالي للخادوم. ترجمة -وبتصرّف- لـ How To Use Mytop to Monitor MySQL Performance لصاحبته Veena K John.

هل تُواجهك صعوبات عند عملية قياس تأثير حملتك التسويقية عبر البريد الإلكتروني؟ أنت تعرف ما معنى "معدّلات الفتح والنقر " open and click-through rates، ويمكنك حتى أن ترى كل شخص قام بفتح رسالة البريد الإلكتروني الذي قمت بإرساله على خريطة كبيرة وجميلة. لكنك لا تزال غير قادر على قياس عدد الزبائن والعملاء المحتملين الذين يمكن أن تظفر بهم بفضل حملاتك عبر البريد الإلكتروني. لحسن حظك، يمكن دمج أدوات التسويق عبر البريد الإلكتروني مثل Campaign Monitor بشكل مباشر مع Google Analytics، فبذلك تستطيع أن تعرف كم عدد الناس الذين يقومون بالنقر على رسائلك التسويقية عبر البريد الإلكتروني، والولوج لموقع الويب الخاص بك لترى إمكانية تحويلهم لزبائن وعملاء محتملين. أفضل جزء هو: أنك تستطيع فعل ذلك بسهولة. في هذا المقال سوف نحدد 3 خطوات بسيطة لمساعدتك على تحقيق ذلك. 1. إعداد متعقب الحملة التسويقية "Campaign Tracking"الخطوة الأولى لتتبع نجاح حملتك عبر البريد الإلكتروني هو إعداد متعقّب الحملة Campaign Tracking. عندما يأتي الناس إلى موقعك الإلكتروني من المواقع الأخرى مثل تويتر وفيسبوك، فإنه من السهل على Google Analytics معرفة من أين أتوا، ويقوم بإرفاق بيانات حركة الزوّار على نحو ملائم (كحركة الزّوار من المواقع الاجتماعية، كمثال). ومع ذلك، في حالة البريد الإلكتروني، إذا كنت لا تستخدم هذه الأشياء الصغيرة والتي يطلق عليها "متغيرات UTM"، فإن حركة الزوّار القادمة من حملاتك (رسائلك التسويقية) عبر البريد الإلكتروني سيتم تصنيفها على أنها زيارات مُباشرة (Direct)، بمعنى وكأن الزّائر كتب رابط الصّفحة في المُتصفّح مُباشرة. متغيرات UTM هي في الأساس مُعاملات صغيرة يمكنك إضافتها إلى نهاية روابطك في حملات البريد الإلكتروني لتخبر أداة Google Analytics من أين جاء هذا الشخص. دعونا ننظر في حملة بريدية قمنا بها مؤخّرًا كمثال على ذلك. هنا يظهر كيف يمكن أن يبدو الرابط بوجود متغيرات UTM أو بدونها: هل رأيت جميع الوسوم الإضافية الملحقة في نهاية نطاق URL؟ إنها تخبر Google Analytics من أين جاء هذا الشخص. على الرغم من أن هذه الروابط تبدو جنونية، لكنها سهلة الإنشاء. لديك خياران: يمكنك إرفاق جميع روابطك يدويًا، أو إذا كنت تستخدم خدمة Campaign Monitor، يمكنك تشغيل مُرفِق الروابط بشكل تلقائي "automatic link tagging". كيفية إرفاق الروابط يدويالإرفاق الروابط في رسائل بريدك الإلكتروني يدويًا، يمكنك استخدام محرّر نطاقات URL. يتم توفير هذه الأداة المجانية عن طريق Google Analytics، وتسمح لك بملء بعض الحقول والحصول على وصلة موسومة بشكل رائع يمكنك وضعها مباشرة في حملتك التسويقية. يمكنك إدخال أي من القيم في النموذج الذي تحتاجه، ولكن في المثال أعلاه، أنشأنا نطاق URL ليخبر أداة Google Analytics بالتالي: تتبع حملة مخصصة اسمها 'canvas'.مصدر الحملة هو 'إعلان' عبر البريد الإلكتروني.وسط الحملة هو "البريد الإلكتروني".الرابط الموجّه للنقر من هو "زر " CTA (الدّعوة إلى الإجراء)، ويُطلق عليه اسم "مُصطلح الحملة" (campaign term).الآن كل ما عليك القيام به هو نسخ الرابط الذي توفره الأداة واستخدامه خلف الأزرار والروابط في حملات البريد الإلكتروني الخاصة بك. كيفية إرفاق الروابط تلقائياقد تبدو عملية إرفاق الرّوابط يدويا صعبة جدّا. ولهذا ستجد أن خدمات مثل Campaign Monitor تسمح بالقيام بذلك بشكل آلي. لأنها تتيح للعملاء ببساطة تغيير جميع الروابط في حملاتهم تلقائيا المرتبطة مع متغيرات UTM. يتم تمكينه لمرة واحدة، وسنقوم بإضافة متغيرات UTM التالية تلقائيا إلى حملات البريد الإلكتروني الخاص بك: utm_medium = البريد الإلكتروني.utm_campaign = اسم حملة التسويق عبر البريد الإلكتروني (ليس عنوان الرسالة).utm_content = اسم حملة التسويق عبر البريد الإلكتروني بالإضافة إلى معرف حملة فريد من نوعه (CID).utm_source = تُرفق في حال ما إذا حدّدت قيمة source term.utm_term = نص الارتباط، أو وصف بديل (للصور).2. إنشاء شريحة متقدمة على Google Analyticsالشرائح المتقدمة بالأساس عبارة عن مُرشحات والتي تسمح لك برؤية البيانات في تقاريرك من زوار معيّنين، مثل الزوّار القادمين من محرك البحث أو الزوّار القادمين من البريد الإلكتروني. لإنشاء شريحة، أنقر على مربع إضافة شريحة فوق أيٍ من التقارير القياسية الخاصة بك. بالنسبة لهذا المثال، نريد فقط رؤية زوّار الموقع الذين جاؤوا من خلال حملة التسويق عبر البريد الإلكتروني. للقيام بذلك، أنقر فوق الزرّ الأحمر لإنشاء شريحة جديدة وسمّها "Campaign Medium: email". في القائمة اليسرى، حدّد: Traffic Sources، وفي حقل Medium field اختر "Exactly Matches" واكتب "email". عند الانتهاء، انقر فوق Save. يمكنك استخدام نفس مربع إضافة شريحة للعثور على شريحتك الجديدة وتطبيقه على تقاريرك. بمجرّد القيام بذلك، سترى عدد من الأشخاص الذين جاؤوا عبر حملاتك التسويقيّة عبر البريد الإلكتروني جنبًا إلى جنب مع مقاييسك المعتادة، كما في المثال التالي: 3. استعرض تقاريركوالآن بعد أن قمت بتمكين مُتعقّب الحملة "Campaign Tracking" ونصّبت حركة الزّوار من البريد الإلكتروني باعتبارها شريحة متقدمة، يمكنك أن تشاهد فعليًا أيُّ تقرير في أداة Google Analytics وترى تأثير حملات التسويق عبر بريدك الإلكتروني بالأرقام. لكي تبدأ، إليك 4 من التقارير المفضّلة لدينا لفهم تأثير حملاتك التسويقية عبر البريد الإلكتروني: تقرير الوقت الفعليإذا كنت قد أرسلت رسائل تسويقيّة إلى قائمتك البريدية، سيكون مشاهدتها مثيرة للاهتمام في الوقت الفعلي، حيث يبدؤون بالنقر والدخول إلى موقعك على الويب والتّنقل بين جَنَباته. يمكن الوصول إلى التقرير في الوقت الفعلي عن طريق تحديد "Real-Time" من شريط القوائم الأيسر ومن ثم اختيار "Traffic Sources" و "Email". وهنا يظهر كيف يبدو تقريرنا لحظة كتابة هذه السّطور. كما ترون، سوف يُظهر لك التقرير عدد الناس في الموقع في الوقت الحالي الذين جاؤوا من رسائل البريد التسويقية، وسيبيّن حتى القناة التسويقية التي جاؤوا من خلالها. تقرير النظرة العامةتحتاج فقط لمعرفة حركة الزيارات التي تأتي بجهود التسويق عبر البريد الإلكتروني لموقعك وقارن ذلك مع حركة الزيارات بشكل عام؟ التقرير الشامل سيكون مناسبًا لك. للوصول إلى ذلك، تأكد من أن الشريحة المتقدمة "Campaign Medium: Email" مُفعّلة، ثم ببساطة اختر "Audience" من القائمة الجانبية اليسرى وقم باختيار" Overview". في هذه اللقطة الوحيدة، ستكون قادرًا على معرفة عدد الزيارات (التي تسمى الآن جلسات) التي جلبتها حملاتك التسويقية عبر بريدك الإلكتروني وكذلك عدد الزوار (ويطلق عليهم المستخدمين). يمكنك أن ترى أيضا عدد الصفحات لكل زيارة ومعدل الارتداد. بالإضافة إلى ذلك، يمكنك بسهولة مقارنة كل هذه المقاييس مع النتائج ككل، أو إمن خلال وسائل أخرى مثل المنصات الاجتماعية أو محركات البحث إذا قمت بإضافة بعض الشرائح المتقدمة الأخرى. تقرير الحملة التسويقية Campaign reportإذا كنت تريد أن ترى تأثير كل حملاتك التسويقية ومقارنتها مع بعضها البعض، إذًا سيدُلك تقرير الحملة التسويقية للمكان الذي تريد أن تكون فيه. تأكد من أن الشريحة المتقدمة "Campaign Medium: Email" مُفعّلة ثم انتقل إلى تبويب "Acquisition" في شريط القائمة اليسرى. ثم حدد "Campaigns". بعد ذلك، سوف تحتاج إلى الضغط على رابط "Campaign" فوق الجدول لفرز الجدول بحسب أفضل الحملات أداءًا. كما ترى في الأعلى، سوف يظهر في التقرير عدد الزيارات (وتسمى جلسات) والزوار (ويسمّون المستخدمين) التي جلبتها كل حملة إلى موقع الويب الخاص بك. إذا سبق لك تجهيز "مُتعقّب هدف" goal tracking أو "متعقّب تجارة إلكترونية" eCommerce tracking ، يمكنك حتى أن ترى عدد عمليات الشراء التي قام بها الناس، أو أي نموذج آخر من التحويل لكل حملة. تقرير سلوك التدفق "the behavior flow report"هل سبق لك أن احتجت معرفة ما يفعله الناس على موقعك بمجرد وصولهم من رسالتك التسويقية؟ هل يغادرون وينتهي الأمر؟ أم أنهم يرون عرض التسعير الخاص بك أو يذهبون لصفحة تواصل معنا؟ لحسن الحظ، يمكن لتقرير سلوك التدفق أن يخبركم بالضبط ما يفعله الناس عند وصولهم إلى موقع الويب الخاص بك من حملة معينة. للوصول إليه، اختر 'Behavior' من القائمة اليسرى ثم اختر "Behavior Flow". بعد ذلك، ستحتاج إلى تحديد "Campaigns" من القائمة الخضراء المنسدلة فوق العمود الأول من التقرير. بهذا سوف تظهر لك جميع الحملات الخاصة بك، وإذا كنت تريد أن ترى حملة واحدة معينة فقط اضغط عليها واختر "View only this segment". كما هو موضح في المثال أعلاه، أولئك الذين جاؤوا من النشرة الإلكترونية لشهر يوليو هبطوا في المقام الأول على تدوينة ‘Canvas Redesign’ (والتي كانت مميزة في النشرة). وذهب عدد لعرض صفحة الهبوط بينما ذهب البعض لتفقّد معرض الصور أو شاهد صفحة التسعير لدينا. باستخدامك تقرير سلوك التدفق، يمكنك أن ترى بالضّبط ما فعله الناس بعدما دخلوا لموقعك الإلكتروني من حملة معينة. خاتمةببساطة، عن طريق تمكين أداة متعقّب الحملة ووضع شريحة متقدمة، يمكنك الحصول على نظرة مُعمّقة لنجاح حملاتك في التسويق عبر البريد الإلكتروني، وتشاهد كيف يتفاعل الناس مع موقعك بعد النقر والدخول من رسائل البريد الإلكتروني. تأكّد من مراقبة هذه التقارير بشكل مستمر، واستخدم الخبرات المكتسبة للتقرير لكل من النجاح في حملات التسويقية عبر البريد الإلكتروني وكذلك المضي قدمًا في تحسين أداءها. ترجمة -وبتصرّف- للمقال: 3Steps to measure the success of your email marketing with Google Analytics لصاحبه AARON BEASHEL. حقوق الصورة البارزة: Designed by Freepik.

بعد أن قمنا مسبقًا بتثبيت وإعداد خادوم قاعدة بيانات MySQL التجريبي الخاصّ بنا، يمكننا الآن البدء باستخدام mysqlslap. يمكن تشغيل mysqlslap عبر طرفية الصدفة العادية، لذا لن يكون هناك حاجة إلى الدخول إلى MySQL لتشغيله من هناك. وعلى الرغم من ذلك، فإننا سنقوم في درسنا هذا بفتح اتصالٍ جديد إلى خادومنا بالإضافة إلى بدء جلسة MySQL جديدة من هناك بواسطة المستخدم sysadmin الذي أنشأناه من قبل، لكي نتمكّن من التحقق من بعض الأمور وتحديث أخرى في MySQL بشكلٍ أسهل. لذا وفي المجمل، فإننا سنمتلك طرفيةً واحدة مفتوحة مع مستخدمٍ بصلاحيات إدارية (sudo)، وطرفية واحدة لـMySQL. قبل أن ندخل في الأوامر الرئيسية المُستخدمة للاختبار، قد تودّ أن تلقي نظرةً على هذه القائمة لأكثر الخيارات المفيدة لـmysqlslap. يمكن أن يساعدك هذا على تصميم أوامر mysqlslap الخاصّ بك لاحقًا. الخياروظيفتهuser--اسم مستخدم MySQL الذي يجب الاتصال به على خادوم قاعدة البياناتpassword--كلمة المرور الخاصّة باسم المستخدم. من الأفضل تركها فارغة في سطر الأوامرhost--اسم خادوم قاعدة بيانات MySQLport--رقم المنفذ الذي يجب من خلاله الاتصال بـMySQL إذا كان الافتراضي غير مستخدمconcurrency--عدد اتصالات العملاء الافتراضية التي سيتم محاكاتها من طرف mysqlslapiterations--عدد المرّات التي سيتم تشغيل الاختبار فيهاcreate-schema--قاعدة البيانات التي سيتم تشغيل الاختبار عليهاquery--عملية الاستعلام التي يجب تنفيذها. يمكن لهذا أن يكون متغيّر استعلام SQL أو مسارًا لملفّ سكربت SQLcreate--الاستعلام الذي يجب إنشاؤه كجدول، مجددًا، يمكن لهذا أن يكون متغيّر استعلام SQL أو مسارًا لملفّ SQLdelimiter--الحائل الذي يجب استخدامه للفصل بين جُمَل SQL متعددةengine--محرّك قاعدة البيانات الذي يجب استخدامه، مثل InnoDBauto-generate-sql-- يسمح هذا الخيار لـMySQL بتنفيذ اختبار الحِمل باستخدام أمر SQL المُنشَئ تلقائيًا من طرف mysqlslapحالة استخدام: اختبار الأداء مع بيانات واستعلامات SQL منشئة تلقائياسنبدأ عبر استخدام ميّزة mysqlslap في الإنشاء التلقائي لجمل SQL. عندما نقوم باستخدامها، فإنّ mysqlslap سيقوم بإنشاء قاعدة بيانات مؤقّتة منفصلة تدعى "mysqlslap". ستحوي قاعدة البيانات هذه جدولًا بسيطًا يحوي هو الآخر عددًا صحيحًا واحدًا وعمودًا واحدًا من نوع varchar بداخله بيانات تجريبية. يمكن أن تكون هذه طريقةً سهلة وسريعة للتحقق من أداء خادوم قاعدة البيانات الكلّي. سنبدأ عبر اختبار اتصال عميلٍ واحدٍ فقط يتم تكراره مرّةً واحدة كذلك باستخدام جملة SQL مُنشئة تلقائيًا: sudo mysqlslap --user=sysadmin --password --host=localhost --auto-generate-sql --verboseيجب أن يبدو الخرج كالتالي: Benchmark Average number of seconds to run all queries: 0.009 seconds Minimum number of seconds to run all queries: 0.009 seconds Maximum number of seconds to run all queries: 0.009 seconds Number of clients running queries: 1 Average number of queries per client: 0يقوم mysqlslap بإعطاء بعض الإحصائيات عن اختبار الأداء كما رأينا من الخرج السابق، حيث أنّه يقوم بإرجاع متوسّط، أقل وأعلى عدد من الثواني التي يحتاجها ليقوم بتنفيذ عملية الاستعلام. يمكننا أيضًا أن نرى أنّ عدد اتصالات العملاء المُستخدمة لاختبار الحِمل هذا كان واحدًا فقط. الآن، جرّب محاكاة 50 اتصال، وقم باختيار تشغيل عملية الاستعلام المُنشَئة تلقائيًا 10 مرّات: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=10 --auto-generate-sql --verboseيعني هذا الأمر أنّه سيتم محاكاة 50 اتصالًا، يقوم كلّ منها بتنفيذ نفس عملية الاستعلام بنفس الوقت، وسيتم إعادة هذه الاختبار 10 مرّات. يظهر لنا الخرج فرقًا واضحًا في الوقت مع ازدياد الحِمل: Benchmark Average number of seconds to run all queries: 0.197 seconds Minimum number of seconds to run all queries: 0.168 seconds Maximum number of seconds to run all queries: 0.399 seconds Number of clients running queries: 50 Average number of queries per client: 0لاحظ كيف أنّ حقل "Number of clients running queries" أصبح الآن يظهر الرقم 50، وأنّ عدد عمليات الاستعلام بواسطة العميل الواحد هو صفر. تقوم SQL المُشَئة تلقائيًا بإنشاء جدولٍ بسيط يحوي حقلين اثنين، إلّا أنّه وفي معظم البيئات الإنتاجية فستكون بنية الجدول أكبر بكثير من هذا. يمكننا أن نفرض على mysqlslap أن يقوم بمحاكاة هذا عبر إضافة بعض الحقول الإضافية إلى جدول الاختبار. لفعل ذلك، يمكننا استخدام المُعامِلين الجديدين number-char-cols-- وnumber-int-cols--. تقوم هذه المُعامِلات بتحديد عدد الأعمدة من نوع varchar وint لإضافتها إلى جدول الاختبار. سنختبر استعلام SQL مُنشَئ تلقائيًا عن جدولٍ بـ5 أعمدة رقمية و20 عمود نصّي في المثال التالي. سنحاكي أيضًا 50 اتصالًا من أجهزة العملاء في الوقت ذاته وسنقوم بتكرار الاختبار 100 مرّة: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=100 --number-int-cols=5 --number-char-cols=20 --auto-generate-sql --verbosسيستغرق هذا الأمر وقتًا أطول. يمكننا أن نتحوّل إلى الطرفية الأخرى الني قمنا بتشغيل جلسة MySQL الخاصّة بنا عليها لنرى ما يجري بينما يتم تنفيذ الاختبار. لاحظ أنّه في حال انتظرت وقتًا طويلًا، سيكتمل الاختبار ولن تتمكن من رؤية قاعدة البيانات الاختبارية. من طرفية MySQL، طبّق: show databases;لاحظ وجود قاعدة mysqlslap: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | mysqlslap | | performance_schema | +--------------------+ 5 rows in set (0.01 sec)يمكنك أن تتحقق من الجدول في قاعدة البيانات الاختبارية إن أردت; إنّه يدعى t1. تحقق من نافذة الطرفية الأخرى الآن. عندما ينتهي الاختبار، ستلاحظ أنّ الأداء قد انخفض بدرجةٍ أكبر من السابق بسبب الحِمل الزائد: Benchmark Average number of seconds to run all queries: 0.695 seconds Minimum number of seconds to run all queries: 0.627 seconds Maximum number of seconds to run all queries: 1.442 seconds Number of clients running queries: 50 Average number of queries per client: 0ارجع إلى نافذة طرفية MySQL. يمكننا أن نرى أنّ mysqlslap قد حذف قاعدة البيانات المؤقّتة الخاصّة به، طبّق: show databases;الخرج: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.00 sec)حالة استخدام: اختبار الأداء مع استعلامات مخصصةاستعلامات SQL المُنشَئة تلقائيًا جيّدة إذا كنت تريد تقييم موارد الخادوم الفيزيائية. هيَ مفيدة عندما تريد معرفة درجة الحِمل التي يمكن للنظام أن يتحمّلها. عندما تريد التحقق من تطبيقٍ يعتمد على قاعدة بيانات، فإنّك ستودّ اختبار استعلاماتٍ حقيقية على بياناتٍ حقيقية. يمكن لهذه الاستعلامات أن تأتي من خادوم الويب الخاصّ بك أو من خادوم التطبيق الذي تشغّله. الآن، سنفترض أنّك تعرف الاستعلامات المحددة التي تريد اختبارها. في القسم التالي، سنريك طريقةً لمعرفة عمليات الاستعلام التي يتم تنفيذها على خادومك. يمكنك جعل mysqlslap ينفّذ عملية استعلام معيّنة عبر الخيار query--. لا يمكن لجُمل الـSQL أن تحتوي على فواصل الأسطر (أكثر من سطر) ضمنها، ويجب فصلها بواسطة فاصلة منقوطة (;). يجب أيضًا إغلاق الاستعلامات بعلامتيّ تنصيص. في الشفرة التالية، سنقوم بتشغيل عملية استعلام بسيطة عن الجدول deptemp. يحوي جدول "deptemp" أكثر من ثلاثمئة ألف سجل بداخله. لاحظ كيف قمنا بتحديد قاعدة البيانات employees مع الخيار create-schema--: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=50 --iterations=10 --create-schema=employees --query="SELECT * FROM dept_emp;" --verboseسيستغرق هذا بعض الوقت ليكتمل. بعدها، يجب أن تتلقّى تقريرًا عن اختبار الأداء كالتالي بعد دقيقة أو اثنتين: Benchmark Average number of seconds to run all queries: 18.486 seconds Minimum number of seconds to run all queries: 15.590 seconds Maximum number of seconds to run all queries: 28.381 seconds Number of clients running queries: 50 Average number of queries per client: 1(ملاحظة: إذا استغرقت العملية حوالي 10 دقائق أو لم ترجع أيّ خرج، فيجب عليك المحاولة مجددًا مع عددٍ أقل للخيار concurrency-- و/أو iterations--, أو محاولة تطبيقها على خادوم أقوى). بعدها، سنستخدم أكثر من جملة SQL مع الخيار query--. في المثال التالي، نقوم بإنهاء كلّ جملة بفاصلة منقوطة. سيعرف mysqlslap أننا نستخدم عددًا من أوامر SQL المنفصلة بسبب استخدامنا للخيارdelimiter--: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=20 --iterations=10 --create-schema=employees --query="SELECT * FROM employees;SELECT * FROM titles;SELECT * FROM dept_emp;SELECT * FROM dept_manager;SELECT * FROM departments;" --delimiter=";" --verboseيستخدم هذا الاختبار نفس عدد الاتصالات ونفس عدد مرّات التكرار، إلّا أنّ الأداء كان أبطئ بشكلٍ ملحوظ بسبب استخدام أكثر من جملة SELECT واحدة (متوسّط 23.8 ثانية مقابل 18.486 ثانية). Benchmark Average number of seconds to run all queries: 23.800 seconds Minimum number of seconds to run all queries: 22.751 seconds Maximum number of seconds to run all queries: 26.788 seconds Number of clients running queries: 20 Average number of queries per client: 5يمكن لجُمل SQL التي يتم استخدامها في بيئة إنتاجية أن تكون معقّدة. إضافة جملة SQL معقّدة إلى سكربت هو أسهل من وضعها للاختبارات، لذا، يمكننا أن نطلب من mysqlslap أن يقوم بقراءة الاستعلامات من ملفّ سكربت. للقيام بهذا، فلنقم بإنشاء ملفّ سكربت من أوامر SQL. يمكننا استخدام الشفرة البرمجية أدناه لإنشاء الملفّ: sudo echo "SELECT * FROM employees;SELECT * FROM titles;SELECT * FROM dept_emp;SELECT * FROM dept_manager;SELECT * FROM departments;" > ~/select_query.sql sudo cp ~/select_query.sql /mysqlslap_tutorial/يحوي ملفّ select_query.sql جميع عبارات SELECT الآن. بما أنّ السكربت يحوي أكثر من عملية استعلام واحدة، فيمكننا استخدام مفهومٍ جديد في الاختبار. يمكن لـmysqlslap أن يقوم بتوزيع عمليات الاستعلام. يمكننا القيام بهذا عبر تحديد عدد الاستعلامات التي يجب على كلّ جهازٍ عميل متّصل أن ينفذّها. يسمح mysqlslap بفعل هذا عبر استخدام الخيار number-of-queries--. لذا، إذا كان لدينا 50 اتصال و1000 عمليّة استعلام يجب تنفيذها، فإنّ كلّ جهاز عميل متّصل سينفّذ حوالي 20 عملية استعلام تقريبًا. أخيرًا، يمكننا أيضًا استخدام الخيار debug-info--، والذي سيظهر لنا حسبة تقريبية للموارد المستعملة. في الشفرة البرمجية التالية، نطلب من mysqlslap أن يستخدم ملفّ السكربت الذي أنشأناه للتوّ. إننا نقوم أيضًا بتحديد المُعامِل number-of-queries. سيتم تكرار العمليّة مرّتين كما أننا نريد معلومات التنقيح (debug) ضمن الخرج: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=20 --number-of-queries=1000 --create-schema=employees --query="/mysqlslap_tutorial/select_query.sql" --delimiter=";" --verbose --iterations=2 --debug-infoبعد أن يكتمل هذا الأمر، يجب أن نرى بعض النتائج المثيرة للاهتمام: Benchmark Average number of seconds to run all queries: 217.151 seconds Minimum number of seconds to run all queries: 213.368 seconds Maximum number of seconds to run all queries: 220.934 seconds Number of clients running queries: 20 Average number of queries per client: 50 User time 58.16, System time 18.31 Maximum resident set size 909008, Integral resident set size 0 Non-physical pagefaults 2353672, Physical pagefaults 0, Swaps 0 Blocks in 0 out 0, Messages in 0 out 0, Signals 0 Voluntary context switches 102785, Involuntary context switches 43هنا يكون متوسّط عدد الثواني اللازم لتنفيذ جميع عمليات الاستعلام في MySQL هو 217 ثانية، حوالي 4 دقائق. صحيحٌ أنّ هذا الرقم له علاقة بحجم الذاكرة العشوائية ونوع المعالج المُستخدم مع آلتنا الوهمية، إلّا أنّه كان كبيرًا أيضًا بسبب عدد الاستعلامات الكبير الذي كان كلّ جهاز عميل متصل يكرره مرّتين. يمكننا أن نرى وجود عددٍ كبير من أخطاء الصفحات غير العتادية (البرمجية). تحصل أخطاء الصفحات (page faults) عندما لا يمكن العثور على البيانات في الذاكرة ويتوجّب على النظام أن يبحث عنها على قرص الـSwap. يظهر الخرج أيضًا بعض المعلومات المتعلّقة بالمعالج المركزي. في حالتنا، فإننا نرى عدد كبيرًا من تبديلات السياق كذلك. حالة استخدام: سيناريو اختبار أداء عملي مع التقاط مباشر للاستعلاماتإلى الآن في أمثلتنا، كنّا نقوم بتطبيق عمليات الاستعلام مع قاعدة بيانات "employees" الخاصّة بنا، وهو ما قد لا يكون شيئًا يريدك مُدراء قواعد البيانات أن تفعله، وهناك سببٌ وجيهٌ لذلك. لا تريد أن تقوم بإضافة حِمل إضافي إلى قاعدة بياناتك الإنتاجية ولا تريد أن تقوم بتفيذ استعلامات اختبارية يمكنها أن تقوم بحذف، تحديث أو إدراج البيانات إلى جداول قاعدة البيانات الإنتاجية الخاصّة بك. سنريك كيفيّة عمل نسخة احتياطية من قاعدة بيانات إنتاجية وكيفيّة نسخها إلى بيئة تجريبية، في هذا المثال وعلى نفس الخادوم، ولكنّك طبعًا قد تودّ نسخها إلى خادومٍ منفصل بنفس قدرات العتاد. والأكثر أهميّة من ذلك، سنريك كيف تقوم بتسجيل الاستعلامات بشكلٍ حيّ أو مباشر (live) من قاعدة بيانات إنتاجية بالإضافة إلى كيفيّة إضافة الاستعلامات إلى سكربتٍ اختباري. في المجمل، ستحصل على الاستعلامات من بيئة عمل إنتاجية، ولكنّك ستقوم بتنفيذ الاختبارات على قاعدة البيانات التجريبية. الخطوات العامّة هي كالتالي، ويمكنك استخدامها لأيّ اختبار mysqlslap: انسخ قاعدة البيانات الإنتاجية إلى بيئة اختبارية.قم بإعداد MySQL لتسجيل والتقاط جميع طلبات الاتصال والاستعلام على قاعدة البيانات الإنتاجية.قم بمحاكاة حالة الاستخدام التي تحاول اختبارها. كمثال، إذا كنتَ تدير موقع تسوّق، يجب أن تشتري شيئًا لتقوم بتفعيل جميع عمليات الاستعلام الأساسية ضمن تطبيقك.قم بتعطيل تسجيل الاستعلامات.انظر إلى سجل الاستعلامات وقم بعمل قائمة بالاستعلامات التي تريد اختبارها.أنشئ ملفًّا اختباريًا لكلّ عملية استعلام تريد اختبارها.نفّذ الاختبارات.استخدم الخرج لتحسين أداء قاعدة البيانات الخاصّة بك.للبدء، قم بإنشاء نسخة احتياطية من قاعدة البيانات "employees". سنقوم بإنشاء مسارٍ منفصل لهذه النسخة الاحتياطية: sudo mkdir /mysqlslap_tutorial/mysqlbackup cd /mysqlslap_tutorial/mysqlbackupأنشئ النسخة الاحتياطية وانقلها إلى المسار الجديد: sudo mysqldump --user sysadmin --password --host localhost employees > ~/employees_backup.sql sudo cp ~/employees_backup.sql /mysqlslap_tutorial/mysqlbackup/اذهب إلى خادوم MySQL التجريبي الخاصّ بك، وأنشئ قاعدة البيانات "employees_backup": CREATE DATABASE employees_backup;في هذه النقطة، إذا كنتَ تستخدم خادومًا منفصلًا للاختبار، فيجب أن تنقل ملفّ employeesbackup.sql إليه، ومن جلسة الطرفيّة الرئيسية، استورد بيانات النسخة الاحتياطية إلى قاعدة البيانات employeesbackup: sudo mysql -u sysadmin -p employees_backup < /mysqlslap_tutorial/mysqlbackup/employees_backup.sqlعلى خادوم قاعدة بيانات MySQL الإنتاجية الخاصّ بك، فعّل سجل استعلامات MySQL العام وقم بتوفير اسم ملفٍّ خاصٍّ به. يقوم سجل الاستعلامات العام بالتقاط الاتصالات، الاتصالات المنقطعة وسجل الاستعلامات لقاعدة بيانات MySQL: SET GLOBAL general_log=1, general_log_file='capture_queries.log';الآن، شغّل الاستعلامات التي تريد اختبارها على خادوم MySQL الإنتاجي. في هذا المثال، سنقوم بتنفيذ عملية استعلام من سطر الأوامر. وعلى كلّ حال، قد تودّ إنشاء الاستعلامات من تطبيقك عوضًا عن تنفيذها بشكلٍ مباشر. إذا كنتَ تمتلك صفحة موقع تريد اختبار أدائها، فيجب عليك تنفيذ تلك العملية أو الوصول إلى تلك الصفحة الآن. كمثال، إذا كنتَ تدير موقع تسوّق إلكتروني، قد تودّ إكمال عملية الدفع الآن، والذي من شأنه أن يقوم بطلب جميع الاستعلامات المطلوبة على خادوم قاعدة البيانات. هذه هي عملية الاستعلام التي سنقوم بطلبها على خادوم MySQL الإنتاجي الخاصّ بنا. أولًا، قم باستخدام قاعدة البيانات الصحيحة: USE employees;والآن عملية الاستعلام: SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_date;الخرج المتوقّع: 489903 rows in set (4.33 sec)سنقوم بتعطيل التسجيل العام عندما تكتمل عملية الاستعلام: SET GLOBAL general_log=0;لاحظ أنّه في حال تركت التسجيل العام مفعّلًا، سيستمر إضافة الاستعلامات إلى السجل، والذي من شأنه جعل الاختبارات أصعب. لذا تأكّد أنّك قمت بتعطيل التسجيل مباشرةً بعد الإنتهاء من اختبارك. فلنتحقق من أنّ ملفّ السجل تمَّ إنشاؤه ضمن المسار var/lib/mysql/: sudo ls -l /var/lib/mysql/capt* -rw-rw----. 1 mysql mysql 861 Sep 24 15:09 /var/lib/mysql/capture_queries.logفلننسخ هذا الملفّ إلى مسار MySQL الاختباري الخاصّ بنا. إذا كنتَ تستخدم خادومًا منفصلًا للاختبار، فقم بنسخه إلى ذلك الخادوم: sudo cp /var/lib/mysql/capture_queries.log /mysqlslap_tutorial/يجب أن يكون هناك بعض البيانات داخل ملفّ السجل هذا. في مثالنا، يجب أن تكون الاستعلامات التي نريدها بالقرب من نهاية الملفّ. تحقق من آخر جزء من الملفّ عبر الأمر: sudo tail /mysqlslap_tutorial/capture_queries.logالخرج المتوقّع: 6294 Query show databases 6294 Query show tables 6294 Field List departments 6294 Field List dept_emp 6294 Field List dept_manager 6294 Field List employees 6294 Field List salaries 6294 Field List titles 140930 15:34:52 6294 Query SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_date 140930 15:35:06 6294 Query SET GLOBAL general_log=0يظهر هذا السجل أوامر SQL والتوقيت الزمني الخاصّ بها. جملة SQL SELECT الموجودة بالقرب من نهاية الملفّ هي الجزء الذي نحن مهتمّون به. يجب أن يكون بالضبط هو الأمر الذي نقوم بتنفيذه على خادوم قاعدة البيانات الإنتاجية، حيث أننا قمنا من هناك بالتقاطه. في مثالنا هذا، كنّا نعرف عملية الاستعلام بالفعل، ولكن، في بيئة عمل إنتاجية، يمكن أن تكون هذه الطريقة نافعة جدًا لمعرفة الاستعلامات التي ربّما لا تعرف بالضرورة أنّه يتم تشغيلها على خادومك. لاحظ أنّه في حال قمت بطلب استعلامات مختلفة أثناء عملية التسجيل (logging)، فإنّ هذا الملفّ سيبدو مختلفًا تمامًا. في سيناريو حقيقي، يمكن أن يتمّ ملئ هذا الملفّ بالمئات من المُدخَلات القادمة من مختلف الاتصالات. هدفك هو العثور على الاستعلام أو الاستعلامات التي تسبب هذا الحِمل. يمكنك أن تبدأ عبر إنشاء قائمة بكلّ سطر يتضمّن الكلمة "Query". بعدها، ستمتلك قائمةً دقيقة بالاستعلامات التي تمّ تنفيذها على قاعدة البيانات الخاصّة بك أثناء الاختبار. قم بنسخ كلّ استعلام تريد اختباره إلى ملفٍّ ينتهي بالامتداد sql. كمثال: sudo vi /mysqlslap_tutorial/capture_queries.sqlيجب أن تكون المحتويات هي استعلامات MySQL التي تريد اختبارها، دون استخدام أيّ سطور إضافية (استخدم سطر واحد فقط) ودون فاصلة منقوطة بالنهاية: SELECT e.first_name, e.last_name, d.dept_name, t.title, t.from_date, t.to_date FROM employees e INNER JOIN dept_emp de ON e.emp_no=de.emp_no INNER JOIN departments d ON de.dept_no=d.dept_no INNER JOIN titles t ON e.emp_no=t.emp_no ORDER BY e.first_name, e.last_name, d.dept_name, t.from_dateبعدها، تأكّد أنّ نتائج الاستعلامات لم يتم تخزينها في ذاكرة الخبيئة (cache). ارجع إلى جلسة MySQL الخاصّة بالخادوم الاختباري وطبّق الأمر التالي: RESET QUERY CACHE;الآن، صار الوقت المناسب لتشغيل أداة mysqlslap مع ملفّ السكربت. تأكّد أنّك تستخدم اسم ملفّ السكربت الصحيح مع المُعامِل query--. سنستخدم فقط 10 اتصالات افتراضية وسنكرر العمليّة مرّتين فقط. قم بتشغيل الأمر التالي من خادومك الاختباري: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=10 --iterations=2 --create-schema=employees_backup --query="/mysqlslap_tutorial/capture_queries.sql" --verboseيجب أن يبدو خرج اختبار الأداء شيئًا كالتالي: Benchmark Average number of seconds to run all queries: 68.692 seconds Minimum number of seconds to run all queries: 59.301 seconds Maximum number of seconds to run all queries: 78.084 seconds Number of clients running queries: 10 Average number of queries per client: 1إذًا، كيف يمكننا الآن تحسين هذا الأداء؟ ستحتاج معرفةً جيّدة باستعلامات MySQL لتقييم ما تفعله عمليات الاستعلام. بالنظر مجددًا إلى الاستعلامات، يمكننا أن نرى أنّه تقوم بالعديد من عمليات الدمج على امتداد أكثر من جدول، تقوم الاستعلامات بإظهار تواريخ عمل الموظّف وأثناء القيام بذلك، تقوم بدمج أكثر من جدول عبر الحقل empno، كما أنّها تقوم باستخدام الحقل deptno للدمج، ولكن بما أنّه هناك أقسام سجلات قليلة فقط، فسنقوم بتجاهل هذا. بما أنّه هناك العديد من مُدخَلات empno في قاعدة البيانات، فمن المنطقي افتراضي أنّ إنشاء الفهارس في حقل empno يمكن أن يحسّن من أداء عمليات الاستعلام. مع القليل من التمرّن، بمجرّد أن تجد الاستعلامات التي تسبب ضغطًا على خادوم البيانات (وهو القسم الذي سيساعدك mysqlslap فيه!)، ستكون قادرًا على تقييم عمليات الاستعلام المتوفّرة بناءً على معرفتك بـMySQL وقاعدة بياناتك. بعدها، يمكنك محاولة تحسين قاعدة بياناتك أو الاستعلامات التي يتم تنفيذها عليها. في حالتنا، فلنضف الفهارس التي ذكرناه بالأعلى، سنقوم بإنشاء 3 فهارس فارغة لـempno. سيتم إنشاء فهرس واحد في حقل empno في جدول employees، وسيتم إنشاء فهرس آخر في حقل empno بالجدول deptemp، وسيتم إنشاء الأخير في حقل emp_no في جدول titles. فلنذهب إلى جلسة MySQL الاختبارية الخاصّة بنا ونطبّق الأوامر التالية: USE employees_backup; CREATE INDEX employees_empno ON employees(emp_no); CREATE INDEX dept_emp_empno ON dept_emp(emp_no); CREATE INDEX titles_empno ON titles(emp_no);بالعودة إلى نافذة الطرفية الرئيسية على خادومنا الاختباري، إذا قمنا بتشغيل mysqlslap بنفس المُعاملات، فسنرى اختلافًا في نتائج اختبار الأداء: sudo mysqlslap --user=sysadmin --password --host=localhost --concurrency=10 --iterations=2 --create-schema=employees_backup --query="/mysqlslap_tutorial/capture_queries.sql" --verbose Benchmark Average number of seconds to run all queries: 55.869 seconds Minimum number of seconds to run all queries: 55.706 seconds Maximum number of seconds to run all queries: 56.033 seconds Number of clients running queries: 10 Average number of queries per client: 1يمكن أن نرى وجود تحسّن فوري في متوسّط، أدنى وأقصى وقت لتنفيذ عمليات الاستعلام. عوضًا عن متوسّط 68 ثانية، يتم تنفيذ الاستعلامات الآن بغضون 55 ثانية. هذا تحسّن بحوالي 13 ثانية لنفس الاستعلامات التي تمّ تنفيذها. بما أنّ هذا التغيير في قاعدة البيانات أعادة نتيجةً جيّدة في البيئة الاختبارية، فإنّه يمكنك الآن أخذه بعين الاعتبار لتنفيذه على خادوم قاعدة البيانات الإنتاجية الخاصّة بك، ولكن لا تنسى أنّ تغييرات قاعدة البيانات لها دومًا إيجابيات وسلبيات عليك المفاضلة بينها. يمكنك إعادة عملية اختبار الأوامر والتحسينات مع جميع الاستعلامات التي جمعتها من ملفّ السجل الخاصّ بك. استكشاف الأخطاء وإصلاحها: mysqlslap لا يظهر الخرجإذا قمت بتنفيذ أمر اختبار ولم يرجع لك خرجًا، فهذا مؤشّرٌ جيّد إلى أنّ موارد خادومك قد تكون امتلأت بالفعل. قد تتضمّن أعراض هذه المشكلة نقصًا في خرج Benchmark، أو رسالة خطأ مثل: mysqlslap: Error when storing result: 2013 Lost connection to MySQL server during queryربّما قد تودّ إعادة الاختبار مجددًا مع عددٍ أقل للمُعامِل concurrency-- أو iterations--، أو يمكنك محاولة ترقية بيئة خادومك الاختباري لإصلاح المشكلة. يمكن أن يكون هذا طريقةً جيّدة لمعرفة حدود سعة خادوم قاعدة البيانات الخاصّ بك. الخاتمةmysqlslap هو أداة بسيطة وخفيفة يمكنها أن تندمج بسهولة مع محرّك قاعدة بيانات MySQL. وهي متوفّر لجميع إصدارات MySQL بدءًا من الإصدار 5.1.4. في هذا الدرس، رأينا كيفيّة استخدام mysqlslap مع خياراته المتعددة وجرّبنا الأمر مع قاعدة بيانات اختبارية كعيّنة. يمكنك تحميل قواعد بيانات عينية أخرى للاختبار من موقع MySQL والتمرّن عليها أيضًا. كما ذكرنا من قبل: رجاءًا لا تقم بتنفيذ الاختبارات على خادوم قاعدة بيانات إنتاجية. آخر حالة استخدام في درسنا هذا تعلّقت بعملية استعلام واحدة فقط. صحيحٌ أننا قمنا بتحسين أداء عملية الاستعلام تلك عبر إضافة فهارس إضافية إلى جميع الجداول الثلاث، إلّا أنّ العملية قد لا تكون بتلك البساطة في الحياة الحقيقية. إضافة المزيد من الفهارس قد يبطئ - في بعض الأحيان - أداء النظام وغالبًا مع يحتاج مُدراء قواعد البيانات إلى قياس إيجابيات إضافتها على حساب التغيير في الأداء الذي سيحصل. سيناريوهات الاختبار في الحياة الحقيقية أكثر تعقيدًا، ولكن هذا قد يعطيك الأدوات اللازمة للبدء في اختبار وتحسين أداء قاعدة البيانات الخاصّة بك. ترجمة -وبتصرف- للمقال: How To Measure MySQL Query Performance with mysqlslap لصاحبه: Sadequl Hussain.

تأتي MySQL مع أداة تشخيص (diagnostic) تدعى mysqlslap، تمّ توفير هذه الأداة منذ الإصدار 5.1.4 من MySQL، وهي عبارة عن أداة قياس للأداء (benchmarking) يمكنها أن تساعد مدراء قواعد البيانات والمطورّين على أن يختبروا أداء خواديم قواعد البيانات الخاصّة بهم بسهولة. يمكن لـmysqlslap أن تحاكي عددًا كبيرًا من أجهزة العملاء التي تتصل بخادوم قاعدة البيانات بنفس الوقت. مُعامِلات اختبار الحمل (load testing parameters) قابلة للضبط بشكلٍ كلّي ويمكن استخدام نتائج الاختبارات المختلفة بهدف تحسين تصميم قواعد البيانات أو استهلاك موارد العتاد. في هذا الدرس، سنشرح كيفيّة تثبيت وإعداد mysqlslap بهدف إجراء اختبار الحِمْل (load test) على قاعدة بيانات MySQL باستخدام بعض عمليات الاستعلام الأساسية ولنرى كيف يمكن لاختبارات الأداء أن تساعدنا على تحسين هذه الاستعلامات لاحقًا. بعد القليل من التوضيحات المبدئية، سنقوم بعمل سيناريو تجريبي مشابه للتجربة الحقيقية حيث سنقوم بإنشاء نسخة من قاعدة بيانات موجودة حاليًا لنقوم بالاختبارات عليها، وسنجمع الاستعلامات من ملفّات السجل ونبدأ بالاختبار بواسطة سكربت. ما هو حجم الخادوم الذي يجب أن أستخدمه؟إذا كنتَ مهتمًا باختبار أداء خادوم قاعدة بياناتٍ معيّن، فيجب عليك أن تقوم بتشغيل اختبارات الأداء على خادوم بنفس المواصفات وبنسخة مطابقة تمامًا لقاعدة البيانات التي قمت بتثبيتها على خادومك الرئيسي. إذا كنتَ تريد المضيّ قدمًا بهذا الدرس بهدف التعلّم وتنفيذ كلّ أمر موجودٍ فيه، فإننا ننصحك بخادوم يمتلك 2 جيجابت من الذاكرة العشوائية (RAM) على الأقل. وبما أنّ الأوامر الموجودة في هذا الدرس تهدف إلى إرهاق الخادوم بالطلبات الكثيرة بهدف قياس أدائه، فإنّك قد تلاحظ أنّ الخواديم الأصغر حجمًا قد ينقطع الاتصال بها بسبب ذلك الحِمل. تمّ إنتاج الخرج الناتج في هذا الدرس بواسطة عدّة طرق بهدف تحسين الاستفادة من الأمثلة الموجودة هنا. الخطوة الأولى: تثبيت خادوم MySQL على نظام اختباريسنبدأ عبر تثبيت نسخة جديدة من خادوم MySQL المطوّر بواسطة المجتمع أو MySQL Community Server على نظام تشغيل اختباري. يجب ألّا تقوم بتشغيل أيّ أوامر أو استعلامات تجدها في هذا الدرس على خادوم قاعدة بيانات ضمن بيئة إنتاجية بتاتًا. تهدف هذه الاختبارات إلى الضغط على الخادوم التجريبي وقد تسبب تعليقا أو تعطلا لخادوم يعمل ضمن بيئة عمل إنتاجية. تمّ تنفيذ هذا الدرس ضمن بيئة العمل التالية: CentOS 7.أوامر تمّ تنفيذها بواسطة مستخدم جذر.2 جيجابت من الذاكرة العشوائية (RAM); لا تنسى أنّ الاختبارات التي سيتم ذكرها هنا تمّ إنتاجها بهدف التعليم ولا تعني بأيّ شكل من الأشكال أنّها نتيجة اختبارات رسمية صادرة عنّا.أولًا، سنقوم بإنشاء مسار ليحوي جميع الملفّات المتعلّقة بهذا الدرس. سيساعدنا هذا على إبقاء المكان نظيفًا. قم بالذهاب إلى هذا المسار: sudo mkdir /mysqlslap_tutorial cd /mysqlslap_tutorialبعدها، سنقوم بتحميل مستودع yum الخاصّ بنسخة المجتمع من خادوم MySQL. المستودع الذي سنحمّله هو مخصص بشكل اساسي لـRed Hat Enterprise Linux 7 إلّا أنّه يعمل بالطبع مع CentOS 7 كذلك: sudo wget http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpmالآن يمكننا تنفيذ rpm -Uvh لتثبيت هذا المستودع: sudo rpm -Uvh mysql-community-release-el7-5.noarch.rpmتحقق أنّه قد تمّ تثبيت المستودعات عبر تفحّص محتويات المجلّد etc/yum.repos.d/: sudo ls -l /etc/yum.repos.dيجب أن يبدو الخرج كالتالي: -rw-r--r--. 1 root root 1612 Jul 4 21:00 CentOS-Base.repo -rw-r--r--. 1 root root 640 Jul 4 21:00 CentOS-Debuginfo.repo -rw-r--r--. 1 root root 1331 Jul 4 21:00 CentOS-Sources.repo -rw-r--r--. 1 root root 156 Jul 4 21:00 CentOS-Vault.repo -rw-r--r--. 1 root root 1209 Jan 29 2014 mysql-community.repo -rw-r--r--. 1 root root 1060 Jan 29 2014 mysql-community-source.repoوفي حالتنا، فإنّ MySQL 5.6 Community Server هو ما نريده: mysql-connectors-community/x86_64 MySQL Connectors Community 10 mysql-tools-community/x86_64 MySQL Tools Community 6 mysql56-community/x86_64 MySQL 5.6 Community Server 64والآن قم بتثبيت خادوم MySQL: sudo yum install mysql-community-serverبمجرّد اكتمال العمليّة، قم بالتحقق من أنّه تمّ تثبيت المكوّنات فعلًا: sudo yum list installed | grep mysqlيجب أن تبدو القائمة كالتالي: mysql-community-client.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-common.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-libs.x86_64 5.6.20-4.el7 @mysql56-community mysql-community-release.noarch el7-5 installed mysql-community-server.x86_64 5.6.20-4.el7 @mysql56-communityبعدها، يجب أن نتأكّد أن عفريت MySQL أو MySQL Daemon يعمل بالفعل وأنّه سيبدأ تلقائيًا عند تشغيل الخادوم. يمكنك القيام بذلك عبر الأمر التالي: sudo systemctl status mysqld.serviceيجب أن ترى خرجًا كهذا: mysqld.service - MySQL Community Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled) Active: inactive (dead)ابدأ الخدمة عبر: sudo systemctl start mysqld.serviceولجعلها تبدأ عند بدء تشغيل الخادوم: sudo systemctl enable mysqld.serviceوأخيرًا يجب علينا تأمين خادوم MySQL: sudo mysql_secure_installationسيظهر لك هذا مجموعة من الأسئلة. سنريك بالأسفل جميع الأسئلة مع أجوبتها التي يجب أن تختارها. في البداية لن يكون هناك كلمة مرور للمستخدم root الخاصّ بـMySQL، لذا، قم فقط بالضغط على زرّ Enter. أثناء الأسئلة، يجب أن تقوم بكتابة كلمة مرور جديدة وآمنة للمستخدم الجذر. يجب أن تقوم بكتابة y لإزالة حساب المستخدم المجهول من خادوم قاعدة البيانات، ولتعطيل السماح بالولوج البعيد للمستخدم الجذر وإعادة تحميل جدول الصلاحيات وغيرها: ... Enter current password for root (enter for none): OK, successfully used password, moving on... ... Set root password? [Y/n] y New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! ... Remove anonymous users? [Y/n] y ... Success! ... Disallow root login remotely? [Y/n] y ... Success! Remove test database and access to it? [Y/n] y - Dropping test database... ... Success! ... Reload privilege tables now? [Y/n] y ... Success! Cleaning up...يمكننا الآن أن نتّصل بقاعدة البيانات لنتأكّد من أنّ كلّ شيءٍ يعمل بشكلٍ صحيح: sudo mysql -h localhost -u root -pقم بإدخال كلمة مرور MySQL التي كتبتها للتوّ الآن. يجب أن ترى الخرج التالي: Enter password: Welcome to the MySQL monitor.... mysql>في طرفيّة <mysql قم بإدخال الأمر الذي سيظهر لك جميع قواعد البيانات: show databases;يجب أن ترى خرجًا كالتالي: +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | +--------------------+ 3 rows in set (0.00 sec)وأخيرًا، دعنا ننشئ مستخدمًا يدعى "sysadmin"، سيتم استخدام هذا الحساب للولوج إلى MySQL بدلًا من المستخدم الجذر. كن متأكّدًا من استبدال mypassword بكلمة المرور التي تريدها لهذا المستخدم. سنقوم أيضًا بمنح جميع الصلاحيات اللازمة لهذا المستخدم. في طرفيّة MySQL، قم بإدخال التالي: create user sysadmin identified by 'mypassword';الخرج: Query OK, 0 rows affected (0.00 sec)قم بإعطاء جميع الصلاحيات للمستخدم: grant all on *.* to sysadmin;الخرج: Query OK, 0 rows affected (0.01 sec)والآن فلنعد إلى طرفيّة نظام التشغيل العادية: quit;الخرج: Byeالخطوة الثانية: تثبيت قاعدة بيانات تجريبيةالآن، سنحتاج إلى تثبيت قاعدة بيانات تجريبية بهدف الاختبار. اسم قاعدة البيانات هذه هو "employees" وهي وهي متوفّرة بشكلٍ مجاني من على موقع MySQL، كما أنّه يمكن تحميل قاعدة البيانات من Launchpad. اخترنا قاعدة "employees" لأنّها تحتوي على مجموعة كبيرة من البيانات. رغم ذلك، فإنّ بنية قاعدة البيانات بسيطة بدرجة كافية، إنّها تحتوي على 6 جداول فقط، ولكن وفي داخلها، فهي تحتوي على سجلات 3 مليون موظّف (يمتلك جدول الرواتب لوحده حوالي 3 ملايين صفّ)، وسيساعدنا هذا على محاكاة حِمل بيئة عمل إنتاجية بشكل أفضل. أوّلًا، دعنا نتأكّد أننا في المسار mysqlslap_tutorial/ الخاصّ بنا: cd /mysqlslap_tutorialقم بتحميل آخر إصدار من قاعدة البيانات التجريبية: sudo wget https://launchpad.net/test-db/employees-db-1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2قم بتثبيت bzip2 لنتمكّن من استخراج الملفّ: sudo yum install bzip2والآن قم بفكّ الضغط عن أرشيف قاعدة البيانات، قد يأخذ هذا وقتًا: sudo bzip2 -dfv employees_db-full-1.0.6.tar.bz2 sudo tar -xf employees_db-full-1.0.6.tarسيتم فكّ ضغط المحتويات إلى مسار منفصل جديد يدعى "employees_db"، نحتاج أن نقوم بالذهاب إلى هذا المجلّد لنقوم بتشغيل الأمر الذي يقوم بتثبيت قاعدة البيانات هذه. تتضمّن المحتويات ملفّ README، سجل للتغييرات، حِزَم بيانات وملفّات استعلامات SQL مختلفة تشكّل جميعها بنية قاعدة البيانات: cd employees_db ls -lوهذا هو ما يجب أن تراه: -rw-r--r--. 1 501 games 752 Mar 30 2009 Changelog -rw-r--r--. 1 501 games 6460 Oct 9 2008 employees_partitioned2.sql -rw-r--r--. 1 501 games 7624 Feb 6 2009 employees_partitioned3.sql -rw-r--r--. 1 501 games 5660 Feb 6 2009 employees_partitioned.sql -rw-r--r--. 1 501 games 3861 Nov 28 2008 employees.sql -rw-r--r--. 1 501 games 241 Jul 30 2008 load_departments.dump -rw-r--r--. 1 501 games 13828291 Mar 30 2009 load_dept_emp.dump -rw-r--r--. 1 501 games 1043 Jul 30 2008 load_dept_manager.dump -rw-r--r--. 1 501 games 17422825 Jul 30 2008 load_employees.dump -rw-r--r--. 1 501 games 115848997 Jul 30 2008 load_salaries.dump -rw-r--r--. 1 501 games 21265449 Jul 30 2008 load_titles.dump -rw-r--r--. 1 501 games 3889 Mar 30 2009 objects.sql -rw-r--r--. 1 501 games 2211 Jul 30 2008 README -rw-r--r--. 1 501 games 4455 Mar 30 2009 test_employees_md5.sql -rw-r--r--. 1 501 games 4450 Mar 30 2009 test_employees_sha.sqlقم بتشغيل هذا الأمر للاتصال بـMySQL وتشغيل سكربت employees.sql، والذي سيقوم بإنشاء قاعدة البيانات وتحميل البيانات إليها: sudo mysql -h localhost -u sysadmin -p -t < employees.sqlالآن، يجب عليك إدخال كلمة المرور التي اخترتها للمستخدم "sysadmin" من قبل. يجب أن يكون خرج العملية شيئًا كهذا، قد تأخذ وقتًا (حوال الدقيقة) ليكتمل: +-----------------------------+ | INFO | +-----------------------------+ | CREATING DATABASE STRUCTURE | +-----------------------------+ +------------------------+ | INFO | +------------------------+ | storage engine: InnoDB | +------------------------+ +---------------------+ | INFO | +---------------------+ | LOADING departments | +---------------------+ +-------------------+ | INFO | +-------------------+ | LOADING employees | +-------------------+ +------------------+ | INFO | +------------------+ | LOADING dept_emp | +------------------+ +----------------------+ | INFO | +----------------------+ | LOADING dept_manager | +----------------------+ +----------------+ | INFO | +----------------+ | LOADING titles | +----------------+ +------------------+ | INFO | +------------------+ | LOADING salaries | +------------------+الآن، يمكنك الولوج إلى MySQL وتشغيل بعض الاستعلامات البدائية للتحقق من أنّ البيانات قد تمّ استيرادها بنجاح: sudo mysql -h localhost -u sysadmin -pقم بإدخال كلمة المرور الخاصّة بالمستخدم sysadmin. تحقق من قائمة قواعد البيانات لرؤية قاعدة البيانات employees الجديدة: show databases;الخرج: +--------------------+ | Database | +--------------------+ | information_schema | | employees | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.01 sec)استخدم قاعدة البيانات "employees" عبر الأمر: use employees;وللتحقق من الجداول الموجودة: show tables;الخرج: +---------------------+ | Tables_in_employees | +---------------------+ | departments | | dept_emp | | dept_manager | | employees | | salaries | | titles | +---------------------+ 6 rows in set (0.01 sec)إذا كنت تريد ذلك، فيمكنك التحقق من تفاصيل كلّ جدول من هذه الجداول. سنتحقق الآن من تفاصيل جدول titles فقط: describe titles;الخرج: +-----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+-------------+------+-----+---------+-------+ | emp_no | int(11) | NO | PRI | NULL | | | title | varchar(50) | NO | PRI | NULL | | | from_date | date | NO | PRI | NULL | | | to_date | date | YES | | NULL | | +-----------+-------------+------+-----+---------+-------+ 4 rows in set (0.01 sec)وللتحقق من رقم المُدخَلات: mysql> select count(*) from titles;+----------+ | count(*) | +----------+ | 443308 | +----------+ 1 row in set (0.14 sec)يمكنك التحقق من أيّ بيانات أخرى تريدها. بعد أن تنتهي، ارجع إلى طرفيّة نظام التشغيل الرئيسية عبر كتابة: quit;انتهى درسنا حول تثبيت mysqlslap وإعداده، اقرأ الدرس الآخر لمتابعة طريقة استخدامه للقيام بالاختبارات المطلوبة. ترجمة -وبتصرف- للمقال: How To Measure MySQL Query Performance with mysqlslap لصاحبه: Sadequl Hussain.