ડેવલપર્સ ಹೆಚ್ಚಾಗಿ ನನ್ನನ್ನು ಒಂದೇ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತಾರೆ: "ನನ್ನ API ನಿಧಾನವಾಗಿದೆ. ನಾನು ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕು?" ಸಾಮಾನ್ಯವಾಗಿ ಇದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದು ಅಥವಾ RAM ಅನ್ನು ಡಬಲ್ ಮಾಡುವುದು ಎಂಬ ಆಲೋಚನೆ ಬರುತ್ತದೆ. ಇದು ಹಣವನ್ನು ವ್ಯಯಿಸುತ್ತದೆ ಮತ್ತು ಅಸಲಿ ಸಮಸ್ಯೆಯನ್ನು (root cause) ಸರಿಪಡಿಸುವುದು ಅಪರೂಪ. ಹೆಚ್ಚಿನ Laravel ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ, ಅಡಚಣೆಯು (bottleneck) ಡೇಟಾಬೇಸ್ ಲೇಯರ್ನಲ್ಲೇ ಇರುತ್ತದೆ. ಫ್ರೇಮ್ವರ್ಕ್ನ ಸುಂದರವಾದ ಸಿಂಟ್ಯಾಕ್ಸ್ (syntax) ಕಾರಣದಿಂದಾಗಿ, ಪ್ರತಿಯೊಂದು Eloquent ಕರೆಯು ಅಂತಿಮವಾಗಿ SQL ಆಗುತ್ತದೆ ಮತ್ತು SQL ನಲ್ಲೇ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಎಂಬ ವಿಷಯವನ್ನು ಮರೆಯುವುದು ಸುಲಭವಾಗುತ್ತದೆ.
ಸರ್ವರ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು, ನಿಮ್ಮ ಕ್ವೇರಿಗಳನ್ನು (queries) ವ್ಯವಸ್ಥಿತವಾಗಿ ಪರಿಶೀಲಿಸಿ.
ಸರಿಯಾದ ರೋಗನಿರ್ಣಯದೊಂದಿಗೆ (Diagnostic) ಪ್ರಾರಂಭಿಸಿ
ಕತ್ತಲೆಯಲ್ಲಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಡಿ. ಕ್ವೇರಿಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ (randomly) ಮರುಬರೆಯುವುದು ಕೇವಲ ಊಹೆಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಅಂತಹ ಊಹೆಗಳು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ.
ಅತಿ ಹೆಚ್ಚು ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳನ್ನು ನೀವು ಪತ್ತೆಹಚ್ಚಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೈಜ ಲೋಡ್ (real load) ಅಡಿಯಲ್ಲಿ ಗಮನಿಸಿ. Laravel Telescope ನಿಮಗೆ ಪ್ರತಿಯೊಂದು ರಿಕ್ವೆಸ್ಟ್ ಸಮಯದಲ್ಲಿ ಚಲಿಸುವ ಪ್ರತಿಯೊಂದು ಕ್ವೇರಿಯನ್ನು ಅದರ ಸಮಯದ ವಿವರಗಳೊಂದಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ. Laravel Debugbar ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಯ (local development) ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಬ್ರೌಸರ್ನಲ್ಲಿ ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ, ಇದರಿಂದ ನೀವು ತಕ್ಷಣವೇ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಗುರುತಿಸಬಹುದು. ನೀವು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕಾದಾಗ, MySQL Slow Query Log ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ. ಇದು ನೀವು ನಿಗದಿಪಡಿಸಿದ ಮಿತಿಗಿಂತ (threshold) ಹೆಚ್ಚಿನ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಸ್ಟೇಟ್ಮೆಂಟ್ಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಇದು ಸಣ್ಣ ಡೇಟಾ ಸೆಟ್ಗಳಲ್ಲಿ ಕಾಣಿಸದ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ನೀವು ದೊಡ್ಡ ಮಟ್ಟದ ಡೇಟಾವನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, Application Performance Monitoring ಸಾಧನವು ನಿಧಾನಗತಿಯ HTTP ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್ ಕರೆಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಕಲ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ನೀವು ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, ಎರಡು ವಿಷಯಗಳನ್ನು ಗಮನಿಸಿ: ಸಂಪೂರ್ಣ ಕಾರ್ಯನಿರ್ವಹಣಾ ಸಮಯ (absolute execution time) ಮತ್ತು ಕರೆಯುವ ಆವರ್ತನ (call frequency). ನಲವತ್ತು ಮಿಲಿಸೆಕೆಂಡು ತೆಗೆದುಕೊಳ್ಳುವ ಕ್ವೇರಿ ಹಾನಿಕಾರಕವಲ್ಲ ಎಂದು ಅನಿಸಬಹುದು, ಆದರೆ ಅದು ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಎರಡು ಸಾವಿರ ಬಾರಿ ಚಲಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದಾಗ ಪರಿಸ್ಥಿತಿ ಬದಲಾಗುತ್ತದೆ. ಗಂಟೆಗೆ ಒಂದು ಬಾರಿ ಚಲಿಸುವ ಮೂರು ಸೆಕೆಂಡುಗಳ ವರದಿಯಿಗಿಂತ, ಪ್ರತಿ ಪೇಜ್ನಲ್ಲಿ ಚಲಿಸುವ ಅರ್ಧ ಸೆಕೆಂಡಿನ ಲುಕ್ಅಪ್ (lookup) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಬಹುದು. ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಮೊದಲು ಸರಿಪಡಿಸಿ.
ಎಲ್ಲವನ್ನೂ ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ
SELECT * ಎಂಬುದು ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ಇದು ದುಬಾರಿಯಾಗಿದೆ (expensive). ನೀವು Model::all() ಎಂದು ಬರೆಯುವಾಗ ಅಥವಾ ಕಾಲಂಗಳನ್ನು ಹೆಸರಿಸದೆ ರಿಸಲ್ಟ್ ಸೆಟ್ ಅನ್ನು ಪಡೆಯುವಾಗ, MySQL ಪ್ರತಿ ಹೊಂದಿಕೆಯಾಗುವ ಸಾಲಿನ ಎಲ್ಲಾ ಫೀಲ್ಡ್ಗಳನ್ನು ಎತ್ತಿ ತರುತ್ತದೆ. ಇದರಲ್ಲಿ ದೊಡ್ಡ ಪಠ್ಯದ ಫೀಲ್ಡ್ಗಳು (text fields), JSON ಬ್ಲಾಗ್ಗಳು ಮತ್ತು ಟೇಬಲ್ನಲ್ಲಿರುವ ಇತರ ಎಲ್ಲವೂ ಸೇರಿರುತ್ತವೆ. ಇದರಿಂದ ರಿಸಲ್ಟ್ ಸೆಟ್ ಬೆಳೆಯುತ್ತದೆ, ಮೆಮೊರಿ ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ ಮತ್ತು ರೆಸ್ಪಾನ್ಸ್ ಅನ್ನು ಸೀರಿಯಲೈಸ್ (serializing) ಮಾಡಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವೂ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಸ್ಪಷ್ಟವಾಗಿರಿ. ನಿಮ್ಮ ಕಂಟ್ರೋಲರ್ಗೆ ಕೇವಲ id, name, ಮತ್ತು email ಫೀಲ್ಡ್ಗಳು ಬೇಕಿದ್ದರೆ, ನಿಖರವಾಗಿ ಅವುಗಳನ್ನು ಮಾತ್ರ ಕೇಳಿ:
User::select('id', 'name', 'email')->get();
ಕ್ವೇರಿ ಬಿಲ್ಡರ್ನಲ್ಲಿಯೂ ಸಹ ಇದೇ ತತ್ವ ಅನ್ವಯಿಸುತ್ತದೆ. ಸಣ್ಣ ಪೇಲೋಡ್ಗಳು (payloads) ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ನಲ್ಲಿ ಕಡಿಮೆ RAM ಅನ್ನು ಬಳಸುತ್ತವೆ. ಇದು ಲಭ್ಯವಿರುವ ಅತ್ಯಂತ ಕಡಿಮೆ ವೆಚ್ಚದ ಪರಿಹಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಆದರೂ Laravel ನಲ್ಲಿ SELECT * ಎಂಬುದು ಡಿಫಾಲ್ಟ್ ವರ್ತನೆಯಾಗಿರುವುದರಿಂದ ಇದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಸುಲಭವಾಗಿದೆ.
EXPLAIN ಮೂಲಕ ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಮಾರ್ಗದರ್ಶನ ಮಾಡಿ
EXPLAIN ಅನ್ನು ಮೊದಲು ಬಳಸದೆ ಎಂದಿಗೂ ಸ್ಲೋ ಕ್ವೇರಿಯನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಬೇಡಿ. MySQL ನಲ್ಲಿ, EXPLAIN ಕೀವರ್ಡ್ ಕ್ವೇರಿ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಪ್ಲಾನ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಆಪ್ಟಿಮೈಸರ್ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಹುಡುಕಲು ಹೇಗೆ ಉದ್ದೇಶಿಸಿದೆ ಎಂಬುದನ್ನು ಇದು ನಿಖರವಾಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.
type ಕಾಲಂ ಕಡೆ ಗಮನ ಕೊಡಿ. ನೀವು ALL ಎಂದು ನೋಡಿದರೆ, MySQL ಪೂರ್ಣ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್ (full table scan) ಮಾಡುತ್ತಿದೆ ಎಂದರ್ಥ. ಅಂದರೆ ನಿಮ್ಮ WHERE ಕ್ಲಾಸ್ ಅನ್ನು ಪೂರೈಸಲು ಅದು ಪ್ರತಿಯೊಂದು ಸಾಲನ್ನು ಓದುತ್ತಿದೆ ಎಂದರ್ಥ. ಆಪ್ಟಿಮೈಸರ್ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತಿದೆಯೇ ಎಂದು ನೋಡಲು key ಕಾಲಂ ಅನ್ನು ಗಮನಿಸಿ. ನಂತರ Extra ಕಾಲಂ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ನೀವು Using temporary ಅಥವಾ Using filesort ಅನ್ನು ಕಂಡರೆ, ನಿಮ್ಮ ಪ್ರಸ್ತುತ ರಚನೆಯು ಕ್ವೇರಿಯನ್ನು ಸುಲಭವಾಗಿ ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ MySQL ಮಧ್ಯಂತರ ಟೇಬಲ್ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದೆ ಅಥವಾ ಮೆಮೊರಿಯಲ್ಲಿ ಸಾಲನ್ನು ಜೋಡಿಸುತ್ತಿದೆ (sorting) ಎಂದರ್ಥ.
ನಿಮ್ಮ MySQL ಕ್ಲೈಂಟ್ನಲ್ಲಿ EXPLAIN ಅನ್ನು ರನ್ ಮಾಡಿ ಅಥವಾ ಔಟ್ಪುಟ್ ಅನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವ ಸಾಧನವನ್ನು ಬಳಸಿ. ಒಮ್ಮೆ ನೀವು ಪ್ಲಾನ್ ಅನ್ನು ನೋಡಿದ ನಂತರ, ಸಮಸ್ಯೆ ಇಲ್ಲದ ಇಂಡೆಕ್ಸ್ ಆಗಿದೆಯೇ, ಕೆಟ್ಟ ಜಾಯಿನ್ (bad join) ಆಗಿದೆಯೇ ಅಥವಾ ಇಂಜಿನ್ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಪ್ರೆಡಿಕೇಟ್ ಆಗಿದೆಯೇ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ. ಆಗ ಊಹಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಇಂಡೆಕ್ಸ್ (Index) ಮಾಡಿ
ಲೊಕಪ್ಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ಇಂಡೆಕ್ಸ್ಗಳು ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾದ ಸಾಧನಗಳಾಗಿವೆ, ಆದರೆ ಅವು ನೀವು ಕ್ವೇರಿ ಮಾಡುವ ರೀತಿಯನ್ನು ಹೊಂದಿದ್ದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಸರಿಯಾದ ಇಂಡೆಕ್ಸ್ ಇಲ್ಲದಿದ್ದರೆ, MySQL ಸಾಲು ಸಾಲಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ. ಸಾವಿರ ಸಾಲುಗಳಿರುವ ಟೇಬಲ್ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯ (development) ಸಮಯದಲ್ಲಿ ಇದು ಸರಿಯಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಹತ್ತು ಮಿಲಿಯನ್ ಸಾಲುಗಳಿರುವ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಇದು ವಿಫಲವಾಗಬಹುದು.
WHERE ಕ್ಲಾಸ್ಗಳಲ್ಲಿ ಪದೇ ಪದೇ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಫೀಲ್ಡ್ಗಳಿಗಾಗಿ ಸಿಂಗಲ್-ಕಾಲಂ ಇಂಡೆಕ್ಸ್ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನೀವು ನಿರಂತರವಾಗಿ status ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಿದ್ದರೆ, status ಮೇಲೆ ಇಂಡೆಕ್ಸ್ ಸೇರಿಸಿ.
ಒಂದು ಕ್ವೇರಿ ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಕಾಲಂಗಳ ಮೇಲೆ ಫಿಲ್ಟರ್ ಮಾಡಿದಾಗ, ಕಾಂಪೋಸಿಟ್ ಇಂಡೆಕ್ಸ್ಗಳ (composite indexes) ಕಡೆಗೆ ಗಮನ ಹರಿಸಿ. ಇಂಡೆಕ್ಸ್ ಒಳಗಿನ ಕಾಲಂಗಳ ಕ್ರಮವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ MySQL ಕಾಂಪೋಸಿಟ್ ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ಎಡದಿಂದ ಬಲಕ್ಕೆ ಓದುತ್ತದೆ. ಇದನ್ನು 'ಲೆಫ್ಟ್ಮೋಸ್ಟ್ ಪ್ರಿಫಿಕ್ಸ್ ರೂಲ್' (leftmost prefix rule) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಕ್ವೇರಿ user_id ಮೂಲಕ ಹುಡುಕಿ ನಂತರ created_at ಮೂಲಕ ಆರ್ಡರ್ ಮಾಡಿದರೆ, (user_id, created_at) ಮೇಲಿನ ಕಾಂಪೋಸಿಟ್ ಇಂಡೆಕ್ಸ್ ಗಮನಾರ್ಹವಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕ್ರಮವನ್ನು ಉಲ್ಟಾ ಮಾಡಿದರೆ, ಆಪ್ಟಿಮೈಸರ್ ಫಿಲ್ಟರ್ಗಾಗಿ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಬಳಸದಿರಬಹುದು.
ಪ್ರತಿಯೊಂದು ಕಾಲಂಗೆ ಇಂಡೆಕ್ಸ್ ಮಾಡಬೇಡಿ. ಪ್ರತಿಯೊಂದು ಇಂಡೆಕ್ಸ್ ಕೂಡ ಇನ್ಸರ್ಟ್ಸ್ (inserts), ಅಪ್ಡೇಟ್ಸ್ (updates) ಮತ್ತು ಡಿಲೀಟ್ಸ್ಗಳಿಗೆ (deletes) ಹೆಚ್ಚಿನ ಹೊರೆ ನೀಡುತ್ತದೆ ಏಕೆಂದರೆ MySQL ಆ ರಚನೆಯನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಅಳತೆ ಮಾಡುವಾಗ ಕಂಡುಕೊಂಡ ಮಾದರಿಗಳ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇರಿಸಿ.
ಕಾಲಂಗಳಿಂದ ಫಂಕ್ಷನ್ಗಳನ್ನು ದೂರವಿಡಿ
ಈ ತಪ್ಪು ಅರಿವಿಲ್ಲದಂತೆ ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ನೀವು WHERE ಕ್ಲಾಸ್ ಒಳಗಡೆ ಒಂದು ಕಾಲಂ ಅನ್ನು ಫಂಕ್ಷನ್ನಲ್ಲಿ ಬಳಸಿದಾಗ, MySQL ಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ