استناداً إلى فرع jrpm بعد الدمج (بما في ذلك ميزات pulsexlb والتحسينات الحصرية لـ jrpm). القيم الافتراضية للمعلمات مأخوذة من src/table/settings/network_settings.ini، يوصى بالاعتماد على الاختبارات الفعلية.

أولاً: تحسينات الأداء المطبقة (هذه المرة)

التحسين	الـ commit	الوصف
عدد التنزيل المتوازي قابل للتكوين	4716b925	network.content_download_parallel (الافتراضي 4، 1-8): عدد الملفات التي يتم تنزيلها في وقت واحد للمحتوى، بدلاً من الترميز الثابت 4
مرايا متعددة + تنزيل متوازي على مستوى الملف	d4c45740 (F1)	network.content_mirrors مرايا متعددة مفصولة بفواصل، إعادة محاولة حسب المرآة عند الفشل، الرجوع النهائي للبروتوكول القديم
توافق إصدارات متعددة للعملاء	cb9848b7	يمكن للخادم استقبال عملاء jrpm / jgrpp الأصلي / pulsexlb في نفس الوقت

ثانياً: معلمات أداء الخادم الرئيسية (نظام jgrpp)

الإعداد	الافتراضي	النطاق	المعنى	اقتراح الضبط
network.sync_freq	100	0-100	كل كم إطار يتم إجراء فحص مزامنة إطار (كشف desync). كلما زاد، وفر في النطاق الترددي؛ كلما قل، اكتشف عدم التزامن مبكراً	إذا كانت استقرار الشبكة أولوية، يمكن خفضه إلى 20-50؛ عند اكتشاف desync متكرر، اخفضه
network.frame_freq	0	0-100	الخادم يرسل إطار أوامر كل كم إطار (0 = إرسال كل إطار). كلما زاد، وفر في النطاق الترددي/CPU لكن زاد تأخير العملية	عادة 0-3؛ الخوادم ذات الأعداد الكبيرة يمكن أن تصل إلى 5، وازن بعد الاختبار
network.commands_per_frame	2	1-65535	الحد الأقصى لعدد أوامر العميل المعالجة لكل إطار (مكافحة البريد المزعج/الخبيث)	عندما يكون اللاعبون كثيرين والتشغيل متكرراً، يمكن رفعه إلى 4-8
network.commands_per_frame_server	16	1-65535	الحد الأقصى لعدد أوامر الخادم نفسه لكل إطار	عادة لا يحتاج إلى تغيير
network.bytes_per_frame	8	1-65535	متوسط الحد الأعلى لبايتات الاستقبال لكل إطار على المدى الطويل (تشكيل النطاق الترددي)	إذا كان النطاق الترددي جيداً، يمكن رفعه إلى 16-32 لتحسين سرعة مزامنة الخريطة الكبيرة
network.bytes_per_frame_burst	256	1-65535	الحد الأعلى للبايتات المفاجئة (يسمح بذروة قصيرة المدى)	يرفع مع العنصر أعلاه، مثل 512
network.max_init_time	60	0-32000	مهلة تهيئة العميل (tick)	إذا كان اللاعبون ذوو الشبكة الضعيفة كثيرين، يمكن التوسيع
network.max_join_time	500	0-32000	مهلة انضمام العميل (تنزيل الخريطة + مزامنة) (tick)	للخرائط الكبيرة/النطاق الترددي البطيء، وسّع إلى 1000+
network.max_download_time	1000	0-32000	مهلة تنزيل الخريطة (tick)	للخرائط الكبيرة (4096+) يوصى بـ 2000+
network.max_lag_time	800	0-32000	أقصى تأخير مسموح به للعميل (tick)	عندما يكون اللاعبون ذوو زمن الوصول العالي كثيرين، وسّع، لكنه يزيد من خطر desync

ملاحظة: وحدة max_*_time هي tick اللعبة (1/74 ثانية ≈ 13.5ms)؛ bytes_per_frame يشير إلى متوسط بايتات نافذة المزامنة لكل إطار.

ثالثاً: تكوين بدء الخادم الموصى به (سيناريو تعدد اللاعبين)

[network]
max_clients = 32            ; أو حسب الحاجة
max_companies = 15
frame_freq = 3              ; 0=إرسال الأوامر كل إطار (الأكثر سلاسة)؛ 3=حل وسط لتوفير النطاق الترددي
sync_freq = 50              ; اكتشاف عدم التزامن مبكراً
commands_per_frame = 8
bytes_per_frame = 16
bytes_per_frame_burst = 512
max_join_time = 1000
max_download_time = 2000
max_lag_time = 1200
content_download_parallel = 4   ; تزامن تنزيل المحتوى من جانب العميل

رابعاً: اتجاهات تحسين الأداء المستقبلية القابلة للتطبيق (حسب الأولوية)

1. تجمع خيوط طبقة النقل HTTP + تنزيل مجزأ Range (فكرة Openttd-Cluster 0007) الوضع الحالي: F1 طبق بالفعل "توازي على مستوى الملف" (تنزيل ملفات متعددة في وقت واحد). 0007 يقوم بتجمّع خيوط على طبقة HTTP + CURLOPT_RANGE للتجزئة، يمكنه تسريع ملف واحد كبير (سيناريو ضخم .tar.gz). كلاهما متكامل لكن يغيران نفس مجموعة الملفات، يوصى بالتنفيذ التدريجي بعد استقرار F1.

2. تحسين إرسال الخريطة تحقق مما إذا كان jrpm يفعل ضغط الخريطة افتراضياً (zstd/lzma)؛ يمكن مقارنة وقت الخوارزميات المختلفة للخرائط الكبيرة.

3. زمن تشغيل خادم Rust (مرجع معماري بعيد المدى) otc-engine من Openttd-Cluster (Admin/RCON، مقاييس Prometheus، تجاوز الفشل العنقودي، لوحة ويب، جسر اللقطات) يعتمد على تكامل FFI لمشروع Rust كامل، هو ترقية بمستوى "الجيل التالي من الخادم"، وليس دمجاً على مستوى التصحيح؛ jrpm حالياً يبقى ثنائي C++ خالص.

4. أداء محاكاة اللعبة

   • للخرائط الكبيرة + عدد كبير من المركبات، انتبه لمعاملات economy/linkgraph (linkgraph_settings.ini)؛
   • إذا كانت هناك حاجة لأداء متطرف، يمكن دراسة فئة settings_game.economy. ومعاملات حد pathfinder (إعدادات pathfinding).

خامساً: اقتراحات التحقق

• افتح الخادم openttd-jrpm -D -c server.cfg، استخدم عدة عملاء jrpm للاختبار الفعلي: وقت الانضمام، استقرار مزامنة الإطارات (بدون提示 desync)، استخدام CPU/الذاكرة؛
• تنزيل المحتوى: اضبط content_download_parallel=8 وقارن وقت تنزيل مجموعة NewGRF؛
• اختبار ضغط الشبكة الضعيفة: اختبر مجموعة max_lag_time و sync_freq لإيجاد الحدود المستقرة.