বেঞ্চমার্কিং অ্যাপাচি কাফকা: পারফরম্যান্স-প্রতি-মূল্য

এই নিবন্ধে, আমি অ্যাপাচি কাফকার পরিবেশের তুলনামূলক একটি গবেষণা উপস্থাপন করি। চূড়ান্ত লক্ষ্য হল সবচেয়ে কার্যকর সেটআপ খুঁজে বের করা এবং সেরা মূল্য-কর্মক্ষমতা অনুপাত অর্জন করা।

আমাদের ডেটা প্ল্যাটফর্ম বৃহৎ ডেটা সেটগুলির জন্য বিশ্লেষণাত্মক প্ল্যাটফর্ম তৈরির জন্য পরিচালিত পরিষেবাগুলি প্রদান করে, অন্যান্য বাজারের সমাধানগুলির সাথে প্রতিযোগিতা করে৷ প্রতিযোগীতা বজায় রাখার জন্য, আমরা আমাদের শক্তিগুলি চিহ্নিত করতে এবং উন্নত করতে, আরও ভাল চুক্তি নিশ্চিত করতে নিয়মিত অভ্যন্তরীণ গবেষণা পরিচালনা করি। এই নিবন্ধটি এমন একটি গবেষণা দেখায়। বর্তমানে, আমাদের প্ল্যাটফর্ম ক্লাউড প্রদানকারী হিসাবে AWS এবং GCP সমর্থন করে। উভয়ই একাধিক গণনা প্রজন্ম এবং দুটি CPU আর্কিটেকচার (Intel এবং AMD, এবং ARM সহ x86) অফার করে। আমি বিভিন্ন জাভা ভার্চুয়াল মেশিন (JVMs) ব্যবহার করে এই সেটআপগুলির তুলনা করি নতুন প্রসেসরগুলিতে নতুন সংস্করণগুলির কার্যকারিতা মূল্যায়ন করতে।

আপনি যদি একটি TL চান; DR: ARM rocks. আধুনিক ব্যয়বহুল স্থাপত্য সবসময় "ভাল" মানে না। আপনি সরাসরি ফলাফলে যেতে পারেন বা পদ্ধতি এবং সেটআপ সম্পর্কে আরও জানতে এগিয়ে যেতে পারেন।

পদ্ধতি

আমি আমাদের নিজস্ব পরিষেবার সাথে পারফরম্যান্স পরীক্ষা করার কথা বিবেচনা করেছি কিন্তু বিভিন্ন পরিবেশে এটি তুলনা করতে চেয়েছিলাম যা আমরা এখনও সমর্থন করিনি৷ আমি নতুন ভার্চুয়াল মেশিন, অঞ্চল এবং এমনকি অন্যান্য ক্লাউড প্রদানকারীও পরীক্ষা করতে চেয়েছিলাম। তাই, আমি একটি খেলনা প্রকল্প বাস্তবায়নের মাধ্যমে শুরু করেছি যা বিভিন্ন বেস কন্টেইনার ইমেজ সহ বেসলাইন কাফকা ব্যবহার করে। এইভাবে, আমি নির্দিষ্ট হার্ডওয়্যারে বেঞ্চমার্ক টুল চালাতে পারি এবং কর্মক্ষমতা পরিমাপ করতে পারি।

আমি সবচেয়ে আকর্ষণীয় ফলাফল সনাক্ত করতে বিভিন্ন কনফিগারেশন পরীক্ষা করার লক্ষ্য রাখি। এর জন্য, আমি প্রাথমিক ফলাফলগুলি ফিল্টার করতে পরীক্ষার ম্যাট্রিক্সের ধারণাটি ব্যবহার করি। পারফরম্যান্সকে আরও পরিমার্জিত করতে পারফ এবং ইবিপিএফ-এর মতো টুল ব্যবহার করে আমি এই ফলাফলগুলি গভীরভাবে বিশ্লেষণ করব।

টেস্টিং কেস

আসুন প্রথমে পরীক্ষার লক্ষ্যগুলি বর্ণনা করি। ওপেনজেডিকে জেভিএম নিয়ে আমার অনেক অভিজ্ঞতা আছে, কিন্তু আজ, মাইক্রোসফ্ট, অ্যামাজন এবং অন্যান্য কোম্পানি থেকে অনেক বিকল্প রয়েছে। উদাহরণস্বরূপ, Amazon Correto-এ AWS-এর জন্য অপ্টিমাইজ করা অতিরিক্ত বৈশিষ্ট্য এবং প্যাচ অন্তর্ভুক্ত রয়েছে। যেহেতু আমাদের বেশিরভাগ গ্রাহক AWS ব্যবহার করেন, তাই এই JVMগুলি সেই প্ল্যাটফর্মে কীভাবে পারফর্ম করে তা দেখতে আমি পরীক্ষায় Amazon Correto অন্তর্ভুক্ত করতে চেয়েছিলাম।

আমি প্রথম তুলনার জন্য এই সংস্করণগুলি বেছে নিয়েছি:

• OpenJDK 11 (একটি পূর্ববর্তী তুলনার জন্য, যদিও এটি পুরানো)
• OpenJDK 17 (বর্তমানে ব্যবহৃত JVM)
• Amazon Coretto 11.0.22-amzn (একটি বিকল্প পূর্ববর্তী তুলনা)
• Amazon Coretto 17.0.10-amzn (আমাদের বর্তমান সংস্করণের একটি বিকল্প)
• Amazon Coretto 21.0.2-amzn (একটি নতুন এলটিএস সংস্করণ যা আরও ভাল হওয়া উচিত)

সংস্করণগুলি সংজ্ঞায়িত হয়ে গেলে, আমি Amazon Correto এবং OpenJDK ব্যবহার করে কাফকা ছবিগুলি তৈরি করার জন্য কয়েকটি স্ক্রিপ্ট প্রস্তুত করেছিলাম।

ইমেজ সেটিংস

বেঞ্চমার্কিং পরীক্ষার জন্য, আমি নির্দিষ্ট কর্মক্ষমতা মেট্রিক্সে ফোকাস করার জন্য কাফকা সেটিংস পরিবর্তন করেছি। আমি [JVM] x [instance_type] x [architecture] x [cloud_provider] এর বিভিন্ন সংমিশ্রণ পরীক্ষা করতে চেয়েছিলাম, তাই নেটওয়ার্ক সংযোগ এবং ডিস্কের কর্মক্ষমতার প্রভাব কমিয়ে আনা গুরুত্বপূর্ণ ছিল। আমি ডেটা স্টোরেজের জন্য tmpfs সহ কন্টেইনার চালিয়ে এটি করেছি:

 podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64

স্বাভাবিকভাবেই, এই সেটআপটি উৎপাদনের জন্য নয়, তবে CPU এবং মেমরির বাধা বিচ্ছিন্ন করা প্রয়োজন ছিল। সর্বোত্তম উপায় হল পরীক্ষাগুলি থেকে নেটওয়ার্ক এবং ডিস্কের প্রভাবগুলি সরিয়ে ফেলা। অন্যথায়, এই কারণগুলি ফলাফলগুলিকে তির্যক করবে।

ন্যূনতম বিলম্বিতা এবং উচ্চতর প্রজননযোগ্যতা নিশ্চিত করতে আমি একই উদাহরণে বেঞ্চমার্ক টুল ব্যবহার করেছি। আমি হোস্ট-নেটওয়ার্ক কনফিগারেশন ছাড়া এবং cgroup-বিচ্ছিন্ন ভার্চুয়াল নেটওয়ার্কের সাথে পরীক্ষা করার চেষ্টা করেছি, কিন্তু এইগুলি শুধুমাত্র অপ্রয়োজনীয় লেটেন্সি যোগ করেছে এবং প্যাকেট ফরওয়ার্ডিংয়ের জন্য CPU ব্যবহার বাড়িয়েছে।

যদিও tmpfs গতিশীলভাবে মেমরি বরাদ্দ করে এবং ফ্র্যাগমেন্টেশন এবং লেটেন্সি হতে পারে, এটি আমাদের পরীক্ষার জন্য যথেষ্ট ছিল। আমি পরিবর্তে ramdisk ব্যবহার করতে পারতাম, যা স্ট্যাটিকভাবে মেমরি বরাদ্দ করে এবং এই সমস্যাগুলি এড়িয়ে যায়, কিন্তু tmpfs কার্যকর করা সহজ ছিল এবং এখনও আমরা যে অন্তর্দৃষ্টিগুলি পরেছিলাম তা সরবরাহ করে। আমাদের উদ্দেশ্যে, এটি সঠিক ভারসাম্যকে আঘাত করেছে।

উপরন্তু, আমি আরও ঘন ঘন মেমরি থেকে ডেটা বের করার জন্য কিছু অতিরিক্ত কাফকা সেটিংস প্রয়োগ করেছি:

 ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0

এখানে পরিবর্তনগুলির একটি সারসংক্ষেপ রয়েছে:

• দ্রুত ডেটা সরানোর জন্য লগ ধারণ করার সময় 15 সেকেন্ডে সেট করা হয়েছে, এবং tmpfs-এ সঞ্চয়স্থান পরিচালনা করতে লগ ধারণ করার আকার 1 GB পর্যন্ত সীমাবদ্ধ। ফাইলগুলিকে দ্রুত ঘোরানোর জন্য লগ সেগমেন্টের আকারও 256 MB-তে পরিবর্তন করা হয়েছে৷
• পুরানো ডেটা দ্রুত মুছে ফেলার জন্য ধারণ চেকের ব্যবধান 1 সেকেন্ডে কমিয়ে আনা হয়েছে
• মেমরি সমস্যা প্রতিরোধ করতে সেগমেন্ট মুছে ফেলতে বিলম্ব 0 এ সেট করা হয়েছে

এই কনফিগারেশনটি উত্পাদন ব্যবহারের জন্য উপযুক্ত নয়, তবে এটি আমাদের বেঞ্চমার্ক পরীক্ষার জন্য গুরুত্বপূর্ণ কারণ এটি অপ্রাসঙ্গিক কারণগুলির প্রভাব হ্রাস করে৷

উদাহরণ প্রকার

ডাবলক্লাউডে, এই নিবন্ধটি লেখার সময়, আমরা গণনা সংস্থানগুলির এই প্রধান প্রজন্মকে সমর্থন করি:

• s1 পরিবার : m5a দৃষ্টান্ত (আই 1 ইন্টেল প্রসেসরের সাথে m5 প্রতিনিধিত্ব করে)
• s2 পরিবার : m6a দৃষ্টান্ত (আই 2 ইন্টেল প্রসেসরের সাথে m6i প্রতিনিধিত্ব করে)
• sg1 পরিবার : AMD রোম প্রসেসরের সাথে GCP n2- স্ট্যান্ডার্ড উদাহরণ

Graviton প্রসেসরের জন্য, আমরা সমর্থন করি:

• g1 পরিবার : m6g উদাহরণ (Graviton 2)
• g2 পরিবার : m7g উদাহরণ (Graviton 3)

উপরন্তু, আমি অ্যাম্পিয়ার আল্ট্রা-তে গ্র্যাভিটনের বিকল্প হিসাবে GCP-তে t2a উদাহরণ পরীক্ষা করেছি। AWS-এর সীমিত আঞ্চলিক সহায়তার কারণে আমরা আমাদের গ্রাহকদেরকে এগুলি অফার করি না, কিন্তু পারফরম্যান্সের তুলনা করার জন্য আমি সেগুলিকে বেঞ্চমার্কে অন্তর্ভুক্ত করেছি। আপনি যদি "সঠিক" অঞ্চলগুলির একটিতে থাকেন তবে এটি একটি ভাল বিকল্প হতে পারে।

বেঞ্চমার্ক টুল

বেঞ্চমার্কিংয়ের জন্য, আমি ফ্রাঞ্জ-গো লাইব্রেরি এবং উদাহরণের উপর ভিত্তি করে একটি লাইটওয়েট টুল তৈরি করেছি। এই টুলটি দক্ষতার সাথে কাফকাকে বিঘ্নিত না করে পরিপূর্ণ করে।

যদিও librdkafka এর নির্ভরযোগ্যতা এবং জনপ্রিয়তার জন্য পরিচিত, আমি cgo এর সম্ভাব্য সমস্যার কারণে এটি এড়িয়ে গিয়েছিলাম।

পরীক্ষা

কাফকা তার স্কেলেবিলিটির জন্য সুপরিচিত, যেটি বিষয়গুলিকে একাধিক পার্টিশনে বিভক্ত করার অনুমতি দেয় যাতে ব্রোকারদের মধ্যে অনুভূমিকভাবে কাজের চাপগুলি দক্ষতার সাথে বিতরণ করা যায়। যাইহোক, আমি পারফরম্যান্স-থেকে-মূল্য অনুপাতের উপর আমাদের নির্দিষ্ট ফোকাসের জন্য একক-কোর কর্মক্ষমতা মূল্যায়নে মনোনিবেশ করেছি।

অতএব, পরীক্ষাগুলি পৃথক মূল ক্ষমতাগুলি সম্পূর্ণরূপে ব্যবহার করার জন্য একক পার্টিশন সহ বিষয়গুলি ব্যবহার করে।

প্রতিটি পরীক্ষার ক্ষেত্রে দুটি ধরণের অন্তর্ভুক্ত:

• সিঙ্ক্রোনাস প্রোডাক্ট: বার্তা স্বীকৃতির জন্য অপেক্ষা করে, কম লেটেন্সি পরিবেশ পরিমাপের জন্য আদর্শ যেখানে মিলিসেকেন্ড গুরুত্বপূর্ণ, যেমন রিয়েল-টাইম অ্যাপ্লিকেশন
• অ্যাসিঙ্ক্রোনাস প্রোডাক্ট: বার্তাগুলিকে বাফার করে এবং সেগুলিকে ব্যাচে পাঠায়, কাফকা ক্লায়েন্টদের জন্য সাধারণ যেগুলি 10-100 ms এর সহনীয় লেটেন্সি সহ রিয়েল-টাইম চাহিদার কাছাকাছি ভারসাম্য বজায় রাখে

আমি 8 KB বার্তা ব্যবহার করেছি, একটি গড় গ্রাহকের ক্ষেত্রের চেয়ে বড়, বিষয় পার্টিশন থ্রেডগুলি সম্পূর্ণরূপে পরিপূর্ণ করতে।

ফলাফল

আমি বিভিন্ন স্থাপত্যের মূল্যায়ন করার জন্য একটি সিন্থেটিক দক্ষতা মেট্রিক ব্যবহার করে বিভিন্ন পরীক্ষার ক্ষেত্রে তুলনা করে প্লটের একটি সিরিজ উপস্থাপন করছি। এই মেট্রিকটি লক্ষ লক্ষ সারিগুলিকে পরিমাপ করে যা আমরা কাফকা ব্রোকারের প্রতি শতাংশে প্রবেশ করতে পারি , যা স্থাপত্যের ব্যয়-দক্ষতার একটি সরল মূল্যায়ন প্রদান করে।

এটা স্বীকার করা গুরুত্বপূর্ণ যে ক্লাউড প্রদানকারীদের অতিরিক্ত ডিসকাউন্টের কারণে প্রকৃত ফলাফল পরিবর্তিত হতে পারে। যখনই সম্ভব, উভয় ক্লাউড প্রদানকারীর জন্য পরীক্ষাগুলি ফ্রাঙ্কফুর্টে পরিচালিত হয়েছিল (অথবা নেদারল্যান্ডসে ক্ষেত্রে যেখানে উদাহরণ-টাইপ বিকল্পগুলি সীমাবদ্ধ ছিল)।

চার্ট

সমস্ত চার্টে, আমি উদাহরণের জন্য প্রচলিত নামগুলি ব্যবহার করি, তাদের প্রদানকারীরা যেগুলি ব্যবহার করে। দৃষ্টান্তগুলি প্রথমে ক্লাউড প্রদানকারী (AWS, তারপর GCP) এবং তারপর প্রজন্ম অনুসারে সাজানো হয়: পুরানো থেকে নতুন।

সম্পূর্ণ ফলাফল, যদিও কাঁচা আকারে, আমার ব্যাপক বেঞ্চমার্কিং শীটে উপলব্ধ। সেখানে, লেটেন্সি এবং ব্যান্ডউইথ নম্বর এবং বিভিন্ন JVM-এর তুলনামূলক কর্মক্ষমতা সহ আপনি এই নিবন্ধে আমি যে তথ্য উপস্থাপন করছি তার চেয়ে বেশি ডেটা খুঁজে পেতে পারেন।

AWS ফলাফল

s1 পরিবার: সবচেয়ে ধীর কর্মক্ষমতা

AMD EPYC 7571-এর সাথে m5a-প্রজন্মের উপর ভিত্তি করে "প্রথম প্রজন্মের" s1 দৃষ্টান্তগুলি, Q3 2019 থেকে ডেটিং, আমাদের উত্তরাধিকার বিকল্প। ফ্রাঙ্কফুর্টে আমাদের বিকল্পগুলির মধ্যে এগুলি সবচেয়ে কম দক্ষ এবং ধীরগতির, যার দাম প্রায় ~0.2080 €/ঘন্টা অন-ডিমান্ড৷ ~0.2070 €/ঘণ্টা খরচ করে নতুন s2 পরিবারে স্থানান্তর করা, মূলত একই মূল্যের জন্য দ্বিগুণ কার্যক্ষমতা লাভ করে। বিশ্লেষণাত্মক অ্যাপ্লিকেশনগুলির জন্য কোয়েরির সময় এবং ইনজেশনের গতি বাড়াতে আমরা গ্রাহকদের এই আরও সাশ্রয়ী এবং কার্যকরী বিকল্পগুলিতে স্থানান্তর করতে উত্সাহিত করি।

g1 পরিবার: s2 এর সাথে তুলনীয় দক্ষতা

G1 পরিবারটি Graviton 2-এর উপর ভিত্তি করে তৈরি এবং ঐতিহাসিকভাবে ভাল মান প্রদান করেছে, কিন্তু AMD প্রসেসর সহ নতুন s2 পরিবার এখন Apache Kafka-এর দক্ষতার স্তরের সাথে মেলে। সামান্য কম ব্যান্ডউইথ এবং একটি প্রান্তিক মূল্য সুবিধা দেওয়া সত্ত্বেও, নতুন বিকল্পগুলির তুলনায় G1 পরিবারকে এখন পুরানো বলে মনে করা হয়।

g2 পরিবার: উচ্চতর দক্ষতা

G2 পরিবার, Graviton 3 দ্বারা চালিত, এর উচ্চতর দক্ষতার কারণে আমাদের শীর্ষ সুপারিশ হিসাবে দাঁড়িয়েছে। এটি নির্দিষ্ট পরিস্থিতিতে 39% পর্যন্ত s2 এবং i2 পরিবারকে ছাড়িয়ে যায়, প্রায় সমস্ত অঞ্চল জুড়ে একটি সাশ্রয়ী সমাধান প্রদান করে, এটি বেশিরভাগ অ্যাপাচি কাফকা ব্যবহারের ক্ষেত্রে আদর্শ করে তোলে। কাফকার সাধারণ আইও-বাউন্ড প্রকৃতির প্রেক্ষিতে, কম্পিউটেশনাল দক্ষতা অপ্টিমাইজ করা খরচ সাশ্রয়ের জন্য গুরুত্বপূর্ণ প্রমাণিত হয়। আমি arm64 আর্কিটেকচার গ্রহণের দিকে একটি ক্রমবর্ধমান প্রবণতা লক্ষ্য করেছি, আমাদের প্রায় অর্ধেক ক্লাস্টার ইতিমধ্যেই এই নতুন প্রযুক্তি ব্যবহার করছে।

x86_64 দক্ষতার প্রবণতা

পরীক্ষাগুলি দেখায় যে প্রতিটি নতুন AMD বা Intel প্রসেসর সামগ্রিক থ্রুপুট এবং লেটেন্সির ক্ষেত্রে উন্নতি করে। তা সত্ত্বেও, নতুন m6 এবং m7 প্রজন্মের জন্য দক্ষতা বৃদ্ধি মালভূমিতে পরিণত হয়েছে। এমনকি m7 প্রজন্ম, কিছু অঞ্চলে কম লেটেন্সি প্রস্তাব করার সময়, আমাদের পরীক্ষা অনুসারে, G2 পরিবারের তুলনায় দক্ষতার কম হয়।

m7a পরিবার: অগ্রণী লেটেন্সি পারফরম্যান্স

থ্রুপুট এবং লেটেন্সির ক্ষেত্রে M7a ফ্যামিলি লো-লেটেন্সি অ্যাপ্লিকেশানে উৎকর্ষ, ইন্টেল এবং পূর্ববর্তী AMD প্রজন্মকে ছাড়িয়ে গেছে। সর্বজনীনভাবে উপলব্ধ না হলেও, এই আর্কিটেকচারটি কর্মক্ষমতা বৃদ্ধিতে AMD এর অগ্রগতি প্রতিফলিত করে। আপনার অঞ্চলে অ্যাক্সেসযোগ্য হলে, উচ্চতর ফলাফলের জন্য m7a বিবেচনা করুন।

GCP ফলাফল

AWS এর সাথে দক্ষতা তুলনা

GCP দৃষ্টান্তগুলির সাধারণত তাদের AWS বিকল্পগুলির তুলনায় কম দক্ষতা থাকে৷ এটি আমার জন্য একটি দুর্দান্ত অন্তর্দৃষ্টি ছিল, কারণ গ্রাহকরা সাধারণত বিশ্লেষণাত্মক অ্যাপ্লিকেশনগুলিতে এর ব্যয়-কার্যকারিতার জন্য GCP পছন্দ করেন, যার ফলে বিল কম হয়। আমাদের sg1 পরিবার n2-মান প্রজন্ম ব্যবহার করে, AWS s2 পরিবারের সাথে তুলনীয়। যাইহোক, অন্যান্য উদাহরণ প্রকারের সাথে এই তুলনা প্রসারিত করার আমার প্রচেষ্টা আঞ্চলিক প্রাপ্যতা দ্বারা সীমাবদ্ধ ছিল, বিশেষত c3 এবং n2 প্রজন্মের জন্য।

আর্ম টাউ প্রসেসর: খরচ-কার্যকারিতা

GCP-এর Tau প্রসেসর ব্যবহার করে আর্ম ইন্সট্যান্সগুলি Graviton 2-এর তুলনায় 5-7% দক্ষতার উন্নতির প্রস্তাব করে, যা আপনার অঞ্চলে উপলব্ধ থাকলে সেগুলিকে একটি যুক্তিসঙ্গত খরচ-সঞ্চয় বিকল্প হিসাবে তৈরি করে৷ যদিও বাহু দৃষ্টান্তগুলির জন্য GCP সমর্থন চারটি অঞ্চলের মধ্যে সীমাবদ্ধ, এটি জি 1 পরিবারের সাথে তুলনামূলক কর্মক্ষমতা এবং দক্ষতা প্রদান করে।

টেকসই ব্যবহার ডিসকাউন্ট

যেহেতু Apache Kafka ক্লাস্টারগুলিতে VM-এর ধ্রুবক ব্যবহার রয়েছে, তাই টেকসই ব্যবহার ডিসকাউন্টের সুবিধা 20% পর্যন্ত ছাড়ের অনুমতি দেয়৷ এটি অ্যাম্পিয়ার আলট্রার মতো আরও পুরানো কম্পিউটেশনাল শক্তিকে দক্ষতার দিক থেকে Graviton 3-এর সাথে প্রতিযোগিতামূলক করে তোলে। প্রত্যক্ষ তুলনা এখানে কঠিন, যদিও, অতিরিক্ত AWS ছাড়ের কারণে যা প্রযোজ্য হতে পারে।

JVM অন্তর্দৃষ্টি

আমি ভেবেছিলাম আমি এআরএম আর্কিটেকচারে নতুন JVM সংস্করণগুলির সাথে একটি উল্লেখযোগ্য উন্নতি দেখতে পাব। যাইহোক, দেখে মনে হচ্ছে openjdk-11 এবং corretto-11 ইতিমধ্যে ARM-এর জন্য বেশ অপ্টিমাইজ করা হয়েছে। যেহেতু কাফকার নতুন সংস্করণের জন্য Java 17 এবং উচ্চতর সংস্করণ প্রয়োজন, তাই আমি Java 17-এ স্যুইচ করেছি, যার ফলে আমাদের বেঞ্চমার্কে প্রায় 4-8% কর্মক্ষমতা বৃদ্ধি পেয়েছে।

উপরন্তু, 21.0.2-amzn আশাব্যঞ্জক বলে মনে হচ্ছে, নতুন ধরনের উদাহরণের ক্ষেত্রে অতিরিক্ত 10-20% পারফরম্যান্স বুস্ট দিচ্ছে।

উপসংহার

সময়ে সময়ে, আমি আমাদের উত্পাদন ক্লাস্টারগুলির জন্য সর্বোত্তম সমাধান খুঁজে পেতে এবং দরকারী অন্তর্দৃষ্টি সংগ্রহ করতে অভ্যন্তরীণ গবেষণা করি। এআরএম আর্কিটেকচারের দিকে অগ্রসর হওয়া পরিচালিত পরিষেবাগুলির জন্য সুবিধাজনক, কারণ এটি অর্থ সাশ্রয় করে এবং শক্তির ব্যবহার হ্রাস করে।

ARM-এর উপর নির্ভর করা ইতিমধ্যেই উপকারী প্রমাণিত হয়েছে, Apache Kafka-এর জন্য পরিচালিত পরিষেবা এবং ClickHouse-এর জন্য পরিচালিত পরিষেবা উভয়ের কর্মক্ষমতা এবং খরচ দক্ষতার উন্নতি করেছে৷ এই গবেষণাটি আমাদের পরীক্ষার ম্যাট্রিক্সকে পরিমার্জিত করতে সাহায্য করেছে, আরও অপ্টিমাইজেশনের জন্য সবচেয়ে কার্যকর পরিবেশ এবং ক্ষেত্রগুলিকে চিহ্নিত করে৷ আমরা সর্বদা এটিতে থাকি: হুডের নীচে টুইকিং এবং পরিমার্জন, এবং আমি সম্প্রদায়ের সাথে আমাদের জ্ঞান ভাগ করে নিতে পেরে খুশি। সাথে থাকুন!