মার্জ-পরবর্তী jrpm ব্রাঞ্চের উপর ভিত্তি করে (pulsexlb বৈশিষ্ট্য ও jrpm নিজস্ব অপ্টিমাইজেশন সহ)। প্যারামিটার ডিফল্ট মান src/table/settings/network_settings.ini থেকে নেওয়া, প্রকৃত লোড পরীক্ষার ভিত্তিতে সামঞ্জস্য করার পরামর্শ দেওয়া হয়।

এক. ইতিমধ্যে বাস্তবায়িত পারফরম্যান্স অপ্টিমাইজেশন (এইবার)

অপ্টিমাইজেশন	কমিট	ব্যাখ্যা
সমান্তরাল ডাউনলোড কনকারেন্সি কনফিগারেবল	4716b925	network.content_download_parallel (ডিফল্ট ৪, ১-৮): কন্টেন্ট ডাউনলোডে একসাথে চলা ফাইলের সংখ্যা, হার্ডকোডেড ৪-এর পরিবর্তে
মাল্টি-মিরর + ফাইল-লেভেল সমান্তরাল ডাউনলোড	d4c45740 (F1)	network.content_mirrors কমা-বিচ্ছিন্ন মাল্টি-মিরর, ব্যর্থ হলে মিরর অনুযায়ী পুনরায় চেষ্টা, শেষে পুরনো প্রোটোকলে ফিরে যাওয়া
সার্ভার মাল্টি-ভার্সন ক্লায়েন্ট সামঞ্জস্য	cb9848b7	সার্ভার একই সাথে jrpm / মূল jgrpp / pulsexlb ক্লায়েন্ট গ্রহণ করতে পারে

দুই. সার্ভার পারফরম্যান্স মূল প্যারামিটার (jgrpp体系)

সেটিংস	ডিফল্ট	পরিসীমা	অর্থ	টিউনিং পরামর্শ
network.sync_freq	100	0-100	কত ফ্রেম পর পর ফ্রেম সিঙ্ক যাচাই (desync সনাক্তকরণ)। বড় মান = কম ব্যান্ডউইথ, ছোট মান = দ্রুত ডিসিঙ্ক সনাক্ত	মাল্টিপ্লেয়ার স্থিতিশীলতা অগ্রাধিকার দিলে ২০-৫০-এ নামানো যেতে পারে; ঘন ঘন desync হলে কম করুন
network.frame_freq	0	0-100	সার্ভার প্রতি কত ফ্রেম পর কমান্ড ফ্রেম প্যাকেজ পাঠায় (০ = প্রতি ফ্রেমে পাঠান)। বড় মান = কম ব্যান্ডউইথ/CPU, কিন্তু অপারেশন লেটেন্সি বাড়ে	সাধারণত ০-৩; বেশি প্লেয়ার থাকলে ৫ পর্যন্ত, লোড পরীক্ষার পর সামঞ্জস্য
network.commands_per_frame	2	1-65535	প্রতি ফ্রেমে প্রক্রিয়াকৃত ক্লায়েন্ট কমান্ডের সংখ্যা সীমা (স্প্যাম/দূষিত প্রতিরোধ)	প্লেয়ার বেশি, অপারেশন ঘন ঘন হলে ৪-৮-এ বাড়ানো যেতে পারে
network.commands_per_frame_server	16	1-65535	সার্ভারের নিজস্ব প্রতি ফ্রেম কমান্ড সংখ্যা সীমা	সাধারণত পরিবর্তনের প্রয়োজন নেই
network.bytes_per_frame	8	1-65535	দীর্ঘমেয়াদী গড় প্রতি ফ্রেম প্রাপ্ত বাইট সংখ্যা সীমা (ব্যান্ডউইথ শেপিং)	ব্রডব্যান্ড ভালো থাকলে ১৬-৩২-এ বাড়ানো যেতে পারে, বড় ম্যাপ সিঙ্ক গতি উন্নত করে
network.bytes_per_frame_burst	256	1-65535	বিস্ফোরণ বাইট সীমা (স্বল্পমেয়াদী পিক অনুমতি দেয়)	উপরের আইটেমের সাথে বাড়ান, যেমন ৫১২
network.max_init_time	60	0-32000	ক্লায়েন্ট ইনিশিয়ালাইজেশন টাইমআউট (টিক)	দুর্বল নেটওয়ার্কের প্লেয়ার বেশি থাকলে শিথিল করা যেতে পারে
network.max_join_time	500	0-32000	ক্লায়েন্ট যোগদান (ম্যাপ ডাউনলোড + সিঙ্ক) টাইমআউট (টিক)	বড় ম্যাপ/ধীর ব্যান্ডউইথের জন্য ১০০০+ শিথিল করুন
network.max_download_time	1000	0-32000	ম্যাপ ডাউনলোড টাইমআউট (টিক)	বড় ম্যাপ (৪০৯৬+) এর জন্য ২০০০+ পরামর্শ দেওয়া হয়
network.max_lag_time	800	0-32000	ক্লায়েন্ট সর্বোচ্চ লেটেন্সি সহনশীলতা (টিক)	উচ্চ লেটেন্সি প্লেয়ার বেশি থাকলে শিথিল করুন, কিন্তু desync ঝুঁকি বাড়ে

লক্ষ্য করুন: max_*_time একক গেম টিক (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   ; ক্লায়েন্ট পক্ষের কন্টেন্ট ডাউনলোড কনকারেন্সি

চার. পরবর্তীতে বাস্তবায়নযোগ্য পারফরম্যান্স অপ্টিমাইজেশনের দিক (অগ্রাধিকার অনুযায়ী)

১. HTTP ট্রান্সপোর্ট লেয়ার থ্রেড পুল + Range চাঙ্ক ডাউনলোড (Openttd-Cluster 0007 ধারণা) বর্তমান অবস্থা: F1 ইতিমধ্যে "ফাইল-লেভেল সমান্তরাল" (একাধিক ফাইল একসাথে ডাউনলোড) বাস্তবায়ন করেছে। 0007 HTTP লেয়ারে থ্রেড পুল + CURLOPT_RANGE চাঙ্ক করে, একক বড় ফাইলের (বিশাল সিনারিও .tar.gz) জন্য আরও গতি বাড়ায়। দুটি পরিপূরক কিন্তু একই ফাইল পরিবর্তন করে, F1 স্থিতিশীল হওয়ার পরে ইনক্রিমেন্টালি করার পরামর্শ দেওয়া হয়।

২. ম্যাপ প্রেরণ অপ্টিমাইজেশন jrpm ডিফল্টভাবে ম্যাপ কম্প্রেশন (zstd/lzma) সক্ষম কিনা যাচাই করুন; বড় ম্যাপের জন্য বিভিন্ন কম্প্রেশন অ্যালগরিদমের সময় তুলনা করুন।

৩. Rust সার্ভার রানটাইম (দূরবর্তী আর্কিটেকচার রেফারেন্স) Openttd-Cluster-এর otc-engine (Admin/RCON, Prometheus মেট্রিক্স, ক্লাস্টার failover, Web প্যানেল, স্ন্যাপশট ব্রিজ) সম্পূর্ণ Rust প্রকৌশল FFI ইন্টিগ্রেশনের উপর নির্ভরশীল, "পরবর্তী প্রজন্মের সার্ভার" স্তরের পরিবর্তন, প্যাচ-লেভেল মার্জ নয়; jrpm বর্তমানে বিশুদ্ধ C++ একক বাইনারি বজায় রাখে।

৪. গেম সিমুলেশন পারফরম্যান্স

• বড় ম্যাপ + প্রচুর যানবাহন থাকলে 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 কম্বিনেশন পরীক্ষা করে স্থিতিশীল সীমা খুঁজুন।