اختبار التزامن و/أو سلامة المعاملات في تطبيق ويب باستخدام JMeter

Question

أنا جديد إلى حد ما في العمل مع سلاسل رسائل متعددة في قاعدة بيانات (لقد أمضيت معظم حياتي المهنية في الواجهة الأمامية).

حاولت اليوم اختبار تطبيق PHP بسيط كتبته لتخزين القيم في قاعدة بيانات MySQL باستخدام جداول ISAM التي تحاكي المعاملات باستخدام Table Locking.

لقد كتبت للتو تدوينة حول الإجراء هنا:

اختبار مع JMeter

من نتائجي، يبدو أن تطبيق php البسيط الخاص بي يحافظ على سلامة المعاملات (كما يتضح من البيانات الموجودة في ملفات csv الخاصة بي وهي نفس البيانات التي قمت بإعادة استخراجها من قاعدة البيانات):

ملفات CSV:

الاستعلام عن البيانات لكلا المستخدمين بعد تشغيل اختبار JMeter:

هل أنا على حق في افتراضاتي أن سلامة بيانات المعاملات سليمة؟

كيف يمكنك اختبار التزامن؟

Answer 1

لماذا لا تستخدم InnoDB وتحصل على نفس التأثير بدون أقفال الطاولة اليدوية؟

وأيضاً ما الذي تحمي منه؟خذ بعين الاعتبار اثنين من المستخدمين (بيل وستيف):

1. سجل الأحمال 1234
2. سجل ستيف الأحمال 1234
3. يقوم ستيف بتغيير السجل إلى 1234 ويقدمه
4. ينتظر بيل قليلاً، ثم يقوم بتحديث السجل القديم 1234 ويقدمه.هذه التغييرات تضرب بيل.

لا يوفر قفل الجدول أي تكامل للبيانات أعلى من قفل جدول MyISAM الأصلي.سيقوم MyISAM بقفل ملفات الجدول أصلاً عند الحاجة لإيقاف تلف البيانات.

في الواقع، السبب وراء استخدام InnoDB عبر MyISAM هو أنه سيقوم بقفل الصفوف بدلاً من قفل الجدول.كما أنه يدعم المعاملات.لن تقوم التحديثات المتعددة لسجلات مختلفة بحظر بعضها البعض، كما سيتم حظر التحديثات المعقدة لسجلات متعددة حتى اكتمال المعاملة.

يجب أن تأخذ في الاعتبار احتمال حدوث تحديثين لنفس السجل في نفس الوقت لتطبيقك.إذا كان من المحتمل أن قفل الجدول/الصف لا يمنع التحديث الثاني، بل يؤجله فقط حتى يكتمل التحديث الأول.

يحرر

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