NGINX કેશને કાઢી નાંખવાનું ભૂલ લોગમાં કડી ન કરવાનું જટિલ ભૂલો મૂકે છે
પ્રકાશિત: 15 ફેબ્રુઆરી, 2025 એ 11:27:01 AM UTC વાગ્યે
આ લેખ સમજાવે છે કે તમારી લોગ ફાઇલોને ભૂલ સંદેશાઓ સાથે અવ્યવસ્થિત કર્યા વિના NGINX ની કેશમાંથી વસ્તુઓને કેવી રીતે કાઢી નાંખવી. સામાન્ય રીતે ભલામણ કરેલો અભિગમ ન હોવા છતાં, તે કેટલાક ધારના કિસ્સાઓમાં ઉપયોગી થઈ શકે છે.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
આ પોસ્ટમાંની માહિતી ઉબુન્ટુ સર્વર ૧૪.૦૪ x૬૪ પર ચાલતા એનજીઆઈએનએક્સ ૧.૪.૬ પર ફાસ્ટસીજીઆઈ કેશિંગ પર આધારિત છે. તે અન્ય સંસ્કરણો માટે માન્ય હોઈ શકે છે અથવા ન પણ હોઈ શકે.
(અપડેટ 2025: આ વચ્ચેના સમયમાં મેં ઓરિજિનલ પોસ્ટ લખી હતી અને હવે, ઘણું બધું બદલાઈ ગયું છે. સર્વર્સ ઝડપી અને સસ્તા છે, તેથી હું હકીકતમાં આ પોસ્ટમાં વર્ણવેલ અભિગમની ભલામણ કરીશ નહીં જ્યાં હું ફક્ત ડાયનેમિક કન્ટેન્ટની કેટલીક વધારાની પેઢીઓને બચાવવા માટે કેશ એક્સપાયરીને માઇક્રો-મેનેજ કરવાનો પ્રયાસ કરું છું. હું ભવિષ્યના સંદર્ભ માટે અહીં સામગ્રી છોડીશ અને જો કોઈને ખરેખર કોઈપણ કારણોસર તેની જરૂર હોય તો. જોકે, મેં એ વાતની પુષ્ટિ કરી નથી કે આ હજી પણ એનજીઆઇએનએક્સના વર્તમાન સંસ્કરણો માટે કામ કરે છે, પરંતુ મને લાગે છે કે તે કરે છે).
અપાચેથી એનજીઆઇએનએક્સ (NGINX) માં ઘણી સાઇટ્સ સ્થળાંતર કર્યા પછી મને તેની બિલ્ટ-ઇન કેશિંગ ક્ષમતાઓ ખૂબ જ પસંદ આવી છે, જે મોટા ભાગના સંજોગોમાં મારી પાસેથી વધુ દખલ કર્યા વિના ખૂબ જ સારી રીતે કાર્ય કરે છે.
જો કે, એક સાઇટ માટે, મને ખરેખર કેશને સાફ કરવાની ક્ષમતાની જરૂર હતી (સંપૂર્ણપણે અને વ્યક્તિગત એન્ટ્રીઝ બંને) જાતે. NGINXની મુક્ત સામુદાયિક આવૃત્તિ માત્ર સમય-આધારિત કેશ સમાપ્તિને જ આધાર આપે છે (એટલે કે તમે તેને એક કલાક, એક દિવસ, વગેરે પછી કંઇક બદલાયું છે કે કેમ તે ચકાસવા માટે સેટ અપ કરી શકો છો). પરંતુ જ્યારે કોઈ ચોક્કસ સંસાધન બદલાશે ત્યારે સમય પહેલાં નક્કી કરવાની કોઈ વિશ્વસનીય રીત ન હોય તો શું? દાખલા તરીકે, મને ખબર નથી કે હું પાછો આવીશ અને આ પોસ્ટમાં કશુંક સંપાદિત કરીશ તે પહેલાં એક કલાક, એક દિવસ કે એક વર્ષ લાગશે કે કેમ - અને જો એક દિવસ માટે કેશિંગ કરવું સારું હોત તો માત્ર એક કલાક માટે જ કેશ શા માટે?
આ તે છે જ્યાં કેશને જાતે જ સાફ કરવાની ક્ષમતાની જરૂર છે (અથવા તમારા વેબ એપ્લિકેશન દ્વારા NGINX ને સૂચિત કરીને કે કંઇક શુદ્ધ થવું જોઈએ) જરૂરી છે. એનજીઆઇએનએક્સ (NGINX) પાછળના લોકો આની જરૂરિયાતથી સ્પષ્ટપણે વાકેફ છે કારણ કે આ સુવિધાને તેમના ઉત્પાદનના પેઇડ વર્ઝનમાં ટેકો આપવામાં આવ્યો છે - પરંતુ જ્યારે તેઓ ઇચ્છે તે રીતે તેમના લાઇસન્સિંગને સેટ કરવા માટે ચોક્કસપણે હકદાર છે, પરંતુ જ્યારે આ ફંક્શન એકમાત્ર પેઇડ ફીચર છે જેની મને ખરેખર જરૂર છે ત્યારે મારા માટે કિંમત થોડી તીવ્ર છે.
સદભાગ્યે, તે તારણ આપે છે કે તમે ફક્ત કેશ ડિરેક્ટરીમાંથી ફાઇલોને જાતે જ કાઢી શકો છો અને NGINX આને પસંદ કરશે અને હરકત વિના તમારા બેક-એન્ડમાંથી નવી નકલ લાવશે. જો કે, જો તમે તમારા રૂપરેખાંકનને ટ્વીક કર્યા વિના આ કરો છો, તો તમને થોડા સમય પછી તમારા એરર લોગમાં આના જેવા જ સંદેશાઓનો એક આખો સમૂહ દેખાશે:
એવું લાગે છે કે આ ભૂલો ત્યારે થાય છે જ્યારે એનજીઆઈએનએક્સ પોતે જ fastcgi_cache_path નિર્દેશના નિષ્ક્રિય પરિમાણ દ્વારા નિર્દિષ્ટ કરેલા સમય પછી કેશ એન્ટ્રીઓને કાઢી નાખવાનો પ્રયાસ કરે છે. આ માટેનો મૂળભૂત માત્ર 10 મિનિટનો છે, પરંતુ તમે તેને જે પણ મૂલ્ય ઇચ્છો તે પર સેટ કરી શકો છો. જો તમે તેને 10 વર્ષ માટે સેટ કરો છો, તો તે સંભવત: અસંભવિત છે કે તમે તે દરમિયાન સર્વર ફરીથી શરૂ કર્યું નથી તેથી મેમરીમાં કી ઇન્ડેક્સ તે દરમિયાન સાફ થઈ ગયો હોત. જો તમે આમ કરો છો, તો શું તમારે ખાતરી કરવાની જરૂર છે કે તમે જાતે કેશને સાફ કરો છો, NGINX તમારા માટે તે કરશે નહીં.
મને તે ખરેખર વિચિત્ર લાગે છે કે તે એક નિર્ણાયક ભૂલ માનવામાં આવે છે કે કેશ એન્ટ્રીને કાઢી શકાતી નથી કારણ કે તે અસ્તિત્વમાં નથી. હકીકત એ છે કે તેનું તીવ્રતા વર્ગીકરણ એટલું ઊંચું છે તેનો અર્થ એ છે કે ચોક્કસ થ્રેશોલ્ડથી નીચેના લોગ પ્રવેશોને અવગણીને ફક્ત છુટકારો મેળવવો અશક્ય છે. જેવી બેક-એન્ડમાંથી નવી નકલ લાવવામાં આવે કે તરત જ પ્રવેશ ફરીથી અસ્તિત્વમાં આવશે, તેથી મારા મતે, આ એક ચેતવણી હોવી જોઈએ.
હવે, જો પરવાનગી અથવા કંઇક ત્રીજી વસ્તુ સાથેની સમસ્યાને કારણે કેશ એન્ટ્રી ડિલીટ કરી શકાતી નથી, તો તે એક ગંભીર ભૂલ હશે, કારણ કે તે એનજીઆઇએનએક્સને તેની સમાપ્તિના સમય પછી લાંબા સમય સુધી કેશ્ડ કન્ટેન્ટ પીરસવાનું ચાલુ રાખી શકે છે, પરંતુ સફાઇ પ્રક્રિયા આ તફાવત કરતી હોય તેવું લાગતું નથી.