يا محمد، خلّني أحلّلها بالأرقام من سكرينك نفسه:
أطلقت ١٠٠٠ عامل و~٤٩٦٬��٩٢ طلب على ديمو بـنواة معالج وحدة. النتيجة؟ ٤٩٦٬٨٧٧ طلب اترفض (٩٩٫٩٩٪)، و١٥ بس عدّوا، والسرعة ٠ req/s. يعني الجدار صدّهم، مو إنه وقع — فيه rate-limiter شغّال (٥ محاولات كل ١٥ دقيقة لكل IP).
الـ 500 اللي صوّرتها؟ رجعت خطأ نظيف برقم مرجعي (ff6eac72…)، بدون أي فقدان بيانات، والنظام رجع لحاله لحيّه. هذا اسمه تدهور رشيق تحت هجوم مقصود — مو انهيار. لو كانت "بتوقع" فعلاً، كان صار فساد بيانات أو ما رجعت أصلاً.
ونظريتك إن «الـAI يكتب الأخطاء في الداتابيز فوقعت» معكوسة: الفيض اتصدّ قبل الداتابيز؛ الـ 500 كانت من إشباع نواة وحدة، مو من تسجيل ال��خطاء.
وعلى العموم شكراً — استفدت من الاختبار: ضفت سقف عام لكل IP يرفض أي إغراق بـ429 قبل ما يلمس قاعدة البيانات أو تشفير كلمة المرور. جرّب ثاني 😉
وبعدين، اختبار الهجوم الحجمي الحقيقي مكانه CDN/WAF قدام السيرفر — قرار بنية تحتية، مو عيب في الكود. الديمو صندوق صغير بنواة وحدة عمدًا.
@mahmooud_2009 حاول ترجع السايد بار القديم لان ده حرفياً استخدامه مش كويس
اوه نسيت انك بتستخدم ai متعرفش يعني ايه git ومتقدرش ترجع خلاص حاول مع ال ai ان شاء الله يفيدك
@mahmooud_2009 معقولة ركويست login ياخد 10 ثواني وركويست logout ياخد 12 ثانيه وانت يادوبك هتبعت فى ال logout انك تشيل الكوكيز من البراوزر ولو في حاجه تانيه هتعملها فى السيرفر ترميها فى الكيو
عرفت ليه المبرمج يستاهل اكثر من 100 الف ريال ؟
@mohamedsalah_sw في مشكلة تانيه كنت واجهتها بس حليتها بشوية حاجات اوبن سورس
عملت كومبو بسيط بديل ل firecrawl
باستخدام crawl4ai + searxng
وبعمل كلين وبيكون كويس جدا
@mohamedsalah_sw لسه بصراحة مفكرتش فى ال Scalablety اوي لان انا لسه فى الاول
حالياً الحاجه الصعبه الى معايا ان لوفبل مش بيتيح للشخص يعمل edit بنفسه
فا بحاول اعمل حل زي replit كده باستخدام yjs بس في كذا مشكلة انه كل ملف بيحتاج يعمل connect فا ال ux مش بيكون كويس ده مع yjs