જો તમે file_exists($path) ને કોલ કરો છો અને $path એ Amazon S3 બકેટ તરફ નિર્દેશ કરે છે, તો તમે લોકલ ડિસ્કનો ઉપયોગ નથી કરી રહ્યા—તમે નેટવર્ક રિક્વેસ્ટ કરી રહ્યા છો. આ સિંગલ-લાઇન ચેક S3 માટે એક રાઉન્ડ-ટ્રિપ બની જાય છે જે દરેક રિક્વેસ્ટમાં દસ-દસ મિલિસેકન્ડનો વધારો કરી શકે છે.

PHP રિમોટ સ્ટોરને સ્ટ્રીમ રેપર્સ (stream wrappers) પાછળ છુપાવે છે. fopen(), file_exists(), is_dir(), unlink() અને file_put_contents() જેવા ફંક્શન્સ આ રેપર્સ દ્વારા રૂટ થાય છે, જે આ કોલ્સને S3 API ઓપરેશન્સમાં રૂપાંતરિત કરે છે. તેનું મેપિંગ સરળ છે:

  • file_exists() → HeadObject
  • is_dir() → ListObjects
  • unlink() → DeleteObject
  • file_put_contents() → PutObject

દરેક કોલને અનુરૂપ S3 API રિક્વેસ્ટ જેટલો જ લેટન્સી (latency) ખર્ચ થાય છે. જ્યારે કોઈ સ્ક્રિપ્ટ ડઝનબંધ ફાઇલો તપાસે છે, ત્યારે તે N+1-સ્ટાઇલ પેટર્ન બનાવે છે: દરેક સિંગલ ચેક માટે એક નેટવર્ક હોપ.

તે અત્યારે શા માટે મહત્વનું છે

સામાન્ય ડેવલપમેન્ટ એન્વાયરમેન્ટમાં ફાઇલ સિસ્ટમ તે જ મશીન પર હોય છે, તેથી ચેક લગભગ તરત જ પરિણામ આપે છે. પ્રોડક્શનમાં, જ્યાં એસેટ્સ (assets) S3 પર હોય છે, ત્યાં આ જ કોડ પરફોર્મન્સમાં મોટો ઘટાડો કરી શકે છે. AWS SDK મેમરીમાં કેટલાક પરિણામો કેશ (cache) કરે છે, જેનાથી સિંગલ PHP પ્રોસેસમાં વારંવાર થતા ચેક ઝડપી લાગે છે. જોકે, મોટાભાગના PHP ડિપ્લોયમેન્ટ્સ દરેક વેબ રિક્વેસ્ટ માટે એક નવી પ્રોસેસ શરૂ કરે છે, જેનાથી દરેક વખતે કેશ ક્લિયર થઈ જાય છે. પરિણામ: દરેક રિક્વેસ્ટ પર દરેક અલગ પાથ માટે આખું નેટવર્ક રાઉન્ડ-ટ્રિપ થાય છે.

એક WordPress સાઇટને તેના હોમપેજને રેન્ડર કરવામાં એકવાર દસ સેકન્ડ લાગી હતી. ડેટાબેઝ ક્વેરીઝ ઝડપી હતી, પરંતુ કન્ટેન્ટ એસેમ્બલ કરવા માટે જ પેજ દ્વારા 73 અલગ-અલગ S3 કોલ્સ કરવામાં આવ્યા હતા. દરેક કોલ એક 'કોલ્ડ રિક્વેસ્ટ' (cold request) હતો, જે દેખીતી રીતે નિર્દોષ લાગતા file_exists() ને નોંધપાત્ર વિલંબમાં ફેરવી નાખ્યો હતો.

નિવારણની વ્યૂહરચનાઓ

  • રિક્વેસ્ટ્સ વચ્ચે કેશને ટકાવી રાખો (Persist cache across requests) – ઇન-પ્રોસેસ કેશને Redis જેવા શેર કરેલા સ્ટોરમાં ખસેડો. જ્યારે એક રિક્વેસ્ટને ખબર પડે કે કોઈ કી S3 પર અસ્તિત્વ ધરાવે છે, ત્યારે પછીની રિક્વેસ્ટ્સ ફરીથી S3 નો સંપર્ક કરવાને બદલે કેશ કરેલા પરિણામને વાંચે છે.
  • લોકલ-ફર્સ્ટ વર્કફ્લો અપનાવો (Adopt a local-first workflow) – ફાઇલો લોકલ ડિસ્ક પર લખો, અને પછી તેને અસિંક્રોનસલી (asynchronously) S3 સાથે સિંક કરો. મુખ્ય રિક્વેસ્ટ પાથ ફક્ત લોકલ ફાઇલ સિસ્ટમને જ સ્પર્શે છે; નેટવર્કનો ખર્ચ બેકગ્રાઉન્ડ જોબમાં બદલાઈ જાય છે.
  • કોડબેઝનું ઓડિટ કરો (Audit the codebase) – સિસ્ટમેટિકલી એવા ફાઇલ-સિસ્ટમ ફંક્શન્સ શોધો જે રિમોટ રેપર (remote wrapper) માં રૂપાંતરિત થઈ શકે છે. જે ફંક્શન્સ ટાઈટ લૂપ્સ (tight loops) અથવા રિક્વેસ્ટ-ક્રિટિકલ પાથમાં દેખાય તેને ફ્લેગ કરો.
  • APM ડેટા તપાસો (Inspect APM data) – જો ડેટાબેઝ મેટ્રિક્સ સ્થિર હોય પરંતુ રિસ્પોન્સ ટાઇમમાં ઉછાળો આવે, તો સ્ટોરેજ SDK ટાઇમિંગ્સની ઊંડાણપૂર્વક તપાસ કરો. SDK લેટન્સીમાં અચાનક વધારો ઘણીવાર છુપાયેલા S3 કોલ્સ તરફ નિર્દેશ કરે છે.

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