બેચ ક્વેરી પ્રોસેસિંગની સમસ્યાઓ અને તેના ઉકેલો (ભાગ 1)

લગભગ તમામ આધુનિક સોફ્ટવેર ઉત્પાદનોમાં ઘણી સેવાઓનો સમાવેશ થાય છે. ઘણીવાર, ઇન્ટરસર્વિસ ચેનલોનો લાંબો પ્રતિસાદ સમય પ્રદર્શન સમસ્યાઓનો સ્ત્રોત બની જાય છે. આ પ્રકારની સમસ્યાનો પ્રમાણભૂત ઉકેલ એ એક પેકેજમાં બહુવિધ ઇન્ટરસર્વિસ વિનંતીઓને પેક કરવાનો છે, જેને બેચિંગ કહેવામાં આવે છે.

જો તમે બેચ પ્રોસેસિંગનો ઉપયોગ કરો છો, તો તમે પ્રદર્શન અથવા કોડ સ્પષ્ટતાના સંદર્ભમાં પરિણામોથી ખુશ ન હોઈ શકો. આ પદ્ધતિ કૉલર પર એટલી સરળ નથી જેટલી તમે વિચારી શકો છો. વિવિધ હેતુઓ માટે અને વિવિધ પરિસ્થિતિઓમાં, ઉકેલો મોટા પ્રમાણમાં બદલાઈ શકે છે. ચોક્કસ ઉદાહરણોનો ઉપયોગ કરીને, હું અનેક અભિગમોના ગુણદોષ બતાવીશ.

પ્રદર્શન પ્રોજેક્ટ

સ્પષ્ટતા માટે, ચાલો હું હાલમાં જે એપ્લિકેશન પર કામ કરું છું તેમાંની એક સેવાનું ઉદાહરણ જોઈએ.

ઉદાહરણો માટે પ્લેટફોર્મ પસંદગીની સમજૂતીનબળા પ્રદર્શનની સમસ્યા એકદમ સામાન્ય છે અને તે કોઈ ચોક્કસ ભાષાઓ અથવા પ્લેટફોર્મને અસર કરતી નથી. સમસ્યાઓ અને ઉકેલો દર્શાવવા માટે આ લેખ સ્પ્રિંગ + કોટલિન કોડ ઉદાહરણોનો ઉપયોગ કરશે. કોટલિન Java અને C# વિકાસકર્તાઓ માટે સમાન રીતે સમજી શકાય તેવું (અથવા અગમ્ય) છે, વધુમાં, કોડ જાવા કરતાં વધુ કોમ્પેક્ટ અને સમજી શકાય તેવું છે. શુદ્ધ Java વિકાસકર્તાઓ માટે સમજવામાં સરળતા બનાવવા માટે, હું કોટલિનના કાળા જાદુને ટાળીશ અને માત્ર સફેદ જાદુનો ઉપયોગ કરીશ (લોમ્બોકની ભાવનામાં). ત્યાં થોડી એક્સ્ટેંશન પદ્ધતિઓ હશે, પરંતુ તે વાસ્તવમાં જાવા પ્રોગ્રામરોને સ્થિર પદ્ધતિઓ તરીકે પરિચિત છે, તેથી આ એક નાની ખાંડ હશે જે વાનગીનો સ્વાદ બગાડે નહીં.
દસ્તાવેજ મંજૂરી સેવા છે. કોઈ વ્યક્તિ દસ્તાવેજ બનાવે છે અને તેને ચર્ચા માટે સબમિટ કરે છે, જે દરમિયાન સંપાદનો કરવામાં આવે છે, અને આખરે દસ્તાવેજ પર સંમત થાય છે. મંજૂરી સેવા પોતે દસ્તાવેજો વિશે કંઈપણ જાણતી નથી: તે ફક્ત નાના વધારાના કાર્યો સાથે મંજૂરી આપનારાઓની ચેટ છે જેને અમે અહીં ધ્યાનમાં લઈશું નહીં.

તેથી, તેમાંના દરેકમાં સહભાગીઓના પૂર્વવ્યાખ્યાયિત સમૂહ સાથે ચેટ રૂમ (દસ્તાવેજોને અનુરૂપ) છે. નિયમિત ચેટ્સની જેમ, સંદેશામાં ટેક્સ્ટ અને ફાઇલો હોય છે અને તે જવાબો અથવા ફોરવર્ડ હોઈ શકે છે:

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 છે, તેથી અમે ભવિષ્યમાં આ નંબરોનો ઉપયોગ કરીશું.

તમામ જરૂરી માહિતી સાથે છેલ્લા N સંદેશાઓ પ્રાપ્ત કરવા માટે અમારે એક સરળ 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 દ્વારા શું સેવા આપવી જોઈએ.

અહીં નવાઈની વાત એ છે કે અમે કોઈપણ ચેટ આઈડી પાસ કરી રહ્યા નથી અને ચેટમેસેજ/ચેટમેસેજયુઆઈ મોડલ પાસે પણ નથી. મેં આ ઇરાદાપૂર્વક કર્યું છે જેથી ઉદાહરણોના કોડમાં ગડબડ ન થાય (ચેટ્સ અલગ છે, તેથી અમે ધારી શકીએ કે અમારી પાસે ફક્ત એક જ છે).

ફિલોસોફિકલ ડિગ્રેશનChatMessageUI ક્લાસ અને ChatRestApi.getLast મેથડ બંને લિસ્ટ ડેટા પ્રકારનો ઉપયોગ કરે છે જ્યારે હકીકતમાં તે ઓર્ડર કરેલ સેટ હોય. JDK માં આ ખરાબ છે, તેથી ઇન્ટરફેસ સ્તરે તત્વોનો ક્રમ જાહેર કરવો (ઉમેરો અને દૂર કરતી વખતે ઓર્ડર સાચવવો) કામ કરશે નહીં. તેથી જ્યાં ઓર્ડર કરેલ સેટની જરૂર હોય તેવા કિસ્સાઓમાં સૂચિનો ઉપયોગ કરવો તે સામાન્ય પ્રથા બની ગઈ છે (ત્યાં એક LinkedHashSet પણ છે, પરંતુ આ ઇન્ટરફેસ નથી).
મહત્વપૂર્ણ મર્યાદા: અમે માની લઈશું કે જવાબો અથવા ટ્રાન્સફરની કોઈ લાંબી સાંકળો નથી. એટલે કે, તેઓ અસ્તિત્વમાં છે, પરંતુ તેમની લંબાઈ ત્રણ સંદેશાઓ કરતાં વધી નથી. સંદેશાઓની આખી સાંકળ અગ્રભાગ પર પ્રસારિત થવી જોઈએ.

બાહ્ય સેવાઓમાંથી ડેટા પ્રાપ્ત કરવા માટે નીચેના APIs છે:

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 માટે ફોરવર્ડફ્રોમ અને રિપ્લાય ટુ ફીલ્ડ્સ એવી રીતે મેળવવામાં આવે છે કે આના માટે બિનજરૂરી કોલની જરૂર નથી. પરંતુ તેમને ChatMessageUI માં ફેરવવાથી પુનરાવર્તિત થશે, એટલે કે, કૉલ કાઉન્ટર્સ નોંધપાત્ર રીતે વધી શકે છે. જેમ આપણે અગાઉ નોંધ્યું છે તેમ, ચાલો ધારીએ કે આપણી પાસે વધુ માળો નથી અને સાંકળ ત્રણ સંદેશાઓ સુધી મર્યાદિત છે.

પરિણામે, અમને સંદેશ દીઠ બાહ્ય સેવાઓ માટે બે થી છ કૉલ્સ અને સંદેશાના સમગ્ર પેકેજ માટે એક JPA કૉલ મળશે. કૉલ્સની કુલ સંખ્યા 2*N+1 થી 6*N+1 સુધી બદલાશે. વાસ્તવિક એકમોમાં આ કેટલું છે? ચાલો કહીએ કે એક પૃષ્ઠને રેન્ડર કરવા માટે 20 સંદેશાઓ લે છે. તેમને પ્રાપ્ત કરવા માટે, તે 4 થી 10 સેકંડ સુધી લેશે. ભયંકર! હું તેને 500 ms ની અંદર રાખવા માંગુ છું. અને તેઓ ફ્રન્ટએન્ડમાં સીમલેસ સ્ક્રોલિંગ બનાવવાનું સપનું જોતા હોવાથી, આ એન્ડપોઇન્ટ માટેની કામગીરીની જરૂરિયાતો બમણી કરી શકાય છે.

ગુણ:

1. કોડ સંક્ષિપ્ત અને સ્વ-દસ્તાવેજીકૃત છે (સપોર્ટ ટીમનું સ્વપ્ન).
2. કોડ સરળ છે, તેથી તમારી જાતને પગમાં મારવાની લગભગ કોઈ તકો નથી.
3. બેચ પ્રોસેસિંગ એ એલિયન જેવું લાગતું નથી અને તે તર્કમાં ઓર્ગેનિકલી એકીકૃત છે.
4. તર્કમાં ફેરફાર સરળતાથી કરવામાં આવશે અને તે સ્થાનિક હશે.

માઈનસ:

ખૂબ જ નાના પેકેટોને કારણે ભયાનક કામગીરી.

આ અભિગમ સામાન્ય સેવાઓ અથવા પ્રોટોટાઇપ્સમાં ઘણી વાર જોઇ શકાય છે. જો ફેરફારો કરવાની ગતિ મહત્વપૂર્ણ છે, તો તે સિસ્ટમને જટિલ બનાવવા માટે ભાગ્યે જ યોગ્ય છે. તે જ સમયે, અમારી ખૂબ જ સરળ સેવા માટે પ્રદર્શન ભયંકર છે, તેથી આ અભિગમની લાગુ થવાનો અવકાશ ખૂબ જ સાંકડો છે.

નિષ્કપટ સમાંતર પ્રક્રિયા

તમે બધા સંદેશાઓ પર સમાંતર પ્રક્રિયા કરવાનું શરૂ કરી શકો છો - આ તમને સંદેશાઓની સંખ્યાના આધારે સમયના રેખીય વધારાથી છુટકારો મેળવવાની મંજૂરી આપશે. આ ખાસ કરીને સારો રસ્તો નથી કારણ કે તે બાહ્ય સેવા પર મોટા પીક લોડમાં પરિણમશે.

સમાંતર પ્રક્રિયા અમલમાં મૂકવી ખૂબ જ સરળ છે:

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()!!

તે જોઈ શકાય છે કે શરૂઆતમાં સરળ મેપિંગ કોડ ઓછા સમજી શકાય તેવું બની ગયું છે. આ એટલા માટે છે કારણ કે અમારે જ્યાંથી પરિણામોનો ઉપયોગ કરવામાં આવે છે ત્યાંથી બાહ્ય સેવાઓના કૉલ્સને અલગ કરવા પડ્યા હતા. આ પોતે ખરાબ નથી. પરંતુ કોલ્સનું સંયોજન ખૂબ ભવ્ય લાગતું નથી અને તે એક લાક્ષણિક પ્રતિક્રિયાશીલ "નૂડલ" જેવું લાગે છે.

જો તમે કોરોટીન્સનો ઉપયોગ કરો છો, તો બધું વધુ યોગ્ય દેખાશે:

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 s પર પાછા આવશે.

આવી સેવાનો ઉપયોગ કરતી વખતે મારું પરિણામ 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())
}

જો તમે ભવિષ્યના સંસ્કરણોમાં બેચ પ્રોસેસિંગ જોવાની આશા રાખતા હોવ તો આનો અર્થ થાય છે.
ગુણ:

1. સંદેશ-આધારિત સમાંતર પ્રક્રિયાને સરળતાથી લાગુ કરો.
2. સારી માપનીયતા.

વિપક્ષ:

1. સમાંતર વિવિધ સેવાઓની વિનંતીઓ પર પ્રક્રિયા કરતી વખતે તેની પ્રક્રિયામાંથી ડેટા સંપાદનને અલગ કરવાની જરૂરિયાત.
2. તૃતીય-પક્ષ સેવાઓ પર ભાર વધારો.

તે જોઈ શકાય છે કે લાગુ પડવાનો અવકાશ લગભગ નિષ્કપટ અભિગમ જેટલો જ છે. જો તમે અન્ય લોકોના નિર્દય શોષણને કારણે તમારી સેવાના પ્રદર્શનને ઘણી વખત વધારવા માંગતા હોવ તો સમાંતર વિનંતી પદ્ધતિનો ઉપયોગ કરવો તે અર્થપૂર્ણ છે. અમારા ઉદાહરણમાં, પ્રદર્શનમાં 2,5 ગણો વધારો થયો છે, પરંતુ આ સ્પષ્ટપણે પૂરતું નથી.

કેશીંગ

તમે બાહ્ય સેવાઓ માટે JPA ની ભાવનામાં કેશીંગ કરી શકો છો, એટલે કે, પ્રાપ્ત વસ્તુઓને સત્રની અંદર સ્ટોર કરી શકો છો જેથી કરીને તેને ફરીથી પ્રાપ્ત ન થાય (બેચ પ્રોસેસિંગ દરમિયાન સહિત). તમે આવા કેશ જાતે બનાવી શકો છો, તમે તેના @Cacheable સાથે સ્પ્રિંગનો ઉપયોગ કરી શકો છો, ઉપરાંત તમે હંમેશા EhCache જેવી તૈયાર કેશનો જાતે ઉપયોગ કરી શકો છો.

એક સામાન્ય સમસ્યા એ હશે કે કેશ હિટ હોય તો જ ઉપયોગી છે. અમારા કિસ્સામાં, લેખક ક્ષેત્ર પર હિટ થવાની સંભાવના છે (ચાલો કહીએ, 50%), પરંતુ ફાઇલો પર બિલકુલ હિટ થશે નહીં. આ અભિગમ કેટલાક સુધારાઓ પ્રદાન કરશે, પરંતુ તે પ્રભાવમાં ધરમૂળથી ફેરફાર કરશે નહીં (અને અમને સફળતાની જરૂર છે).

ઇન્ટરસેસન (લાંબા) કેશને જટિલ અમાન્યતા તર્કની જરૂર છે. સામાન્ય રીતે, તમે ઈન્ટરસેસન કેશનો ઉપયોગ કરીને પર્ફોર્મન્સ સમસ્યાઓ ઉકેલવા માટે જેટલી પાછળથી નીચે આવશો, તેટલું સારું.

ગુણ:

1. કોડ બદલ્યા વિના કેશીંગનો અમલ કરો.
2. ઉત્પાદકતામાં ઘણી વખત વધારો (કેટલાક કિસ્સાઓમાં).

વિપક્ષ:

1. જો ખોટી રીતે ઉપયોગ કરવામાં આવે તો કામગીરીમાં ઘટાડો થવાની શક્યતા.
2. મોટી મેમરી ઓવરહેડ, ખાસ કરીને લાંબા કેશ સાથે.
3. જટિલ અમાન્યતા, ભૂલો જેમાં રનટાઈમમાં પુનઃઉત્પાદન કરવા માટે મુશ્કેલ સમસ્યાઓ તરફ દોરી જશે.

ઘણી વાર, કેશનો ઉપયોગ ફક્ત ડિઝાઇન સમસ્યાઓને ઝડપથી પેચ કરવા માટે થાય છે. આનો અર્થ એ નથી કે તેનો ઉપયોગ થવો જોઈએ નહીં. જો કે, તમારે હંમેશા તેમની સાથે સાવધાનીપૂર્વક વર્તવું જોઈએ અને પ્રથમ પરિણામી પરફોર્મન્સ ગેઈનનું મૂલ્યાંકન કરવું જોઈએ અને પછી જ નિર્ણય લેવો જોઈએ.

અમારા ઉદાહરણમાં, કેશ લગભગ 25% નો પ્રભાવ વધારો પ્રદાન કરશે. તે જ સમયે, કેશમાં ઘણા બધા ગેરફાયદા છે, તેથી હું તેનો અહીં ઉપયોગ કરીશ નહીં.

પરિણામો

તેથી, અમે બેચ પ્રોસેસિંગનો ઉપયોગ કરતી સેવાના નિષ્કપટ અમલીકરણ અને તેને ઝડપી બનાવવાની કેટલીક સરળ રીતો પર ધ્યાન આપ્યું.

આ બધી પદ્ધતિઓનો મુખ્ય ફાયદો એ સરળતા છે, જેમાંથી ઘણા સુખદ પરિણામો છે.

આ પદ્ધતિઓની સામાન્ય સમસ્યા એ નબળી કામગીરી છે, મુખ્યત્વે પેકેટોના કદને કારણે. તેથી, જો આ ઉકેલો તમને અનુકૂળ ન આવે, તો તે વધુ આમૂલ પદ્ધતિઓ ધ્યાનમાં લેવા યોગ્ય છે.

ત્યાં બે મુખ્ય દિશાઓ છે જેમાં તમે ઉકેલો શોધી શકો છો:

• ડેટા સાથે અસુમેળ કાર્ય (પેરાડાઈમ શિફ્ટની જરૂર છે, તેથી આ લેખમાં ચર્ચા કરવામાં આવી નથી);
• સિંક્રનસ પ્રોસેસિંગ જાળવી રાખતી વખતે બેચનું વિસ્તરણ.

બૅચેસનું વિસ્તરણ બાહ્ય કૉલ્સની સંખ્યામાં મોટા પ્રમાણમાં ઘટાડો કરશે અને તે જ સમયે કોડને સિંક્રનસ રાખશે. લેખનો આગળનો ભાગ આ વિષયને સમર્પિત કરવામાં આવશે.

સોર્સ: www.habr.com