जर तुम्ही file_exists($path) कॉल केला आणि $path हे Amazon S3 बकेटला निर्देशित करत असेल, तर तुम्ही स्थानिक डिस्क (local disk) वापरत नसून एक नेटवर्क विनंती (network request) करत असता. ही एक ओळीची तपासणी S3 कडे जाणारी एक 'round-trip' बनते, ज्यामुळे प्रत्येक विनंतीमध्ये अनेक मिलीसेकंद वाढू शकतात.

PHP रिमोट स्टोअरला 'stream wrappers' च्या मागे लपवते. fopen(), file_exists(), is_dir(), unlink() आणि file_put_contents() सारखी फंक्शन्स या wrappers द्वारे मार्गक्रमण करतात, जे या कॉल्सना S3 API ऑपरेशन्समध्ये रूपांतरित करतात. याचे मॅपिंग अगदी सरळ आहे:

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

प्रत्येक कॉलमध्ये संबंधित S3 API विनंतीइतकाच विलंब (latency) येतो. जेव्हा एखादा स्क्रिप्ट डझनभर फाइल्स तपासतो, तेव्हा तो N+1-शैलीचा पॅटर्न तयार करतो: प्रत्येक तपासणीसाठी एक नेटवर्क हॉप (network hop).

हे आता का महत्त्वाचे आहे

सामान्य डेव्हलपमेंट एन्व्हायरमेंटमध्ये (development environment) फाइलसिस्टम त्याच मशीनवर असते, त्यामुळे तपासणी जवळजवळ त्वरित होते. परंतु प्रोडक्शनमध्ये (production), जिथे ॲसेट्स (assets) S3 वर असतात, तिथे तोच कोड परफॉर्मन्समध्ये मोठी घट (performance cliff) घडवून आणतो. AWS SDK काही निकाल मेमरीमध्ये कॅश (cache) करते, ज्यामुळे एका सिंगल PHP प्रोसेसमध्ये वारंवार केल्या जाणाऱ्या तपासण्या जलद वाटतात. मात्र, बहुतेक PHP डिप्लॉयमेंट्समध्ये प्रत्येक वेब विनंतीसाठी एक नवीन प्रोसेस तयार केली जाते, ज्यामुळे प्रत्येक वेळी कॅश क्लिअर होते. परिणामी: प्रत्येक विनंतीवरील प्रत्येक वेगळ्या पाथसाठी (path) पूर्ण नेटवर्क राऊंड-ट्रिप होते.

एका WordPress साइटला तिचे होमपेज रेंडर करण्यासाठी एकेकाळी दहा सेकंद लागत होते. डेटाबेस क्वेरीज जलद होत्या, परंतु केवळ कंटेंट तयार करण्यासाठी त्या पेजने ७३ स्वतंत्र S3 कॉल्स केले होते. प्रत्येक कॉल हा एक 'cold request' होता, ज्यामुळे एक साधा वाटणारा file_exists() कॉल देखील लक्षणीय विलंब निर्माण करत होता.

प्रतिबंधात्मक उपाय (Mitigation strategies)

  • विनंत्यांमधील कॅश कायम ठेवा (Persist cache across requests) – इन-प्रोसेस कॅशला Redis सारख्या शेअर स्टोअरमध्ये हलवा. जेव्हा एखादी विनंती S3 वर एखादी की (key) अस्तित्वात असल्याचे शोधते, तेव्हा पुढील विनंत्या S3 शी पुन्हा संपर्क साधण्याऐवजी कॅश केलेला निकाल वाचतात.
  • लोकल-फर्स्ट वर्कफ्लोचा अवलंब करा (Adopt a local-first workflow) – फाइल्स स्थानिक डिस्कवर लिहा आणि नंतर त्या S3 वर असिंक्रोनसली (asynchronously) सिंक करा. मुख्य विनंती पाथ फक्त स्थानिक फाइलसिस्टमला स्पर्श करतो; नेटवर्कचा खर्च बॅकग्राउंड जॉबकडे वळवला जातो.
  • कोडबेस ऑडिट करा (Audit the codebase) – रिमोट wrapper मध्ये रूपांतरित होऊ शकणाऱ्या फाइल-सिस्टम फंक्शन्ससाठी पद्धतशीरपणे शोधा. जे फंक्शन्स 'tight loops' किंवा विनंती-महत्त्वाच्या (request-critical) पाथमध्ये दिसतात, त्यांना फ्लॅग करा.
  • APM डेटा तपासा (Inspect APM data) – जर डेटाबेस मेट्रिक्स स्थिर असताना रिस्पॉन्स टाइममध्ये अचानक वाढ होत असेल, तर स्टोरेज SDK च्या टाइमिंगचा सखोल अभ्यास करा. SDK लेटन्सीमध्ये अचानक झालेली वाढ अनेकदा लपलेल्या S3 कॉल्सकडे निर्देश करते.

मुख्य निष्कर्ष: जे फंक्शन मायक्रोसेकंद स्थानिक तपासणीसारखे दिसते, ते नेटवर्क लेटन्सीचे अनेक मिलीसेकंद लपवून ठेवू शकते. S3 वरील file_exists() ला एक बाह्य कॉल (external call) म्हणून treating करा, त्याचा निकाल कॅश करा आणि मुख्य कामाचा भार विनंती पाथवरून (request path) काढून टाका. अन्यथा, लपलेला विलंब तुमच्या साइटचा वेग कमी करत राहील, प्रत्येक अदृश्य नेटवर्क विनंतीसह.