Etherpad-lite: تدهور الأداء في 1.8.0 والإصدارات الأحدث

نسخة seballot

لدينا تغطية اختبارية لهذه الآفاق. انظر اختبار الاستجابة الأمامية.

من السهل إدراك مشكلة إعادة التدفق عندما يكون هناك عدد كبير من العقد.
هل هذا؟ https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
علق عليه

يا فتى ، سأقوم بإلغاء التعليق والتأكد من أن لدينا تغطية اختبار عمل. نأمل أن يتمكنseballot من العثور على حل

شكراJohnMcLear!

بدون تعليق ، شكرًا لتقرير الأخطاء الشامل والمُعد جيدًا. سيتم رفعseballot مرة أخرى: +1:

لم يتم تلقي أي رد من

اهلا ياجماعة ! شكرًا على تقرير الخطأ الواضح هذا joassouza ، وآسف على الخطأ

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

seballot مجرد نتوء للأسبوع القادم للتأكد من أن لديك بعض الوقت في جدولك الزمني لإلقاء نظرة على هذا من فضلك :) شكرا!

مرحبا !

لا يمكنني التكاثر ، لقد صنعت وسادة بطول 6000 سطر ، وهي تعمل بشكل جيد

تم الاختبار على Debian 9 -> Chromium 73 و Firefox 68

لماذا تبدو أرقام الأسطر سيئة (يتم عرض الرقم 1 جيدًا ، ثم الرقم 2 كبير جدًا وغير محاذي)؟
هل يمكن أن تكون مشكلة في رمزك المحلي؟
ربما يكون تدهور الأداء فقط على Mac؟ هل يمكن لشخص آخر المحاولة من فضلك؟

لم يتم اختباره ولكن يمكنه رؤية فشل اختبار استجابة Firefox الذي اعتاد اجتيازه. جرّب اختبار استجابة Firefox مع عدم ضبط الجلد لمعرفة ما إذا كان قد نجح؟

اجتياز الاختبار بالنسبة لي على كل من Chrome و Firefox

نعم ، لقد مرت للتو أيضًا ، لذا أحتاج إلى التعمق أكثر ولكني أتساءل عما إذا كان يمر بالنسبة لنا لأننا على أجهزة كمبيوتر سريعة (ish) ومختبرات الصلصة ترمي بعض الفلاحين للتعامل مع المهمة؟

كما أنني أعاني من عدم وجود أي تأخير على ff على ubuntu

حسنًا ، تغيير amount إلى 1600000 (إنشاء 8k سطر) يجعل التأخر ملحوظًا بالنسبة لي.

حاول القيام بذلك seballot ، tests/frontend/specs/responsiveness.js line 26

لا يمكنني تأكيد ما إذا كان هذا خطأ جديدًا أم لا ، سيكون من المفيد التحقق من 1.7.9 أو أي شيء آخر والتأكد من أن السلوك مختلف بالفعل. يجب أن يكون هناك سبب لاختبار الاستجابة كان عند علامة 1k سطر.

من الجدير بالذكر أيضًا أن التجربة على Firefox 52 هي المشكلة ، FF الحديث يبدو جيدًا؟ يتعطل اختبار الاستجابة على FF 52 ولكنه لا بأس به في 80. في الواقع إنه يعطل المتصفح. - لذا أعتقد أن الاختبار في Firefox 52؟ أنا أختبر على SL الآن.

فشل اختبار الاستجابة على this.timeout ليس خطأ وظيفي. https://github.com/ether/etherpad-lite/pull/4257/files

فقط لإعطاء المزيد من السياق. تم إجراء الاختبارات على Chrome على MacOs. يمكننا إعادة إنتاج نفس الخطأ على أجهزة سريعة حقًا مثل i9 وذاكرة الوصول العشوائي بسعة 64 جيجابايت.
seballot هل يمكنك محاولة التعديل في بداية اللوحة؟
لقد جربت للتو على جهاز يعمل بنظام Windows باستخدام الكروم أيضًا ولدي نفس التأخير.
https://video.etherpad.com/p/example_long_pad

لقد كنت أختبر Firefox مثل أحمق ، سأختبر Chrome الآن.

حسنًا ، رائع ، نعم هذا سيء. لقد غيرت المبلغ إلى 800000 والتأخر فظيع.

أعتقد أن التأخير يزداد إذا قمت بالتحرير في بداية اللوحة. مثل ، في السطر الأول منه.

لست معتادًا على استخدام أدوات أداء Chrome ولكن هذا ما أراه عند محاولة تعديل لوحة response.js.

هل لاحظت أنني لا أحصل على كل وقت التخطيط مثلك؟

لقد جربت FF على جهاز يعمل بنظام Windows ولدي نفس التأخير. باستخدام هذه الوسادة

https://video.etherpad.com/p/example_long_pad
حول إعادة التدفق ، يعتمد ذلك على CSS المطبق ، والمتصفح ، وكود js الذي يطلقه ، .... لهذا السبب أجريت الاختبارات بدون أي مكون إضافي. يجب أن أتحقق من رمز اختبار الاستجابة لفهم سبب عدم إدراككم في تلك الاختبارات للتأخير.

مرحبا ! في الواقع مع 8K يبدأ التجميد. لكنني تحولت إلى 1.7.5 ومع لوحة 8k ، تجمدت كما هي (حتى أنني أقول إنها أسوأ!)

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

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

كنت أحاول إلقاء نظرة ، لكنني لا أعدك بأي شيء بسبب ذلك
1- لا يبدو مضحكا جدا :)
2- لا أشعر أنه خطأ فادح

JohnMcLear لقد حاولت إلقاء نظرة الآن ، لكنني لا أفهم ، كل تغيير ace2_inner.js (حتى حذف الملف بأكمله) لا يؤثر على المثيل المحلي الخاص بي ، فهو لا يزال يعمل بنفس الطريقة. ماذا ينقصني؟

يُطلب ace2_inner.js بدون إصدار atm ، لذلك لا يتغير عنوان URL الخاص بـ ace2_inner.js ويتم استخدام ذاكرة التخزين المؤقت للمتصفح. عند تعيين maxAge = 0 في settings.json و / أو تعطيل ذاكرة التخزين المؤقت للمتصفح ، يجب أن يخدم الملف الجديد دون إعادة التشغيل.

مرحبا @ webzwo0i ! شكرا لمساعدتك ! أتذكر أخيرًا أنني بحاجة إلى إبطال ذاكرة التخزين المؤقت لـ ace2_inner لأنه تم تحميله في iframe ...

(maxAge = 0 ليس لها تأثير بالمناسبة)

متأخر قليلا الآن ، سوف ننظر غدا!

إحدى الحيل هي استخدام علامة تبويب الشبكة المفتوحة لأنها تعطل التخزين المؤقت.

joassouza هل يمكنك تأكيد نتائج سيباستيانز؟

حسنًا! في الواقع لم يكن الأمر معقدًا للغاية ، بفضل joassouza الذي بذل كل العمل لإيجاد كل من المشكلة والحل

وأؤكد أن الخطأ لا علاقة له بالتغييرات الأخيرة في واجهة المستخدم ، فهو موجود منذ وقت طويل على ما أعتقد!

أعتقد أنه يمكن إغلاق هذا الآن مع الإصلاح رقم 4267
شكرا مرة أخرى seballot