اقتراحي هو تقييم منتجات الدردشة بهدف دمجها بسلاسة.
لا ينتمي Ephemera إلى Discourse.
3 إعجابات
ستحتاج إلى توخي الحذر الشديد هنا. ربما يكون من الأفضل تخصيص موضوع دردشة واحد في كل مرة وحذف المواضيع القديمة بانتظام، لأن كل موضوع دردشة مستمر يفرض عقوبة أداء شديدة على الخادم، وتزداد هذه العقوبة مع كل مشاهدة صفحة.
الأفضل هو دمج أداة دردشة فعلية، وذلك وفقًا لـ
3 إعجابات
أتفق بنسبة 100% مع هذا. أحيانًا تضيف هذه المواضيع قيمة للمجتمع، لكن ليس إلى الحد الذي يستدعي تغييرات في الكود برأيي.
3 إعجابات
هل يمكنك التوسع قليلاً في عقوبة الأداء هذه؟ هل هذا خاص بالمواضيع المغلقة والأرشيفية؟ إغلاق المواضيع عند 10 آلاف مقالة أمر مقبول، لكن حذفها سيكون أمرًا مختلفًا تمامًا.
مجتمعي يحب Discourse ويعتمد على المنتديات منذ أكثر من 15 عامًا. لن يستخدموا غرفة دردشة، وسيكون رد فعلهم سلبيًا جدًا تجاه حذف المواضيع القديمة. إذا كان هناك مشكلة أداء خطيرة ومتزايدة بسبب مجرد وجود هذه المواضيع، فسيكون عليّ إما تحويلها إلى صفحات ثابتة أو الانتقال إلى منصة أخرى.
أدرك أن مجتمعنا لا يتناسب تمامًا مع الطريقة التي تتخيلون بها استخدام Discourse، لكن هذا هو المجتمع المسؤول عنه، وهناك بعض التغييرات التي لا أستطيع إجبارهم على إجرائها. في الواقع، لم يكن مجتمعنا أقوى مما هو عليه الآن باستخدام Discourse. سأكره الاضطرار إلى الانتقال إلى منصة أخرى بينما الجميع سعيد جدًا بالإعداد الحالي لدينا.
8 إعجابات
يجب أن تكون المواضيع الضخمة مخفية إلى حد كبير — حتى لو كانت مغلقة و/أو مؤرشفة، فكلما زاد عدد المستخدمين الذين يزورون موضوعًا ضخمًا، زادت تدهور أداء الخادم. المثالي هو حذف المواضيع الضخمة بحيث يكون لديك موضوع ضخم واحد نشط فقط في أي وقت؟ هذه هي توصيتي. فكلما زاد عدد المواضيع الضخمة، زادت المخاطر التي تتعرض لها.
إذا أمكنك ضخ مبلغ كبير من المال لحل المشكلة، فيمكنك زيادة سعة الخادم بشكل كبير ودعم المزيد من المواضيع الضخمة — لكن ذلك سيظل يؤثر على الأداء المتوسط لجميع المواضيع.
4 إعجابات
حتى عندما يكون الموضوع مغلقًا، فإنه يولد بيانات وحركة مرور وعبئًا.
تذكر أن موضع قراءة كل مستخدم يُسجَّل بالنسبة لكل موضوع. يمكن إعجاب كل منشور، ولا تزال التفاعلات مع المواضيع الضخمة ممكنة حتى بعد إغلاقها، ناهيك عن كمية الضوضاء التي قد تُسببها في نتائج بحثك.
إعجابَين (2)
هذا لا يفسّر بعدُ لماذا تُسبّب المواضيع الضخمة تحديدًا مشاكل. لماذا موضوع واحد يحتوي على 10,000 منشور أسوأ من عشرة مواضيع تحتوي كلٌّ منها على 1,000 منشور؟ في الحالة الثانية، يكون العدد الإجمالي للمنشورات القابلة للإعجاب أو البحث عنه هو نفسه، لكن هناك عشرة أضعاف مواقع القراءة والمواضيع التي يجب البحث فيها. بناءً على شرحك وحده، سأستنتج أن وجود عدد أكبر من المواضيع الأصغر حجمًا هو الأسوأ. إذن لا بد أن هناك عوامل أخرى تدخل في الأمر.
4 إعجابات
لأنك تقوم بتحميل موضوع واحد فقط في كل مرة. يمكنك تحميل عشرة مواضيع تحتوي كل منها على 1,000 عنصر خفيف واحد تلو الآخر دون مشاكل، لكن تحميل 10,000 عنصر دفعة واحدة أصعب بكثير.
إعجابَين (2)
لكنني أشعر بالفضول بشأن التفاصيل الدقيقة. فعدد معين فقط من المنشورات يتم تحميله افتراضيًا قبل التمرير، مما يعني بوضوح أن الأمر لا يعود إلى عدد المنشورات الظاهرة. فهل يعود ذلك إلى الخط الزمني؟ أم إلى ملخص الموضوع؟ أم بشكل عام إلى خوارزميات خطية أو تفوق الخطية تعتمد على العدد الإجمالي للمنشورات في الموضوع؟
لا يهمني كثيرًا موضوعات “الميجا”، اعتمادًا على ما تعتبره “ميجا”. ففي القسم الأكثر زيارة في المجتمع الذي أستخدمه، يحتوي الموضوع ذو المنشورات الأكثر على حوالي 3.6 ألف منشور، بينما يحتل الموضوع العاشر من حيث العدد 600 منشور فقط. أما الموضوع الخامس والعشرون فيحتوي على 300 منشور فقط. فأنا مهتم أكثر من الناحية التقنية في هذه المرحلة.
6 إعجابات
إليك استعلام مستكشف البيانات الذي كتبته لمحاولة الإجابة على سؤالك. يمكنك تجربته مع مواضيع وإزاحات مختلفة.
-- [params]
-- int :topic_id = 107216
-- int :offset = 10000
SELECT "posts"."id" FROM "posts"
WHERE ("posts"."deleted_at" IS NULL)
AND "posts"."topic_id" = :topic_id
AND "posts"."post_type" IN (1,2,3) ORDER BY "posts"."sort_order" ASC LIMIT 20
OFFSET :offset
إليك موضوع بحجم عادي وموضوع ضخم بشكل غير منطقي:
Example time: 3.4ms
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..1925.22 rows=477 width=8)
example time: 353.9ms, 739.6 ms (time varies depending on database caching)
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..605155.88 rows=161255 width=8)
أعتقد أنني رأيت أوقاتًا أطول من 750 مللي ثانية.
إليك أوقات الوسيط والفترة المئوية التاسعة والتسعين. وقت الوسيط جيد بشكل مفاجئ، لكن طبيعة الوسيط تعني أنك لا تستطيع معرفة ما إذا كان في النسبة المئوية الستين أسوأ بكثير من حالة الوسيط.
إليك خادم آخر (يحتوي على عدد هائل من الفئات، مما يسبب له أيضًا ضربة في الأداء، لذا فهو ليس مقارنة عادلة دون مواضيع ضخمة)، لكنك تستطيع أن ترى أن أداء الوسيط هو النصف وأن أسوأ حالة أفضل بكثير أيضًا:
11 إعجابًا
أنا أيضًا، مجرد فضول.
أفهم أن التنقل في موضوع ضخم قد يؤدي إلى أداء ضعيف وفقًا لهذا الشرح:
ومع ذلك، لا أفهم كيف يمكن لموضوع ضخم واحد أو عدة مواضيع ضخمة أن تؤثر على التنقل في صفحات أخرى في المنتدى، حتى قائمة المواضيع مثلًا. 
عن طريق إضافة حمل كبير جدًا على الخادم. كل تحميل موضوع ضخم واحد يعادل 100 ضعف عقوبة الأداء! انظر المنشور الموجود مباشرة فوق منشورك.
5 إعجابات
مرحبًا،
المنتدى الذي أقوم حاليًا باستيراده إلى Discourse يحتوي على العديد من المواضيع الضخمة:
(ولم يتم استيراد جميع المنشورات بعد!)
بما أن المواضيع الضخمة لا تعمل بشكل جيد مع Discourse، فماذا أفعل عمليًا؟ (أعتزم اقتراح دردشة في المستقبل للمجتمع، ربما عبر Discord، لكنني أريد معرفة ما يجب فعله مع المواضيع الحالية)؟
هل أحذفها؟
أم أقوم بتقسيمها وإغلاقها؟
إذا قمت بتقسيمها، فكم عدد الرسائل في كل موضوع؟ هل القيمة الافتراضية البالغة 10000 كافية، أم تنصحون بتقليلها؟
3 إعجابات
تقسيمها إلى كتل حجمها 10 آلاف يجب أن يكون كافياً.
8 إعجابات
بالإضافة إلى ذلك، تبدو معظمها مقبولة. يبدأ الخسائر الحقيقية عند 10 آلاف، ومعظم ما هو مصوّر في لقطة الشاشة أقل بكثير من 10 آلاف.
6 إعجابات
ما هي آخر مستجدات تأثير الأداء على الموضوع الضخم؟ إن موضوعنا المتعلق بمتابعة جائحة كوفيد يقترب من 10 آلاف منشور، ونحن نقوم بتحليل أي تباطؤ محتمل حدث مؤخرًا.
4 إعجابات
لا أعرف ما الذي “يجب” أن تكون عليه إحصائيات الخادم، لكن يمكنني مشاركة إحصائياتنا لمجتمع يحتوي على عدد كبير من المواضيع الضخمة. لدينا حاليًا 15 موضوعًا مغلقًا يحتوي كل منها على 10 آلاف منشور، وأكثر من 50 موضوعًا مفتوحًا يحتوي كل منها على أكثر من 2 ألف منشور. تحدث معظم نشاطات المنتدى في عدد محدود نسبيًا من المواضيع النشطة جدًا في أي وقت معين.
نعمل حاليًا على خادم DigitalOcean يحتوي على 4 معالجات افتراضية، وذاكرة عشوائية بسعة 8 جيجابايت، ومساحة تخزين بسعة 160 جيجابايت، بتكلفة 40 دولارًا شهريًا. ربما مرة كل بضعة أشهر، قد يرى بعض المستخدمين لفترة وجيزة جدًا رسالة “حمل شديد”. يحدث هذا فقط عندما تكون هناك حدث مباشر ويشارك عدد كبير من المستخدمين في النشر في آن واحد - مثل متوسط عدة منشورات في الدقيقة في موضوع واحد على مدار ساعة أو ساعتين.
في جميع الأوقات الأخرى، يكون الأداء سلسًا دون أي مشاكل. نحن حاليًا على الطريق إلى الحاجة إلى مساحة تخزين أكبر قبل وقت طويل من حاجتنا لترقية أي شيء آخر.
6 إعجابات
هذا رقم جيد؛ فـ 2000 منشور ليس بالأمر الكبير، وربما يكون وجود بضعة عشرات من المواضيع التي تتجاوز 10 آلاف منشور مقبولًا (خاصة إذا كانت مغلقة). أما منطقة الخطر فتظهر عندما يكون لديك العديد من المواضيع الضخمة النشطة. سأعرّف “العديد” بأنه أكثر من بضعة عشرات.
10 إعجابات
في حين أن المواضيع الضخمة ليست عادةً مشكلة هنا في Meta، إلا أنها تبدو طريقة طبيعية لتنظيم النقاشات للعديد من المجتمعات. بعبارة أخرى، لا توجد نقطة توقف طبيعية للنقاش.
إنديريس هي شركة فنلندية تقدم تحليلاً مالياً لسوق الأسهم. وقد أطلقوا مؤخراً مجتمعهم على منصة ديسكورت، وكان نجاحاً هائلاً بالنظر إلى المنطقة والقطاع المتخصص.
يتم تنظيم النقاش بشكل أساسي حسب كل سهم أو أداة استثمارية، مثل $AAPL أو $TSLA كمثال. والآن، بعد عامين فقط، تقترب العديد من هذه المواضيع من علامة 10 آلاف مشاركة. وهذا دليل رائع على فعالية ديسكورت (مجتمع نابض بالحياة، بُني من الصفر)، لكنه يسلط الضوء أيضاً على مشكلة المواضيع الضخمة.
4 إعجابات
إذا لم يكن هناك خيار آخر، يمكنك تقسيمها حسب السنة. هذا موضح في المنشور الأول. يمكن للمواضيع الضخمة أن تعمل لفترة من الوقت، ولكن إذا زاد عددها كثيرًا، فسوف تؤدي في النهاية إلى انهيار موقعك.
(أيضًا، تصبح عملية البحث كابوسًا عندما يكون لديك عشرات الآلاف من المنشورات في “موضوع” واحد، إلخ — فببساطة لقد أنشأت غرفة دردشة.)
5 إعجابات