ನೀವು file_exists($path) ಅನ್ನು ಕರೆ ಮಾಡಿದಾಗ ಮತ್ತು $path ಎಂಬುದು Amazon S3 ಬಕೆಟ್ ಅನ್ನು ಸೂಚಿಸಿದರೆ, ನೀವು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ ಅನ್ನು ಬಳಸುತ್ತಿಲ್ಲ—ನೀವು ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಯನ್ನು (network request) ಮಾಡುತ್ತಿದ್ದೀರಿ. ಈ ಒಂದೇ ಸಾಲಿನ ಪರಿಶೀಲನೆಯು S3 ಗೆ ಒಂದು ರೌಂಡ್-ಟ್ರಿಪ್ ಆಗಿ ಬದಲಾಗುತ್ತದೆ, ಇದು ಪ್ರತಿ ವಿನಂತಿಗೆ ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ಸೇರಿಸಬಹುದು.

PHP ದೂರದ ಸ್ಟೋರ್ ಅನ್ನು (remote store) ಸ್ಟ್ರೀಮ್ ರ್ಯಾಪರ್‌ಗಳ (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-ಶೈಲಿಯ ಮಾದರಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಪ್ರತಿ ಪರಿಶೀಲನೆಗೂ ಒಂದು ನೆಟ್‌ವರ್ಕ್ ಹಪ್ (network hop).

ಇದು ಈಗ ಏಕೆ ಮುಖ್ಯವಾಗುತ್ತದೆ

ಸಾಮಾನ್ಯ ಡೆವಲಪ್‌ಮೆಂಟ್ ಪರಿಸರದಲ್ಲಿ (development environment) ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಒಂದೇ ಮಷೀನ್‌ನಲ್ಲಿ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಶೀಲನೆಯು ತಕ್ಷಣವೇ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ (production), ಅಸೆಟ್‌ಗಳು S3 ಯಲ್ಲಿರುವಾಗ, ಅದೇ ಕೋಡ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತಕ್ಕೆ (performance cliff) ಕಾರಣವಾಗುತ್ತದೆ. AWS SDK ಕೆಲವು ಫಲಿತಾಂಶಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಕ್ಯಾಶ್ (cache) ಮಾಡುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಒಂದೇ PHP ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪದೇ ಪದೇ ಮಾಡುವ ಪರಿಶೀಲನೆಗಳು ವೇಗವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆದರೆ ಹೆಚ್ಚಿನ PHP ನಿಯೋಜನೆಗಳು (deployments), ಪ್ರತಿ ವೆಬ್ ವಿನಂತಿಗೂ ಹೊಸ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿಯೂ ಕ್ಯಾಶ್ ಅನ್ನು ತೆರವುಗೊಳಿಸುತ್ತವೆ. ಇದರ ಪರಿಣಾಮ: ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲಿನ ಪ್ರತಿಯೊಂದು ವಿಭಿನ್ನ ಪಾತ್‌ಗೂ (path) ಪೂರ್ಣ ನೆಟ್‌ವರ್ಕ್ ರೌಂಡ್-ಟ್ರಿಪ್ ಆಗುತ್ತದೆ.

ಒಂದು WordPress ಸೈಟ್ ತನ್ನ ಹೋಮ್‌ಪೇಜ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲು ಒಮ್ಮೆ ಹತ್ತು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿತ್ತು. ಡೇಟಾಬೇಸ್ ಕ್ವೇರಿಗಳು ವೇಗವಾಗಿದ್ದವು, ಆದರೆ ಕಂಟೆಂಟ್ ಅನ್ನು ಜೋಡಿಸಲು ಕೇವಲ ಪುಟವು 73 ವೈಯಕ್ತಿಕ S3 ಕರೆಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತಿತ್ತು. ಪ್ರತಿ ಕರೆಯೂ ಒಂದು 'ಕೋಲ್ಡ್ ರಿಕ್ವೆಸ್ಟ್' ಆಗಿದ್ದು, ಮೇಲ್ನೋಟಕ್ಕೆ ಹಾನಿಕಾರಕವಲ್ಲದ file_exists() ಅನ್ನು ಗಮನಾರ್ಹ ವಿಳಂಬವಾಗಿ ಪರಿವರ್ತಿಸಿತ್ತು.

ತಡೆಗಟ್ಟುವಿಕೆಯ ತಂತ್ರಗಳು

  • ವಿನಂತಿಗಳ ನಡುವೆ ಕ್ಯಾಶ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ (Persist cache across requests) – ಇನ್-ಪ್ರೊಸೆಸ್ ಕ್ಯಾಶ್ ಅನ್ನು Redis ನಂತಹ ಹಂಚಿಕೆಯ ಸ್ಟೋರ್‌ಗೆ (shared store) ವರ್ಗಾಯಿಸಿ. ಒಂದು ವಿನಂತಿಯು S3 ಯಲ್ಲಿ ಒಂದು ಕೀ (key) ಇರುವುದನ್ನು ಕಂಡುಕೊಂಡಾಗ, ಮುಂದಿನ ವಿನಂತಿಗಳು ಮತ್ತೆ S3 ಅನ್ನು ಸಂಪರ್ಕಿಸುವ ಬದಲು ಕ್ಯಾಶ್ ಮಾಡಿದ ಫಲಿತಾಂಶವನ್ನು ಓದುತ್ತವೆ.
  • ಲೋಕಲ್-ಫಸ್ಟ್ ವರ್ಕ್‌ಫ್ಲೋ ಅಳವಡಿಸಿಕೊಳ್ಳಿ (Adopt a local-first workflow) – ಫೈಲ್‌ಗಳನ್ನು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಿರಿ, ನಂತರ ಅವುಗಳನ್ನು ಅಸynchronized ಆಗಿ S3 ಗೆ ಸಿಂಕ್ ಮಾಡಿ. ಮುಖ್ಯ ವಿನಂತಿ ಪಾತ್ ಕೇವಲ ಸ್ಥಳೀಯ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ; ನೆಟ್‌ವರ್ಕ್ ವೆಚ್ಚವು ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ಕೆಲಸಕ್ಕೆ (background job) ವರ್ಗಾಯಿಸಲ್ಪಡುತ್ತದೆ.
  • ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಆಡಿಟ್ ಮಾಡಿ (Audit the codebase) – ರಿಮೋಟ್ ರ್ಯಾಪರ್‌ಗೆ ಪರಿವರ್ತನೆಯಾಗಬಹುದಾದ ಫೈಲ್-ಸಿಸ್ಟಮ್ ಫಂಕ್ಷನ್‌ಗಳಿಗಾಗಿ ವ್ಯವಸ್ಥಿತವಾಗಿ ಹುಡುಕಿ. ಟೈಟ್ ಲೂಪ್‌ಗಳು (tight loops) ಅಥವಾ ವಿನಂತಿ-ನಿರ್ಣಾಯಕ ಪಾತ್‌ಗಳ (request-critical paths) ಒಳಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಯಾವುದೇ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಗುರುತಿಸಿ.
  • APM ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿ (Inspect APM data) – ಡೇಟಾಬೇಸ್ ಮೆಟ್ರಿಕ್‌ಗಳು ಸ್ಥಿರವಾಗಿದ್ದರೂ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವು (response time) ಏರಿಕೆಯಾದರೆ, ಸ್ಟೋರೇಜ್ SDK ಸಮಯವನ್ನು (timings) ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸಿ. SDK ವಿಳಂಬದಲ್ಲಿನ (latency) ಹಠಾತ್ ಏರಿಕೆಯು ಹೆಚ್ಚಾಗಿ ಅಡಗಿರುವ S3 ಕರೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಮುಖ್ಯ ಅಂಶ: ಮೈಕ್ರೋಸೆಕೆಂಡ್ ಸ್ಥಳೀಯ ಪರಿಶೀಲನೆಯಂತೆ ಕಾಣುವ ಒಂದು ಫಂಕ್ಷನ್ ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ನೆಟ್‌ವರ್ಕ್ ವಿಳಂಬವನ್ನು ಮರೆಮಾಚಬಹುದು. S3 ಯ ಮೇಲಿನ file_exists() ಅನ್ನು ಬಾಹ್ಯ ಕರೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಅದರ ಫಲಿತಾಂಶವನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿ ಮತ್ತು ಭಾರೀ ಕೆಲಸಗಳನ್ನು ವಿನಂತಿ ಪಾತ್‌ನಿಂದ ಹೊರಗೆ ತನ್ನಿ. ಇಲ್ಲದಿದ್ದರೆ, ಅಡಗಿರುವ ವಿಳಂಬವು ನಿಮ್ಮ ಸೈಟ್ ಅನ್ನು ಒಂದೊಂದೇ ಅದೃಶ್ಯ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿಯ ಮೂಲಕ ನಿಧಾನಗೊಳಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.