રિસોર્સ મેનેજમેન્ટમાં નિપુણતા: જાવાસ્ક્રિપ્ટ 'using' સ્ટેટમેન્ટ અને રિસોર્સ પૂલિંગ વ્યૂહરચના

ઉચ્ચ-પ્રદર્શન સર્વર-સાઇડ જાવાસ્ક્રિપ્ટની દુનિયામાં, ખાસ કરીને Node.js અને Deno જેવા વાતાવરણમાં, કાર્યક્ષમ રિસોર્સ મેનેજમેન્ટ માત્ર એક શ્રેષ્ઠ પ્રથા નથી; તે સ્કેલેબલ, સ્થિતિસ્થાપક અને ખર્ચ-અસરકારક એપ્લિકેશનો બનાવવા માટે એક મહત્વપૂર્ણ ઘટક છે. ડેવલપર્સ ઘણીવાર ડેટાબેઝ કનેક્શન્સ, ફાઇલ હેન્ડલ્સ, નેટવર્ક સોકેટ્સ અથવા વર્કર થ્રેડ્સ જેવા મર્યાદિત, બનાવવા માટે ખર્ચાળ સંસાધનોના સંચાલન સાથે સંઘર્ષ કરે છે. આ સંસાધનોનું ખોટું સંચાલન સમસ્યાઓની હારમાળા તરફ દોરી શકે છે: મેમરી લીક, કનેક્શનની થકાવટ, સિસ્ટમ અસ્થિરતા અને પ્રદર્શનમાં ઘટાડો.

પરંપરાગત રીતે, ડેવલપર્સે સંસાધનો સાફ થાય તેની ખાતરી કરવા માટે try...catch...finally બ્લોક પર આધાર રાખ્યો છે. અસરકારક હોવા છતાં, આ પેટર્ન વર્બોઝ અને ભૂલ-સંભવિત હોઈ શકે છે. બીજી બાજુ, પ્રદર્શન માટે, અમે આ અસ્કયામતોને સતત બનાવવા અને નષ્ટ કરવાના ઓવરહેડને ટાળવા માટે રિસોર્સ પૂલિંગનો ઉપયોગ કરીએ છીએ. પરંતુ આપણે ગેરંટીકૃત ક્લીનઅપની સલામતીને રિસોર્સ પુનઃઉપયોગની કાર્યક્ષમતા સાથે સુંદર રીતે કેવી રીતે જોડી શકીએ? જવાબ બે ખ્યાલો વચ્ચેના શક્તિશાળી સમન્વયમાં રહેલો છે: અન્ય ભાષાઓમાં જોવા મળતા using સ્ટેટમેન્ટની યાદ અપાવે તેવી પેટર્ન અને રિસોર્સ પૂલિંગની સાબિત વ્યૂહરચના.

આ વ્યાપક માર્ગદર્શિકા આધુનિક જાવાસ્ક્રિપ્ટમાં એક મજબૂત રિસોર્સ મેનેજમેન્ટ વ્યૂહરચના કેવી રીતે બનાવવી તે શોધશે. અમે સ્પષ્ટ રિસોર્સ મેનેજમેન્ટ માટે આગામી TC39 પ્રસ્તાવમાં ઊંડાણપૂર્વક જઈશું, જે using અને await using કીવર્ડ્સ રજૂ કરે છે, અને શક્તિશાળી અને જાળવવા માટે સરળ બંને હોય તેવી એપ્લિકેશનો બનાવવા માટે આ સ્વચ્છ, ડિક્લેરેટિવ સિન્ટેક્સને કસ્ટમ રિસોર્સ પૂલ સાથે કેવી રીતે એકીકૃત કરવું તે દર્શાવીશું.

મુખ્ય સમસ્યાને સમજવી: જાવાસ્ક્રિપ્ટમાં રિસોર્સ મેનેજમેન્ટ

આપણે કોઈ ઉકેલ બનાવીએ તે પહેલાં, સમસ્યાની સૂક્ષ્મતાને સમજવી મહત્વપૂર્ણ છે. આ સંદર્ભમાં 'રિસોર્સ' બરાબર શું છે, અને તેનું સંચાલન કરવું સાદી મેમરીનું સંચાલન કરવા કરતાં શા માટે અલગ છે?

'રિસોર્સ' શું છે?

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

• ડેટાબેઝ કનેક્શન્સ: ડેટાબેઝ સાથે કનેક્શન સ્થાપિત કરવામાં નેટવર્ક હેન્ડશેક, ઓથેન્ટિકેશન અને સેશન સેટઅપનો સમાવેશ થાય છે, જે બધા સમય અને CPU સાયકલનો વપરાશ કરે છે.
• ફાઇલ હેન્ડલ્સ: ઓપરેટિંગ સિસ્ટમ્સ કોઈ પ્રક્રિયા એકસાથે કેટલી ફાઇલો ખોલી શકે તેની સંખ્યા મર્યાદિત કરે છે. લીક થયેલ ફાઇલ હેન્ડલ્સ એપ્લિકેશનને નવી ફાઇલો ખોલવાથી રોકી શકે છે.
• નેટવર્ક સોકેટ્સ: બાહ્ય APIs, મેસેજ ક્યુઝ અથવા અન્ય માઇક્રોસર્વિસિસ સાથેના કનેક્શન્સ.
• વર્કર થ્રેડ્સ અથવા ચાઇલ્ડ પ્રોસેસિસ: હેવીવેઇટ કોમ્પ્યુટેશનલ રિસોર્સિસ કે જે પ્રોસેસ ક્રિએશન ઓવરહેડને ટાળવા માટે પૂલમાં મેનેજ કરવા જોઈએ.

ગાર્બેજ કલેક્ટર શા માટે પૂરતો નથી

સિસ્ટમ્સ પ્રોગ્રામિંગમાં નવા ડેવલપર્સમાં એક સામાન્ય ગેરસમજ એ છે કે જાવાસ્ક્રિપ્ટનો ગાર્બેજ કલેક્ટર (GC) બધું સંભાળી લેશે. GC એવા ઓબ્જેક્ટ્સ દ્વારા કબજે કરેલી મેમરી પુનઃપ્રાપ્ત કરવામાં ઉત્તમ છે કે જે હવે પહોંચી શકાય તેવા નથી. જો કે, તે બાહ્ય સંસાધનોનું નિર્ણાયક રીતે સંચાલન કરતું નથી.

જ્યારે ડેટાબેઝ કનેક્શનનું પ્રતિનિધિત્વ કરતો ઓબ્જેક્ટ હવે સંદર્ભિત નથી, ત્યારે GC આખરે તેની મેમરી ખાલી કરશે. પરંતુ તે ક્યારે થશે તેની કોઈ ગેરંટી આપતું નથી, કે તેને એ પણ ખબર નથી કે અંતર્ગત નેટવર્ક સોકેટને ઓપરેટિંગ સિસ્ટમમાં પાછું છોડવા અથવા કનેક્શન સ્લોટને ડેટાબેઝ સર્વર પર પાછું આપવા માટે તેને .close() પદ્ધતિને કૉલ કરવાની જરૂર છે. રિસોર્સ ક્લીનઅપ માટે GC પર આધાર રાખવાથી બિન-નિર્ણાયક વર્તન અને રિસોર્સ લીક થાય છે, જ્યાં તમારી એપ્લિકેશન જરૂરી કરતાં વધુ સમય માટે કિંમતી કનેક્શન્સ પકડી રાખે છે.

'using' સ્ટેટમેન્ટનું અનુકરણ: ડિટર્મિનિસ્ટિક ક્લીનઅપનો માર્ગ

C# (using સાથે) અને Python (with સાથે) જેવી ભાષાઓ એ ગેરંટી આપવા માટે સુંદર સિન્ટેક્સ પ્રદાન કરે છે કે રિસોર્સની ક્લીનઅપ લોજિક જેવી તે સ્કોપની બહાર જાય કે તરત જ એક્ઝિક્યુટ થાય છે. આ ખ્યાલને ડિટર્મિનિસ્ટિક રિસોર્સ મેનેજમેન્ટ કહેવાય છે. જાવાસ્ક્રિપ્ટ એક નેટિવ સોલ્યુશન મેળવવાની તૈયારીમાં છે, પરંતુ ચાલો પહેલા પરંપરાગત પદ્ધતિ જોઈએ.

ક્લાસિક અભિગમ: ધ try...finally બ્લોક

જાવાસ્ક્રિપ્ટમાં રિસોર્સ મેનેજમેન્ટ માટે હંમેશા try...finally બ્લોક મુખ્ય રહ્યો છે. finally બ્લોકમાંનો કોડ એક્ઝિક્યુટ થવાની ખાતરી છે, ભલે try બ્લોકમાંનો કોડ સફળતાપૂર્વક પૂર્ણ થાય, એરર ફેંકે, અથવા કોઈ મૂલ્ય પરત કરે.

ડેટાબેઝ કનેક્શનનું સંચાલન કરવા માટે અહીં એક સામાન્ય ઉદાહરણ છે:

            
async function getUserById(id) {
  let connection;
  try {
    connection = await getDatabaseConnection(); // Acquire resource
    const result = await connection.query('SELECT * FROM users WHERE id = ?', [id]);
    return result[0];
  } catch (error) {
    console.error("An error occurred during the query:", error);
    throw error; // Re-throw the error
  } finally {
    if (connection) {
      await connection.close(); // ALWAYS release resource
    }
  }
}

            

              
                Copy
              
            
          

આ પેટર્ન કામ કરે છે, પરંતુ તેની ખામીઓ છે:

• શબ્દાડંબર: રિસોર્સ મેળવવા અને છોડવા માટેનો બોઈલરપ્લેટ કોડ ઘણીવાર વાસ્તવિક બિઝનેસ લોજિક કરતાં મોટો હોય છે.
• ભૂલ-સંભવિત: if (connection) ચેક ભૂલી જવું અથવા finally બ્લોકમાં જ એરર્સને ખોટી રીતે હેન્ડલ કરવું સરળ છે.
• નેસ્ટિંગ જટિલતા: બહુવિધ સંસાધનોનું સંચાલન કરવાથી ઊંડા નેસ્ટેડ try...finally બ્લોક્સ બને છે, જેને ઘણીવાર "પિરામિડ ઓફ ડૂમ" તરીકે ઓળખવામાં આવે છે.

એક આધુનિક ઉકેલ: TC39 'using' ડિક્લેરેશન પ્રસ્તાવ

આ ખામીઓને દૂર કરવા માટે, TC39 સમિતિ (જે જાવાસ્ક્રિપ્ટનું માનકીકરણ કરે છે) એ સ્પષ્ટ રિસોર્સ મેનેજમેન્ટ પ્રસ્તાવને આગળ વધાર્યો છે. આ પ્રસ્તાવ, હાલમાં સ્ટેજ 3 પર છે (એટલે કે તે ECMAScript સ્ટાન્ડર્ડમાં સમાવેશ માટેનો ઉમેદવાર છે), બે નવા કીવર્ડ્સ—using અને await using—અને ઓબ્જેક્ટ્સ માટે તેમની પોતાની ક્લીનઅપ લોજિક વ્યાખ્યાયિત કરવાની એક પદ્ધતિ રજૂ કરે છે.

આ પ્રસ્તાવનો મુખ્ય ભાગ "ડિસ્પોઝેબલ" રિસોર્સનો ખ્યાલ છે. એક ઓબ્જેક્ટ જાણીતા સિમ્બોલ કી હેઠળ ચોક્કસ પદ્ધતિ લાગુ કરીને ડિસ્પોઝેબલ બને છે:

• [Symbol.dispose](): સિંક્રનસ ક્લીનઅપ લોજિક માટે.
• [Symbol.asyncDispose](): એસિંક્રનસ ક્લીનઅપ લોજિક માટે (ઉદાહરણ તરીકે, નેટવર્ક કનેક્શન બંધ કરવું).

જ્યારે તમે using અથવા await using સાથે વેરિયેબલ જાહેર કરો છો, ત્યારે જાવાસ્ક્રિપ્ટ આપમેળે સંબંધિત ડિસ્પોઝ પદ્ધતિને કૉલ કરે છે જ્યારે વેરિયેબલ સ્કોપની બહાર જાય છે, કાં તો બ્લોકના અંતે અથવા જો કોઈ એરર ફેંકાય.

ચાલો એક ડિસ્પોઝેબલ ડેટાબેઝ કનેક્શન રેપર બનાવીએ:

            
class ManagedDatabaseConnection {
  constructor(connection) {
    this.connection = connection;
    this.isDisposed = false;
  }

  // Expose database methods like query
  async query(sql, params) {
    if (this.isDisposed) {
      throw new Error("Connection is already disposed.");
    }
    return this.connection.query(sql, params);
  }

  async [Symbol.asyncDispose]() {
    if (!this.isDisposed) {
      console.log('Disposing connection...');
      await this.connection.close();
      this.isDisposed = true;
      console.log('Connection disposed.');
    }
  }
}

// How to use it:
async function getUserByIdWithUsing(id) {
  // Assumes getRawConnection returns a promise for a connection object
  const rawConnection = await getRawConnection(); 
  await using connection = new ManagedDatabaseConnection(rawConnection);

  const result = await connection.query('SELECT * FROM users WHERE id = ?', [id]);
  return result[0];
  
  // No finally block needed! `connection[Symbol.asyncDispose]` is called automatically here.
}

            

              
                Copy
              
            
          

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

પૂલિંગની શક્તિ: જ્યારે તમે પુનઃઉપયોગ કરી શકો ત્યારે ફરીથી શા માટે બનાવવું?

using પેટર્ન *ગેરંટીકૃત ક્લીનઅપ*ની સમસ્યાને હલ કરે છે. પરંતુ ઉચ્ચ-ટ્રાફિક એપ્લિકેશનમાં, દરેક એક વિનંતી માટે ડેટાબેઝ કનેક્શન બનાવવું અને નષ્ટ કરવું અતિશય બિનકાર્યક્ષમ છે. અહીં જ રિસોર્સ પૂલિંગ કામ આવે છે.

રિસોર્સ પૂલ શું છે?

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

એક સામાન્ય રિસોર્સ પૂલ અમલીકરણમાં શામેલ છે:

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

પૂલિંગના ફાયદા

• ઘટાડેલી લેટન્સી: પૂલમાંથી રિસોર્સ મેળવવું શરૂઆતથી નવું બનાવવા કરતાં નોંધપાત્ર રીતે ઝડપી છે.
• ઓછો ઓવરહેડ: તમારા એપ્લિકેશન સર્વર અને બાહ્ય સિસ્ટમ (દા.ત., ડેટાબેઝ) બંને પર CPU અને મેમરીનું દબાણ ઘટાડે છે.
• કનેક્શન થ્રોટલિંગ: મહત્તમ પૂલ સાઇઝ સેટ કરીને, તમે તમારી એપ્લિકેશનને ડેટાબેઝ અથવા બાહ્ય સેવાને ઘણા બધા સમવર્તી કનેક્શન્સથી ઓવરલોડ થતા અટકાવો છો.

મહાન સંશ્લેષણ: `using` ને રિસોર્સ પૂલ સાથે જોડવું

હવે આપણે આપણી વ્યૂહરચનાના મૂળમાં આવીએ છીએ. આપણી પાસે ગેરંટીકૃત ક્લીનઅપ (using) માટે એક શાનદાર પેટર્ન અને પ્રદર્શન (પૂલિંગ) માટે એક સાબિત વ્યૂહરચના છે. આપણે તેમને એક સીમલેસ, મજબૂત ઉકેલમાં કેવી રીતે મર્જ કરી શકીએ?

ધ્યેય પૂલમાંથી રિસોર્સ મેળવવાનો છે અને ગેરંટી આપવાનો છે કે જ્યારે આપણું કામ પૂરું થઈ જાય, ત્યારે ભૂલોની હાજરીમાં પણ તે પૂલમાં પાછું છોડવામાં આવે. આપણે આ એક રેપર ઓબ્જેક્ટ બનાવીને પ્રાપ્ત કરી શકીએ છીએ જે ડિસ્પોઝ પ્રોટોકોલ લાગુ કરે છે, પરંતુ જેની `dispose` પદ્ધતિ `resource.close()` ને બદલે `pool.release()` ને કૉલ કરે છે.

આ જાદુઈ કડી છે: `dispose` ક્રિયા 'નષ્ટ કરવું' ને બદલે 'પૂલમાં પાછા ફરો' બની જાય છે.

પગલા-દર-પગલા અમલીકરણ

ચાલો આને કામ કરવા માટે એક જેનરિક રિસોર્સ પૂલ અને જરૂરી રેપર્સ બનાવીએ.

પગલું 1: એક સરળ, જેનરિક રિસોર્સ પૂલ બનાવવું

અહીં એક એસિંક્રનસ રિસોર્સ પૂલનું વૈચારિક અમલીકરણ છે. પ્રોડક્શન-રેડી સંસ્કરણમાં ટાઇમઆઉટ, આઇડલ રિસોર્સ ઇવિક્શન અને રિટ્રાય લોજિક જેવી વધુ સુવિધાઓ હશે, પરંતુ આ મુખ્ય મિકેનિક્સને દર્શાવે છે.

            
class ResourcePool {
  constructor({ create, destroy, min, max }) {
    this.factory = { create, destroy };
    this.config = { min, max };
    this.pool = []; // Stores available resources
    this.active = []; // Stores resources currently in use
    this.waitQueue = []; // Stores promises for clients waiting for a resource
    
    // Initialize minimum resources
    for (let i = 0; i < this.config.min; i++) {
      this._createResource().then(resource => this.pool.push(resource));
    }
  }

  async _createResource() {
    const resource = await this.factory.create();
    return resource;
  }

  async acquire() {
    // If a resource is available in the pool, use it
    if (this.pool.length > 0) {
      const resource = this.pool.pop();
      this.active.push(resource);
      return resource;
    }

    // If we are under the max limit, create a new one
    if (this.active.length < this.config.max) {
      const resource = await this._createResource();
      this.active.push(resource);
      return resource;
    }

    // Otherwise, wait for a resource to be released
    return new Promise((resolve, reject) => {
        // A real implementation would have a timeout here
        this.waitQueue.push({ resolve, reject });
    });
  }

  release(resource) {
    // Check if someone is waiting
    if (this.waitQueue.length > 0) {
        const waiter = this.waitQueue.shift();
        // Give this resource directly to the waiting client
        waiter.resolve(resource);
    } else {
        // Otherwise, return it to the pool
        this.pool.push(resource);
    }
    // Remove from active list
    this.active = this.active.filter(r => r !== resource);
  }

  async close() {
    // Close all resources in the pool and those active
    const allResources = [...this.pool, ...this.active];
    this.pool = [];
    this.active = [];
    await Promise.all(allResources.map(r => this.factory.destroy(r)));
  }
}

            

              
                Copy
              
            
          

પગલું 2: 'PooledResource' રેપર બનાવવું

આ તે મહત્વપૂર્ણ ભાગ છે જે પૂલને using સિન્ટેક્સ સાથે જોડે છે. તે એક રિસોર્સ અને તે જે પૂલમાંથી આવ્યું છે તેનો સંદર્ભ રાખશે. તેની ડિસ્પોઝ પદ્ધતિ pool.release() ને કૉલ કરશે.

            
class PooledResource {
  constructor(resource, pool) {
    this.resource = resource;
    this.pool = pool;
    this._isReleased = false;
  }

  // This method releases the resource back to the pool
  [Symbol.dispose]() {
    if (this._isReleased) {
      return;
    }
    this.pool.release(this.resource);
    this._isReleased = true;
    console.log('Resource released back to pool.');
  }
}

// We can also create an async version
class AsyncPooledResource {
    constructor(resource, pool) {
        this.resource = resource;
        this.pool = pool;
        this._isReleased = false;
    }

    // The dispose method can be async if releasing is an async operation
    async [Symbol.asyncDispose]() {
        if (this._isReleased) {
            return;
        }
        // In our simple pool, release is sync, but we show the pattern
        await Promise.resolve(this.pool.release(this.resource));
        this._isReleased = true;
        console.log('Async resource released back to pool.');
    }
}

            

              
                Copy
              
            
          

પગલું 3: બધું એક યુનિફાઇડ મેનેજરમાં એકસાથે મૂકવું

API ને વધુ સ્વચ્છ બનાવવા માટે, અમે એક મેનેજર ક્લાસ બનાવી શકીએ છીએ જે પૂલને સમાવિષ્ટ કરે છે અને ડિસ્પોઝેબલ રેપર્સ પ્રદાન કરે છે.

            
class ResourceManager {
    constructor(poolConfig) {
        this.pool = new ResourcePool(poolConfig);
    }

    async getResource() {
        const resource = await this.pool.acquire();
        // Use the async wrapper if your resource cleanup could be async
        return new AsyncPooledResource(resource, this.pool);
    }

    async shutdown() {
        await this.pool.close();
    }
}

// --- Example Usage ---

// 1. Define how to create and destroy our mock resources
let resourceIdCounter = 0;
const poolConfig = {
  create: async () => {
    resourceIdCounter++;
    console.log(`Creating resource #${resourceIdCounter}...`);
    return { id: resourceIdCounter, data: `data for ${resourceIdCounter}` };
  },
  destroy: async (resource) => {
    console.log(`Destroying resource #${resource.id}...`);
  },
  min: 1,
  max: 3
};

// 2. Create the manager
const manager = new ResourceManager(poolConfig);

// 3. Use the pattern in an application function
async function processRequest(requestId) {
  console.log(`Request ${requestId}: Attempting to get a resource...`);
  try {
    await using client = await manager.getResource();
    
    console.log(`Request ${requestId}: Acquired resource #${client.resource.id}. Working...`);
    // Simulate some work
    await new Promise(resolve => setTimeout(resolve, 500));

    // Simulate a random failure
    if (Math.random() > 0.7) {
        throw new Error(`Request ${requestId}: Simulated random failure!`);
    }

    console.log(`Request ${requestId}: Work complete.`);
  } catch (error) {
    console.error(error.message);
  }
  // `client` is automatically released back to the pool here, in success or failure cases.
}

// --- Simulate concurrent requests ---
async function main() {
    const requests = [
        processRequest(1),
        processRequest(2),
        processRequest(3),
        processRequest(4),
        processRequest(5)
    ];

    await Promise.all(requests);

    console.log('\nAll requests finished. Shutting down pool...');
    await manager.shutdown();
}

main();

            

              
                Copy
              
            
          

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

વૈશ્વિક પ્રેક્ષકો માટે અદ્યતન વિચારણાઓ અને શ્રેષ્ઠ પ્રયાસો

જ્યારે આપણું ઉદાહરણ એક મજબૂત પાયો પૂરો પાડે છે, ત્યારે વાસ્તવિક-વિશ્વની, વૈશ્વિક સ્તરે વિતરિત એપ્લિકેશનોને વધુ સૂક્ષ્મ વિચારણાઓની જરૂર પડે છે.

સમવર્તીતા અને પૂલ સાઇઝ ટ્યુનિંગ

`min` અને `max` પૂલ સાઇઝ મહત્વપૂર્ણ ટ્યુનિંગ પરિમાણો છે. કોઈ એક જાદુઈ સંખ્યા નથી; શ્રેષ્ઠ સાઇઝ તમારી એપ્લિકેશનના લોડ, રિસોર્સ બનાવવાની લેટન્સી અને બેકએન્ડ સેવાની મર્યાદાઓ (દા.ત., તમારા ડેટાબેઝના મહત્તમ કનેક્શન્સ) પર આધાર રાખે છે.

• ખૂબ નાનું: તમારી એપ્લિકેશનના થ્રેડ્સ રિસોર્સ ઉપલબ્ધ થવાની રાહ જોવામાં ઘણો સમય પસાર કરશે, જે પ્રદર્શનમાં અવરોધ ઊભો કરશે. આને પૂલ કન્ટેન્શન તરીકે ઓળખવામાં આવે છે.
• ખૂબ મોટું: તમે તમારા એપ્લિકેશન સર્વર અને બેકએન્ડ બંને પર વધારાની મેમરી અને CPU નો વપરાશ કરશો. વૈશ્વિક સ્તરે વિતરિત ટીમ માટે, આ સંખ્યાઓ પાછળના તર્કનું દસ્તાવેજીકરણ કરવું મહત્વપૂર્ણ છે, કદાચ લોડ પરીક્ષણના પરિણામોના આધારે, જેથી વિવિધ પ્રદેશોના ઇજનેરો મર્યાદાઓને સમજી શકે.

અપેક્ષિત લોડના આધારે સાવચેતીભર્યા નંબરોથી પ્રારંભ કરો અને પૂલ વેઇટ ટાઇમ્સ અને યુટિલાઇઝેશન માપવા માટે એપ્લિકેશન પર્ફોર્મન્સ મોનિટરિંગ (APM) ટૂલ્સનો ઉપયોગ કરો. તે મુજબ ગોઠવણ કરો.

ટાઇમઆઉટ અને એરર હેન્ડલિંગ

જો પૂલ તેની મહત્તમ સાઇઝ પર હોય અને બધા સંસાધનો ઉપયોગમાં હોય તો શું થાય? અમારો સાદો પૂલ નવી વિનંતીઓને હંમેશ માટે રાહ જોવડાવશે. પ્રોડક્શન-ગ્રેડ પૂલમાં એક્વિઝિશન ટાઇમઆઉટ હોવું આવશ્યક છે. જો કોઈ રિસોર્સ ચોક્કસ સમયગાળામાં (દા.ત., 30 સેકન્ડ) મેળવી શકાતું નથી, તો `acquire` કૉલ ટાઇમઆઉટ એરર સાથે નિષ્ફળ જવો જોઈએ. આ વિનંતીઓને અનિશ્ચિત સમય માટે અટકી જવાથી અટકાવે છે અને તમને સુંદર રીતે નિષ્ફળ થવાની મંજૂરી આપે છે, કદાચ ક્લાયન્ટને `503 સર્વિસ અનુપલબ્ધ` સ્ટેટસ પરત કરીને.

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

ફ્રેમવર્ક અને આર્કિટેક્ચર સાથે એકીકરણ

આ રિસોર્સ મેનેજમેન્ટ પેટર્ન કોઈ અલગ તકનીક નથી; તે મોટા આર્કિટેક્ચરનો પાયાનો ભાગ છે.

• ડિપેન્ડન્સી ઇન્જેક્શન (DI): આપણે બનાવેલ `ResourceManager` એ DI કન્ટેનરમાં સિંગલટન સર્વિસ માટે એક સંપૂર્ણ ઉમેદવાર છે. દરેક જગ્યાએ નવો મેનેજર બનાવવાને બદલે, તમે તમારી એપ્લિકેશનમાં સમાન ઇન્સ્ટન્સ ઇન્જેક્ટ કરો છો, ખાતરી કરો કે દરેક જણ સમાન પૂલ શેર કરે છે.
• માઇક્રોસર્વિસિસ: માઇક્રોસર્વિસિસ આર્કિટેક્ચરમાં, દરેક સર્વિસ ઇન્સ્ટન્સ ડેટાબેઝ અથવા અન્ય સેવાઓ સાથેના તેના પોતાના કનેક્શન્સના પૂલનું સંચાલન કરશે. આ નિષ્ફળતાઓને અલગ પાડે છે અને દરેક સેવાને સ્વતંત્ર રીતે ટ્યુન કરવાની મંજૂરી આપે છે.
• સર્વરલેસ (FaaS): AWS Lambda અથવા Google Cloud Functions જેવા પ્લેટફોર્મ્સમાં, ફંક્શન્સની સ્ટેટલેસ અને ક્ષણિક પ્રકૃતિને કારણે કનેક્શન્સનું સંચાલન કરવું કુખ્યાત રીતે મુશ્કેલ છે. એક વૈશ્વિક કનેક્શન મેનેજર જે ફંક્શન ઇન્વોકેશન્સ વચ્ચે ટકી રહે છે (હેન્ડલરની બહાર ગ્લોબલ સ્કોપનો ઉપયોગ કરીને) અને હેન્ડલરની અંદર આ `using`/પૂલ પેટર્ન સાથે જોડાયેલો છે તે તમારા ડેટાબેઝને ઓવરલોડ થતો અટકાવવા માટે માનક શ્રેષ્ઠ પ્રથા છે.

નિષ્કર્ષ: વધુ સ્વચ્છ, સુરક્ષિત અને વધુ પ્રદર્શનશીલ જાવાસ્ક્રિપ્ટ લખવું

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

ચાલો આપણે જે શક્તિશાળી વ્યૂહરચના શોધી છે તેનો સારાંશ જોઈએ:

1. સમસ્યા: ડેટાબેઝ કનેક્શન્સ જેવા ખર્ચાળ, મર્યાદિત બાહ્ય સંસાધનોનું સંચાલન કરવું જટિલ છે. ડિટર્મિનિસ્ટિક ક્લીનઅપ માટે ગાર્બેજ કલેક્ટર પર આધાર રાખવો એ વિકલ્પ નથી, અને try...finally સાથે મેન્યુઅલ મેનેજમેન્ટ વર્બોઝ અને ભૂલ-સંભવિત છે.
2. સુરક્ષા નેટ: આગામી using અને await using સિન્ટેક્સ, જે TC39 સ્પષ્ટ રિસોર્સ મેનેજમેન્ટ પ્રસ્તાવનો ભાગ છે, તે સુનિશ્ચિત કરવાનો એક ઘોષણાત્મક અને લગભગ ફૂલપ્રૂફ માર્ગ પૂરો પાડે છે કે રિસોર્સ માટે ક્લીનઅપ લોજિક હંમેશા એક્ઝિક્યુટ થાય.
3. પ્રદર્શન એન્જિન: રિસોર્સ પૂલિંગ એ એક સમય-પરીક્ષિત પેટર્ન છે જે હાલના સંસાધનોનો પુનઃઉપયોગ કરીને રિસોર્સ બનાવવા અને નષ્ટ કરવાના ઊંચા ખર્ચને ટાળે છે.
4. સંશ્લેષણ: ડિસ્પોઝ પ્રોટોકોલ ([Symbol.dispose] અથવા [Symbol.asyncDispose]) લાગુ કરતું રેપર બનાવીને અને જેની ક્લીનઅપ લોજિક રિસોર્સને તેના પૂલમાં પાછું છોડવાની હોય, આપણે બંને વિશ્વના શ્રેષ્ઠને પ્રાપ્ત કરીએ છીએ. આપણને using સ્ટેટમેન્ટની સલામતી અને સુંદરતા સાથે પૂલિંગનું પ્રદર્શન મળે છે.

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