🥇 অনুরোধের ব্যাচ প্রক্রিয়াকরণের সমস্যা এবং তাদের সমাধান (পর্ব 1)

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

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

প্রদর্শনী প্রকল্প

স্পষ্টতার জন্য, আমি বর্তমানে যে অ্যাপ্লিকেশনটিতে কাজ করছি তার একটি পরিষেবার উদাহরণ দেখি।

উদাহরণের জন্য প্ল্যাটফর্ম নির্বাচনের ব্যাখ্যাদুর্বল পারফরম্যান্সের সমস্যাটি বেশ সাধারণ এবং কোনও নির্দিষ্ট ভাষা বা প্ল্যাটফর্মকে প্রভাবিত করে না। এই নিবন্ধটি সমস্যা এবং সমাধান প্রদর্শন করতে স্প্রিং + কোটলিন কোড উদাহরণ ব্যবহার করবে। Kotlin জাভা এবং C# ডেভেলপারদের জন্য সমানভাবে বোধগম্য (বা বোধগম্য), উপরন্তু, কোড জাভার তুলনায় আরো কমপ্যাক্ট এবং বোধগম্য। খাঁটি জাভা ডেভেলপারদের জন্য বোঝা সহজ করার জন্য, আমি কোটলিনের কালো জাদু এড়াব এবং শুধুমাত্র সাদা জাদু ব্যবহার করব (লম্বকের চেতনায়)। কয়েকটি এক্সটেনশন পদ্ধতি থাকবে, তবে তারা প্রকৃতপক্ষে সমস্ত জাভা প্রোগ্রামারদের কাছে স্ট্যাটিক পদ্ধতি হিসাবে পরিচিত, তাই এটি একটি ছোট চিনি যা খাবারের স্বাদ নষ্ট করবে না।
একটি নথি অনুমোদন সেবা আছে. কেউ একটি নথি তৈরি করে এবং আলোচনার জন্য জমা দেয়, যার সময় সম্পাদনা করা হয়, এবং শেষ পর্যন্ত নথিতে সম্মত হয়। অনুমোদন পরিষেবা নিজেই নথি সম্পর্কে কিছুই জানে না: এটি কেবলমাত্র ছোট অতিরিক্ত ফাংশন সহ অনুমোদনকারীদের একটি চ্যাট যা আমরা এখানে বিবেচনা করব না।

সুতরাং, তাদের প্রত্যেকটিতে অংশগ্রহণকারীদের একটি পূর্বনির্ধারিত সেট সহ চ্যাট রুম (নথির সাথে সম্পর্কিত) রয়েছে। নিয়মিত চ্যাটের মতো, বার্তাগুলিতে পাঠ্য এবং ফাইল থাকে এবং উত্তর বা ফরোয়ার্ড হতে পারে:

data class ChatMessage( // nullable так как появляется только после persist val id: Long? = null, /** Ссылка на автора */ val author: UserReference, /** Сообщение */ val message: String, /** Ссылки на аттачи */ // из-за особенностей связки JPA+СУБД проще поддерживать и null, и пустые списки val files: List<FileReference>? = null, /** Если является ответом, то здесь будет оригинал */ val replyTo: ChatMessage? = null, /** Если является пересылкой, то здесь будет оригинал */ val forwardFrom: ChatMessage? = null )

ফাইল এবং ব্যবহারকারীর লিঙ্কগুলি অন্যান্য ডোমেনের লিঙ্ক। এখানে আমরা এই মত বাস করি:

typealias FileReference = Long typealias UserReference = Long
ব্যবহারকারীর ডেটা কীক্লোকে সংরক্ষণ করা হয় এবং REST এর মাধ্যমে পুনরুদ্ধার করা হয়। ফাইলগুলির ক্ষেত্রেও একই রকম হয়: ফাইল এবং সেগুলির সম্পর্কে তথ্য একটি পৃথক ফাইল স্টোরেজ পরিষেবাতে থাকে৷

এই পরিষেবাগুলিতে সমস্ত কল হয় ভারী অনুরোধ. এর মানে হল যে এই অনুরোধগুলি পরিবহনের ওভারহেড একটি তৃতীয় পক্ষের পরিষেবা দ্বারা প্রক্রিয়াকরণের জন্য যে সময় লাগে তার চেয়ে অনেক বেশি। আমাদের পরীক্ষার বেঞ্চগুলিতে, এই ধরনের পরিষেবাগুলির জন্য সাধারণ কল টাইম হল 100 ms, তাই আমরা ভবিষ্যতে এই নম্বরগুলি ব্যবহার করব৷

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

/** В таком виде отдаются ссылки на сущности для фронта */ data class ReferenceUI( /** Идентификатор для url */ val ref: String, /** Видимое пользователю название ссылки */ val name: String ) data class ChatMessageUI( val id: Long, /** Ссылка на автора */ val author: ReferenceUI, /** Сообщение */ val message: String, /** Ссылки на аттачи */ val files: List<ReferenceUI>, /** Если являтся ответом, то здесь будет оригинал */ val replyTo: ChatMessageUI? = null, /** Если являтся пересылкой, то здесь будет оригинал */ val forwardFrom: ChatMessageUI? = null )

আমাদের নিম্নলিখিতগুলি বাস্তবায়ন করতে হবে:

interface ChatRestApi { fun getLast(n: Int): List<ChatMessageUI> }

UI পোস্টফিক্স মানে ফ্রন্টএন্ডের জন্য DTO মডেল, অর্থাৎ REST এর মাধ্যমে আমাদের যা পরিবেশন করা উচিত।

এখানে আশ্চর্যের বিষয় হতে পারে যে আমরা কোনো চ্যাট আইডি পাস করছি না এমনকি ChatMessage/ChatMessageUI মডেলের একটিও নেই। আমি ইচ্ছাকৃতভাবে এটি করেছি যাতে উদাহরণগুলির কোড বিশৃঙ্খল না হয় (চ্যাটগুলি বিচ্ছিন্ন, তাই আমরা ধরে নিতে পারি যে আমাদের কেবল একটিই আছে)।

দার্শনিক ডিগ্রেশনChatMessageUI ক্লাস এবং ChatRestApi.getLast উভয় পদ্ধতিই তালিকা ডেটা টাইপ ব্যবহার করে যখন প্রকৃতপক্ষে এটি একটি অর্ডার করা সেট। এটি JDK-তে খারাপ, তাই ইন্টারফেস স্তরে উপাদানগুলির ক্রম ঘোষণা করা (সংযোজন এবং সরানোর সময় ক্রম সংরক্ষণ করা) কাজ করবে না। সুতরাং অর্ডার করা সেটের প্রয়োজন হয় এমন ক্ষেত্রে একটি তালিকা ব্যবহার করা সাধারণ অভ্যাস হয়ে উঠেছে (একটি লিঙ্কডহ্যাশসেটও রয়েছে, তবে এটি একটি ইন্টারফেস নয়)।
গুরুত্বপূর্ণ সীমাবদ্ধতা: আমরা অনুমান করব যে উত্তর বা স্থানান্তরের কোন দীর্ঘ চেইন নেই। অর্থাৎ, তারা বিদ্যমান, কিন্তু তাদের দৈর্ঘ্য তিনটি বার্তা অতিক্রম করে না। বার্তাগুলির সম্পূর্ণ চেইনটি অবশ্যই ফ্রন্টএন্ডে প্রেরণ করা উচিত।

বাহ্যিক পরিষেবাগুলি থেকে ডেটা গ্রহণ করতে নিম্নলিখিত APIগুলি রয়েছে:

interface ChatMessageRepository { fun findLast(n: Int): List<ChatMessage> } data class FileHeadRemote( val id: FileReference, val name: String ) interface FileRemoteApi { fun getHeadById(id: FileReference): FileHeadRemote fun getHeadsByIds(id: Set<FileReference>): Set<FileHeadRemote> fun getHeadsByIds(id: List<FileReference>): List<FileHeadRemote> fun getHeadsByChat(): List<FileHeadRemote> } data class UserRemote( val id: UserReference, val name: String ) interface UserRemoteApi { fun getUserById(id: UserReference): UserRemote fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> fun getUsersByIds(id: List<UserReference>): List<UserRemote> }

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

সহজ বাস্তবায়ন

নিষ্পাপ বাস্তবায়ন

আমাদের REST কন্ট্রোলারের প্রথম নির্বোধ বাস্তবায়ন বেশিরভাগ ক্ষেত্রে এইরকম কিছু দেখাবে:

class ChatRestController( private val messageRepository: ChatMessageRepository, private val userRepository: UserRemoteApi, private val fileRepository: FileRemoteApi ) : ChatRestApi { override fun getLast(n: Int) = messageRepository.findLast(n) .map { it.toFrontModel() } private fun ChatMessage.toFrontModel(): ChatMessageUI = ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = userRepository.getUserById(author).toFrontReference(), message = message, files = files?.let { files -> fileRepository.getHeadsByIds(files) .map { it.toFrontReference() } } ?: listOf(), forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }
সবকিছু খুব পরিষ্কার, এবং এটি একটি বড় প্লাস।

আমরা ব্যাচ প্রক্রিয়াকরণ ব্যবহার করি এবং ব্যাচগুলিতে একটি বহিরাগত পরিষেবা থেকে ডেটা গ্রহণ করি। কিন্তু আমাদের উৎপাদনশীলতার কি হবে?

প্রতিটি বার্তার জন্য, লেখক ক্ষেত্রের ডেটা পেতে UserRemoteApi-এ একটি কল করা হবে এবং সমস্ত সংযুক্ত ফাইল পেতে FileRemoteApi-এ একটি কল করা হবে। মনে হচ্ছে এটাই। ধরা যাক যে ChatMessage-এর ForwardFrom এবং replyTo ফিল্ডগুলি এমনভাবে প্রাপ্ত করা হয়েছে যাতে অপ্রয়োজনীয় কলের প্রয়োজন হয় না। কিন্তু সেগুলিকে ChatMessageUI-তে পরিণত করলে তা পুনরাবৃত্তি ঘটবে, অর্থাৎ কল কাউন্টারগুলি উল্লেখযোগ্যভাবে বৃদ্ধি পেতে পারে৷ যেমনটি আমরা আগে উল্লেখ করেছি, আসুন ধরে নিই যে আমাদের অনেক নেস্টিং নেই এবং চেইনটি তিনটি বার্তার মধ্যে সীমাবদ্ধ।

ফলস্বরূপ, আমরা প্রতি বার্তায় বাহ্যিক পরিষেবাগুলিতে দুই থেকে ছয়টি কল এবং বার্তাগুলির সম্পূর্ণ প্যাকেজের জন্য একটি JPA কল পাব। মোট কলের সংখ্যা 2*N+1 থেকে 6*N+1 পর্যন্ত পরিবর্তিত হবে। বাস্তব ইউনিটে এটি কত? ধরা যাক একটি পৃষ্ঠা রেন্ডার করতে 20টি বার্তা লাগে। সেগুলি পেতে, এটি 4 সেকেন্ড থেকে 10 সেকেন্ড পর্যন্ত লাগবে। ভয়ানক! আমি এটি 500 ms এর মধ্যে রাখতে চাই। এবং যেহেতু তারা ফ্রন্টএন্ডে নির্বিঘ্ন স্ক্রলিং করার স্বপ্ন দেখেছিল, তাই এই শেষ পয়েন্টের জন্য কর্মক্ষমতা প্রয়োজনীয়তা দ্বিগুণ করা যেতে পারে।

পেশাদাররা:

কোডটি সংক্ষিপ্ত এবং স্ব-ডকুমেন্টিং (একটি সমর্থন দলের স্বপ্ন)।
কোডটি সহজ, তাই নিজেকে পায়ে গুলি করার প্রায় কোন সুযোগ নেই।
ব্যাচ প্রসেসিং কিছু পরক মত দেখায় না এবং জৈবভাবে যুক্তিতে একত্রিত করা হয়.
যুক্তি পরিবর্তন সহজে করা হবে এবং স্থানীয় হবে.

কম:

খুব ছোট প্যাকেটের কারণে ভয়ঙ্কর কর্মক্ষমতা।

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

নিষ্পাপ সমান্তরাল প্রক্রিয়াকরণ

আপনি সমান্তরালভাবে সমস্ত বার্তা প্রক্রিয়াকরণ শুরু করতে পারেন - এটি আপনাকে বার্তাগুলির সংখ্যার উপর নির্ভর করে সময়ের রৈখিক বৃদ্ধি থেকে পরিত্রাণ পেতে দেয়। এটি একটি বিশেষভাবে ভাল পথ নয় কারণ এর ফলে বহিরাগত পরিষেবার উপর একটি বড় পিক লোড হবে৷

সমান্তরাল প্রক্রিয়াকরণ বাস্তবায়ন করা খুবই সহজ:

override fun getLast(n: Int) = messageRepository.findLast(n).parallelStream() .map { it.toFrontModel() } .collect(toList())

সমান্তরাল বার্তা প্রক্রিয়াকরণ ব্যবহার করে, আমরা আদর্শভাবে 300-700 ms পাই, যা একটি নিষ্পাপ বাস্তবায়নের তুলনায় অনেক ভালো, কিন্তু এখনও যথেষ্ট দ্রুত নয়।

এই পদ্ধতির সাথে, userRepository এবং fileRepository-এর অনুরোধগুলি সিঙ্ক্রোনাসভাবে কার্যকর করা হবে, যা খুব কার্যকর নয়। এটি ঠিক করার জন্য, আপনাকে কল লজিক অনেক পরিবর্তন করতে হবে। উদাহরণস্বরূপ, CompletionStage এর মাধ্যমে (ওরফে Completable Future):

private fun ChatMessage.toFrontModel(): ChatMessageUI = CompletableFuture.supplyAsync { userRepository.getUserById(author).toFrontReference() }.thenCombine( files?.let { CompletableFuture.supplyAsync { fileRepository.getHeadsByIds(files).map { it.toFrontReference() } } } ?: CompletableFuture.completedFuture(listOf()) ) { author, files -> ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = author, message = message, files = files, forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }.get()!!

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

আপনি coroutines ব্যবহার করলে, সবকিছু আরো শালীন দেখাবে:

private fun ChatMessage.toFrontModel(): ChatMessageUI = join( { userRepository.getUserById(author).toFrontReference() }, { files?.let { fileRepository.getHeadsByIds(files) .map { it.toFrontReference() } } ?: listOf() } ).let { (author, files) -> ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = author, message = message, files = files, forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }

যেখানে:

fun <A, B> join(a: () -> A, b: () -> B) = runBlocking(IO) { awaitAll(async { a() }, async { b() }) }.let { it[0] as A to it[1] as B }

তাত্ত্বিকভাবে, এই ধরনের সমান্তরাল প্রক্রিয়াকরণ ব্যবহার করে, আমরা 200-400 ms পাব, যা ইতিমধ্যেই আমাদের প্রত্যাশার কাছাকাছি।

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

এই ধরনের একটি পরিষেবা ব্যবহার করার সময় আমার ফলাফল হল 1300টি বার্তা প্রক্রিয়াকরণের জন্য 1700-20 ms। এটি প্রথম বাস্তবায়নের তুলনায় দ্রুত, কিন্তু এখনও সমস্যার সমাধান করে না।

সমান্তরাল প্রশ্নের বিকল্প ব্যবহারযদি তৃতীয় পক্ষের পরিষেবাগুলি ব্যাচ প্রক্রিয়াকরণ প্রদান না করে? উদাহরণস্বরূপ, আপনি ইন্টারফেস পদ্ধতির ভিতরে ব্যাচ প্রক্রিয়াকরণ বাস্তবায়নের অভাব লুকাতে পারেন:

interface UserRemoteApi { fun getUserById(id: UserReference): UserRemote fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> = id.parallelStream() .map { getUserById(it) }.collect(toSet()) fun getUsersByIds(id: List<UserReference>): List<UserRemote> = id.parallelStream() .map { getUserById(it) }.collect(toList()) }

আপনি যদি ভবিষ্যতের সংস্করণগুলিতে ব্যাচ প্রক্রিয়াকরণ দেখতে আশা করেন তবে এটি বোঝা যায়।
পেশাদাররা:

সহজে বার্তা-ভিত্তিক সমান্তরাল প্রক্রিয়াকরণ বাস্তবায়ন.
ভাল মাপযোগ্যতা.

কনস:

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

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

ক্যাশিং

আপনি বাহ্যিক পরিষেবাগুলির জন্য JPA-এর স্পিরিটে ক্যাশিং করতে পারেন, অর্থাৎ, প্রাপ্ত বস্তুগুলিকে একটি সেশনের মধ্যে সংরক্ষণ করুন যাতে সেগুলি আবার না পাওয়া যায় (ব্যাচ প্রক্রিয়াকরণের সময় সহ)। আপনি নিজে এই ধরনের ক্যাশে তৈরি করতে পারেন, আপনি স্প্রিংকে এর @Cacheable দিয়ে ব্যবহার করতে পারেন, এছাড়াও আপনি সবসময় EhCache-এর মতো তৈরি ক্যাশে ম্যানুয়ালি ব্যবহার করতে পারেন।

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

ইন্টারসেসন (দীর্ঘ) ক্যাশে জটিল অবৈধকরণ যুক্তি প্রয়োজন। সাধারণভাবে, আপনি যত পরে ইন্টারসেশন ক্যাশে ব্যবহার করে পারফরম্যান্স সমস্যা সমাধানে নামবেন, ততই ভালো।

পেশাদাররা:

কোড পরিবর্তন না করে ক্যাশিং প্রয়োগ করুন।
উত্পাদনশীলতা কয়েকবার বৃদ্ধি পেয়েছে (কিছু ক্ষেত্রে)।

কনস:

ভুলভাবে ব্যবহার করা হলে কর্মক্ষমতা হ্রাসের সম্ভাবনা।
বড় মেমরি ওভারহেড, বিশেষ করে দীর্ঘ ক্যাশে সহ।
জটিল অবৈধতা, ত্রুটি যা রানটাইমে হার্ড-টু-রিপ্রোডিউস সমস্যার দিকে পরিচালিত করবে।

খুব প্রায়ই, ক্যাশে শুধুমাত্র নকশা সমস্যা দ্রুত প্যাচ আপ করতে ব্যবহার করা হয়. এর অর্থ এই নয় যে তাদের ব্যবহার করা উচিত নয়। যাইহোক, আপনার সর্বদা তাদের সাথে সাবধানতার সাথে আচরণ করা উচিত এবং প্রথমে ফলাফলের কার্যকারিতা লাভের মূল্যায়ন করা উচিত এবং শুধুমাত্র তারপর একটি সিদ্ধান্ত নেওয়া উচিত।

আমাদের উদাহরণে, ক্যাশে প্রায় 25% কার্যক্ষমতা বৃদ্ধি প্রদান করবে। একই সময়ে, ক্যাশেগুলির অনেক অসুবিধা রয়েছে, তাই আমি সেগুলি এখানে ব্যবহার করব না।

ফলাফল

সুতরাং, আমরা ব্যাচ প্রসেসিং ব্যবহার করে এমন একটি পরিষেবার নিষ্পাপ বাস্তবায়নের দিকে তাকিয়েছি এবং এটিকে গতি বাড়ানোর কিছু সহজ উপায়।

এই সমস্ত পদ্ধতির প্রধান সুবিধা হল সরলতা, যা থেকে অনেক আনন্দদায়ক পরিণতি রয়েছে।

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

দুটি প্রধান দিক রয়েছে যেখানে আপনি সমাধানগুলি সন্ধান করতে পারেন:

ডেটা সহ অ্যাসিঙ্ক্রোনাস কাজ (একটি প্যারাডাইম পরিবর্তনের প্রয়োজন, তাই এই নিবন্ধে আলোচনা করা হয়নি);
সিঙ্ক্রোনাস প্রক্রিয়াকরণ বজায় রাখার সময় ব্যাচের পরিবর্ধন।

ব্যাচ বর্ধিত করা বাহ্যিক কলের সংখ্যা অনেক কমিয়ে দেবে এবং একই সাথে কোডটি সিঙ্ক্রোনাস রাখবে। নিবন্ধের পরবর্তী অংশ এই বিষয়ে নিবেদিত করা হবে.

উত্স: www.habr.com

ব্যাচ কোয়েরি প্রক্রিয়াকরণের সমস্যা এবং তাদের সমাধান (পর্ব 1)