ব্যাপক ব্যবহারকারী বৃদ্ধির জন্য রেলে রুবি স্কেলিং

আজ আমরা এমন কিছু কৌশল নিয়ে আলোচনা করব যা ব্যবহার করে আপনি রুবি অন রেল অ্যাপ্লিকেশনগুলিকে একটি বিশাল ব্যবহারকারী বেসে স্কেল করতে পারেন৷

অ্যাপ্লিকেশানগুলিকে স্কেল করার একটি সুস্পষ্ট উপায় হল তাদের দিকে আরও অর্থ নিক্ষেপ করা। এবং এটি আশ্চর্যজনকভাবে কাজ করে — আরও কয়েকটি সার্ভার যোগ করুন, আপনার ডাটাবেস সার্ভার আপগ্রেড করুন এবং ভয়েলা, কর্মক্ষমতা সংক্রান্ত অনেক সমস্যা poof চলে যায় !

কিন্তু প্রায়ই আরও সার্ভার যোগ না করে অ্যাপ্লিকেশন স্কেল করা সম্ভব। সেটাই আজ আমরা আলোচনা করব।

চলুন চলুন!

আপনার রেল অ্যাপ্লিকেশনের জন্য AppSignal ব্যবহার করুন

আমরা স্কেলিং এবং কর্মক্ষমতা অপ্টিমাইজেশানে ডুব দেওয়ার আগে, আপনাকে প্রথমে if সনাক্ত করতে হবে আপনাকে এটি করতে হবে, আপনার অ্যাপ্লিকেশনে কী কী বাধা রয়েছে এবং কোন সংস্থানগুলিকে স্কেল করা যেতে পারে৷

এটি করার একটি সহজ উপায় হল রুবির জন্য AppSignal-এর কর্মক্ষমতা পর্যবেক্ষণ এবং মেট্রিক্স ব্যবহার করা৷

পারফরম্যান্স ড্যাশবোর্ড আপনাকে সঠিক কন্ট্রোলার অ্যাকশন এবং ব্যাকগ্রাউন্ডের কাজগুলি চিহ্নিত করতে সাহায্য করে যা গড়ে ধীর হয়৷

উদাহরণস্বরূপ, এখানে একটি কর্মক্ষমতা ড্যাশবোর্ড কিভাবে ActiveRecord এর জন্য দেখতে পারে:

এটি যেকোন স্কেলিং যাত্রার একটি ভাল সূচনা পয়েন্ট দেয় — আপনি আরও সার্ভার যোগ করার সিদ্ধান্ত নিন বা কোডের মাধ্যমে পারফরম্যান্স অপ্টিমাইজ করুন।

এখন চলুন সহজতম কৌশলগুলির একটিতে চলে যাই যা আপনি আপনার Rails অ্যাপকে স্কেল করতে ব্যবহার করতে পারেন — ক্যাশিং৷

রেলগুলিতে রুবিতে ক্যাশিং

ক্যাশিং আপনাকে একই জিনিসগুলি বারবার কম্পিউট করা বন্ধ করতে দেয়৷

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

আসুন ক্যাশে করা যেতে পারে এমন সমস্ত সম্ভাব্য সংস্থান দেখি।

ক্যাশিং ভিউ

ভিউ রেন্ডার করা কখনও কখনও একটি ব্যয়বহুল অপারেশন হতে পারে, বিশেষ করে যখন সেই ভিউতে প্রচুর ডেটা রেন্ডার করা হয়। এমনকি অপারেশনটি ব্যয়বহুল না হলেও, একটি পূর্ব-রেন্ডার করা ভিউ ব্যবহার করলে একই ভিউকে এক মিলিয়ন বার রেন্ডার করার বিপরীতে আপনাকে অনেক কর্মক্ষমতা দেবে৷

রেলগুলি cache ব্যবহার করে বাক্সের বাইরে এটিকে সমর্থন করে সাহায্যকারী দেখুন। উদাহরণস্বরূপ, একটি তালিকা রেন্ডার করার সময় এটি প্রতিটি পোস্টকে এইভাবে ক্যাশে করতে পারে:

এর জন্য, রেলগুলি স্বয়ংক্রিয়ভাবে প্রতিটি পোস্টকে একটি নির্দিষ্ট কী-এর অধীনে ক্যাশ করে যা টেমপ্লেট, পোস্ট আইডি এবং আপডেট টাইমস্ট্যাম্পের HTML বিষয়বস্তুর উপর নির্ভর করে৷

এই কৌশলটি সম্পর্কে আরও পড়তে, রেল এবং রেল সংগ্রহের ক্যাশিং-এ ফ্র্যাগমেন্ট ক্যাশিং পোস্টগুলি দেখুন৷

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

ক্যাশিং প্রতিক্রিয়া

ক্যাশিং ভিউ/ফ্র্যাগমেন্ট ছাড়াও, আপনি GET এর সম্পূর্ণ প্রতিক্রিয়া ক্যাশ করতেও বেছে নিতে পারেন অনুরোধ এটি If-None-Match এর মাধ্যমে সমর্থিত এবং If-Modified-Since ব্রাউজারদের পাঠানো হেডার।

যখন একটি If-None-Match অনুরোধে শিরোনাম উপস্থিত থাকে, সার্ভার একটি 304 Not Modified ফেরত দিতে পারে কোন বিষয়বস্তু ছাড়া প্রতিক্রিয়া যদি প্রতিক্রিয়াতে কোন পরিবর্তন না হয়। সার্ভার-গণনা করা Etag সেই হেডারের ভিতরের মানের সাথে তুলনা করা হয়।

একইভাবে, যদি If-Modified-Since হেডার একটি If-None-Match ছাড়াই উপস্থিত , সার্ভার একটি 304 Not Modified ফেরত দিতে পারে কোন বিষয়বস্তু ছাড়াই প্রতিক্রিয়া (যতক্ষণ না সেই তারিখ থেকে প্রতিক্রিয়া পরিবর্তিত না হয়)।

রেলগুলি নিয়ামক ক্রিয়াগুলির ভিতরে এটি করার সহজ উপায় সরবরাহ করে। আপনি সহজভাবে লিখতে পারেন:

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

ক্যাশিং মান

অবশেষে, কাঁচা মান ক্যাশে করাও সম্ভব (ক্যাশে স্টোরে সিরিয়াল করা যেতে পারে এমন যেকোনো কিছু)। এটি সাধারণত সম্পদ-নিবিড় বা ধীর ক্রিয়াকলাপের ফলাফল ক্যাশে করতে এবং সেগুলিকে আবার সম্পাদন করা এড়াতে উপযোগী৷

এই ক্যাশিং থেকে উপকৃত হতে পারে এমন একটি মান সনাক্ত করা অ্যাপ্লিকেশনের উপর অনেকটাই নির্ভর করে, তবে সাধারণত, আপনার ধীরতম ইভেন্টগুলির দিকে তাকানো আপনাকে সঠিক দিক নির্দেশ করতে সহায়তা করতে পারে৷

অবশেষে, আপনি যখন শনাক্ত করবেন কি ক্যাশে করতে হবে, তখন রেল যে APIটি এর জন্য প্রদান করে তা ব্যবহার করা খুবই সহজ:

উপরের কোডটি perform_the_slow_computation হবে শুধুমাত্র একবার এবং তারপর cache_key_with_version এর অধীনে মানটি ক্যাশে করুন চাবি পরের বার যখন একই কোড কল করা হবে, রেলগুলি প্রথমে চেক করবে আমাদের ইতিমধ্যে একটি ক্যাশে মান আছে কিনা এবং perform_the_slow_computation ট্রিগার করার পরিবর্তে সেটি ব্যবহার করবে। আবার।

এই ক্যাশিং কৌশলটির সবচেয়ে গুরুত্বপূর্ণ অংশ হল একটি ভাল ক্যাশে কী গণনা করা যা মান গণনায় ব্যবহৃত সমস্ত ইনপুটের উপর নির্ভর করে। এটি নিশ্চিত করার জন্য যে আমরা একটি পুরানো মান ব্যবহার করতে থাকি না।

ক্যাশ স্টোর

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

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

রুবি অন রেলে ব্যাকগ্রাউন্ড ওয়ার্কার্স

বেশিরভাগ অ্যাপ্লিকেশনের মেইলার, নিয়মিত ক্লিন-আপ, বা অন্য যেকোন সময়সাপেক্ষ অপারেশনের জন্য ব্যাকগ্রাউন্ড জব প্রয়োজন যাতে ব্যবহারকারীর উপস্থিত থাকার প্রয়োজন হয় না। সম্ভাবনা হল, আপনি ইতিমধ্যেই একটি ব্যাকগ্রাউন্ড কর্মী সেট আপ করেছেন৷

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

উদাহরণ বাস্তবায়ন

কাস্টম কাজ চালানোর জন্য, রেল সক্রিয় কাজের কাঠামো প্রদান করে। চলুন দেখা যাক কিভাবে আমরা এটি ব্যবহার করতে পারি একটি খুব জটিল ফিল্টারিং লজিককে একটি ব্যাকগ্রাউন্ড কাজে নিয়ে যেতে। প্রথমে, আসুন আমাদের ব্যাকগ্রাউন্ড কাজ তৈরি করি:

আমরা কন্ট্রোলার থেকে এই কাজটি এভাবে চালাতে পারি:

ডেটা গণনা এবং ফলাফল প্রদানের জন্য আমাদের কাজের জন্য অপেক্ষা করার সময় আমাদের টেমপ্লেটে একটি লোডিং সূচক রেন্ডার করতে হবে৷

কিন্তু কিভাবে আমরা আমাদের কাজ থেকে দেখার ফলাফল পেতে পারি? Turbo এটা সত্যিই সহজ করে তোলে। উদাহরণস্বরূপ, ভিউয়ের ভিতরে, আমরা turbo_stream_from ব্যবহার করে একটি নির্দিষ্ট বিজ্ঞপ্তি চ্যানেলে টার্বো-স্ট্রিম ইভেন্টগুলিতে সদস্যতা নিতে পারি .

এটি ব্যবহার করে, আসুন আমাদের টেমপ্লেটগুলি লিখি:

যেহেতু প্রাথমিক কন্ট্রোলার অ্যাকশনে ডেটা সংজ্ঞায়িত করা হয়নি, তাই আমরা শুধুমাত্র একটি লোডিং সূচক রেন্ডার করব। এখন আমাদের কাজ থেকে ফলাফল প্রদান করা যাক:

এখানে গুরুত্বপূর্ণ অংশ হল notify_completed পদ্ধতি এটি Turbo::StreamsChannel ব্যবহার করে, [user, :huge_datasets] এ একটি প্রতিস্থাপন ইভেন্ট সম্প্রচার করে বিজ্ঞপ্তি স্ট্রীম যা আমরা আমাদের ভিউ থেকে সাবস্ক্রাইব করেছি।

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

দ্রষ্টব্য :

আপনার রুবি অন রেল অ্যাপ্লিকেশনে একটি ডাটাবেস স্কেলিং

শেষ স্কেলযোগ্য সম্পদ যা আমরা এই পোস্টে আলোচনা করব তা হল ডাটাবেস। ডাটাবেসগুলি বেশিরভাগ অ্যাপ্লিকেশনের মূল গঠন করে। ডেটা এবং সেই ডেটা অ্যাক্সেস করার সার্ভারের সংখ্যা বাড়ার সাথে সাথে ডেটাবেসগুলি লোড অনুভব করতে শুরু করে৷

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

ডাটাবেস স্কেল করার দ্বিতীয় বিকল্প হল একাধিক ডাটাবেস ব্যবহার করে অথবা আপনার ডাটাবেস শার্ড করে অনুভূমিকভাবে স্কেল করা। এই সম্পর্কে আরও বিস্তারিত জানার জন্য সক্রিয় রেকর্ড সহ একাধিক ডেটাবেস দেখুন৷

পরিবর্তে, আমরা PostgreSQL দেখে আপনার ডাটাবেসের কর্মক্ষমতা অপ্টিমাইজ করার উপর ফোকাস করব।

PostgreSQL-এ সময়-সাপেক্ষ প্রশ্নগুলি খুঁজুন

প্রথমত, আমাদের সবচেয়ে বেশি সময়সাপেক্ষ প্রশ্নগুলি চিহ্নিত করতে হবে। আমরা যেভাবে করতে পারি তা হল pg_stat_statements প্রশ্ন করা টেবিল যা সার্ভারে নির্বাহিত সমস্ত SQL স্টেটমেন্টের পরিসংখ্যান ধারণ করে। চলুন দেখি কিভাবে আমরা সর্বোচ্চ রান টাইম সহ শীর্ষ 100টি প্রশ্ন খুঁজে পেতে পারি:

এটি কোয়েরি, কলের সংখ্যা এবং এই কোয়েরির গড় রান টাইম ফেরত দেবে। আপনি যেগুলিকে দ্রুততর হতে পারে বলে মনে করেন সেগুলি খুঁজে বের করার চেষ্টা করুন এবং কেন তারা ধীর ছিল তা বিশ্লেষণ করুন৷

এছাড়াও আপনি EXPLAIN চালাতে পারেন অথবা EXPLAIN ANALYZE ক্যোয়ারী প্ল্যান এবং প্রকৃত এক্সিকিউশন বিশদ দেখতে ক্যোয়ারীতে, যথাক্রমে।

ফলাফলের জন্য সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলির মধ্যে একটি হল Seq Scan , যা নির্দেশ করে যে পোস্টগ্রেসকে ক্যোয়ারী চালানোর জন্য ক্রমানুসারে সমস্ত রেকর্ডের মধ্য দিয়ে যেতে হবে। যদি এটি ঘটে থাকে, আপনার ফিল্টার করা কলামগুলিতে একটি সূচী যোগ করে সেই অনুক্রমিক স্ক্যানটিকে বাইপাস করার চেষ্টা করুন৷

সর্বাধিক অনুক্রমিক স্ক্যান সহ টেবিলগুলি

আরেকটি দরকারী ক্যোয়ারী যা আমি চালাতে চাই তা হল একটি টেবিলের বিপরীতে চালানো ক্রমিক স্ক্যানের মোট সংখ্যা খুঁজে পাওয়া:

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

সূচী ব্যবহার

আপনি এই ক্যোয়ারীটি চালিয়ে সূচক ব্যবহার সম্পর্কে পরিসংখ্যানও খুঁজে পেতে পারেন:

এটি প্রতিটি টেবিলের জন্য সূচক ব্যবহারের শতাংশ প্রদান করে। কম সংখ্যার মানে হল যে আপনি সেই টেবিলে কিছু সূচী হারিয়েছেন।

রেপ আপ

এই পোস্টে, আমরা ক্যাশিং এবং ব্যাকগ্রাউন্ড কর্মীদের সহ আপনার রুবি অন রেল অ্যাপ্লিকেশনগুলিকে স্কেল করার জন্য বেশ কয়েকটি কৌশল অন্বেষণ করেছি। আমরা আপনার PostgreSQL ডাটাবেসের কর্মক্ষমতা অপ্টিমাইজ করার দিকেও নজর দিয়েছি।

রেলগুলি আপনার অ্যাপ্লিকেশনে কার্যক্ষমতা অপ্টিমাইজেশানের বেশ কয়েকটি স্তর যুক্ত করা সত্যিই সহজ করে তোলে৷

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

শুভ কোডিং!

পি.এস. আপনি যদি রুবি ম্যাজিক পোস্টগুলি প্রেস থেকে বের হওয়ার সাথে সাথে পড়তে চান তবে আমাদের রুবি ম্যাজিক নিউজলেটারে সাবস্ক্রাইব করুন এবং একটি পোস্ট মিস করবেন না!