ಚಾಟಿ SQL ಅಪ್ಲಿಕೇಶನ್ VPN ಮೇಲೆ ಏಕೆ ನಿಧಾನವಾಗುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಬ್ಯಾಚ್ ಮಾಡಬೇಕು

ಸ್ಥಳೀಯ ಜಾಲದಲ್ಲಿ ಒಂದು ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ತೆರೆಯುವ ಫಾರ್ಮ್ VPN ಮೇಲೆ ಐದು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಂಪರ್ಕದಲ್ಲಿ ಫೈಲ್ ನಕಲು ಪೂರ್ಣ ವೇಗದಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ವ್ಯತ್ಯಾಸ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಲ್ಲಿಲ್ಲ. ಫಾರ್ಮ್ ಉತ್ತರಗಳ ಅನುಕ್ರಮಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಹೆಜ್ಜೆಯಲ್ಲೂ ಪೂರ್ಣ ಸುತ್ತಿನ ಪ್ರಯಾಣವನ್ನು ತೆತ್ತುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಫೈಲ್ ನಕಲು ಬೈಟ್‌ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಚಲನೆಯಲ್ಲಿರಿಸುತ್ತದೆ. ಪ್ರವೇಶ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ಕಾಯುವಿಕೆಗಳನ್ನು ಎಣಿಸಿ.

ಲಕ್ಷಣ ಪರದೆ, ಕ್ವೆರಿ ಅಲ್ಲ

ಆ ಪರದೆಯ ಪ್ರತಿ ಕ್ವೆರಿಯೂ ವೇಗವಾಗಿರಬಹುದು ಮತ್ತು ಪರದೆ ಇನ್ನೂ ನಿಧಾನವಾಗಿರಬಹುದು, ಏಕೆಂದರೆ ಒಟ್ಟು ಮೊತ್ತವು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯಗಳ ಮೊತ್ತವಲ್ಲ, ಕಾಯುವಿಕೆಗಳ ಮೊತ್ತ. ಎರಡು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಡೆಯುವ ಹೇಳಿಕೆಯೂ, ಮುಂದಿನದನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಫಲಿತಾಂಶವನ್ನು ಸ್ವೀಕರಿಸಬೇಕಾದಾಗ ಪೂರ್ಣ ಸುತ್ತಿನ ಪ್ರಯಾಣವನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ. ನಲವತ್ತು ಮಿಲಿಸೆಕೆಂಡುಗಳ ವಿಳಂಬವಿರುವ ಮಾರ್ಗದಲ್ಲಿ, ನೂರು ಅವಲಂಬಿತ ಕರೆಗಳು ಯಾವುದೇ ರೆಂಡರಿಂಗ್ ಕೆಲಸ ಆರಂಭವಾಗುವ ಮೊದಲು ಸುಮಾರು ನಾಲ್ಕು ಸೆಕೆಂಡುಗಳಷ್ಟು ಸೇರುತ್ತವೆ. ಈ ಅಂಕಗಣಿತವು ಕಾಯುವಿಕೆಯ ಮಾದರಿ, ನಿಮ್ಮ ಸಂಪರ್ಕದ ಮಾಪನವಲ್ಲ.

ಅದಕ್ಕಾಗಿಯೇ ವೇಗ ಪರೀಕ್ಷೆ ನಿರ್ದೋಷವಾಗಿ ಕಾಣುತ್ತದೆ. ಬಲ್ಕ್ ವರ್ಗಾವಣೆ ಥ್ರೂಪುಟ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆ, ಚಾಟಿ ಫಾರ್ಮ್ ವಿಳಂಬವನ್ನು ಅಳೆಯುತ್ತದೆ, ಮತ್ತು VPN ಒಂದರಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದ್ದು ಇನ್ನೊಂದರಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿರಬಹುದು. ಆದ್ದರಿಂದ ಪರದೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುವ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಎಂದರೆ ಸಂಪರ್ಕವನ್ನಲ್ಲ, ಪರದೆಯನ್ನೇ ಅಳೆಯುವುದು.

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಒಂದು ಬಳಕೆದಾರ ಕ್ರಿಯೆಯ ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗಿನ ಸಮಯವನ್ನು ದಾಖಲಿಸಿ. ನಂತರದ ಸರಿಪಡಿಸುವಿಕೆ ಕೆಲಸ ಮಾಡಿದೆಯೇ ಎಂದು ಹೇಳಬಲ್ಲ ಏಕೈಕ ಆಧಾರ ಅದೇ ಸಂಖ್ಯೆ.

ಒಂದು ಬಳಕೆದಾರ ಕ್ರಿಯೆಯಲ್ಲಿ ಅನುಕ್ರಮ ಕಾಯುವಿಕೆಗಳನ್ನು ಎಣಿಸಿ

ಊಹಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್‌ಗೆ ಅಳತೆ ಒಳಸೇರಿಸಿ. psql ನಲ್ಲಿ \timing on ಪ್ರತಿ ಹೇಳಿಕೆಯ ಕಳೆದ ಸಮಯವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು EXPLAIN (ANALYZE, BUFFERS) ಸರ್ವರ್ ಆ ಸಮಯದಲ್ಲಿ ಎಷ್ಟನ್ನು ನಿಜವಾಗಿ ಕೆಲಸಕ್ಕೆ ಕಳೆದಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಆ ಎರಡು ಸಂಖ್ಯೆಗಳ ನಡುವಿನ ಅಂತರ ನಿಮ್ಮ ಜಾಲ ಮತ್ತು ಕ್ಲೈಂಟ್ ವೆಚ್ಚ. ಒಂದು ಹೇಳಿಕೆ ಎರಡು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಡೆದು ಕ್ಲೈಂಟ್ ಅರವತ್ತು ದಾಖಲಿಸಿದರೆ, ಉಳಿದ ಐವತ್ತೆಂಟು ಪ್ರಯಾಣ ಮತ್ತು ಸ್ಥಳೀಯ ಸಂಸ್ಕರಣೆ, ಯಾವುದೇ ಸೂಚ್ಯಂಕ ಅವನ್ನು ತೆಗೆಯುವುದಿಲ್ಲ. ಪರದೆ ಹೊರಡಿಸುವ ಪ್ರತಿ ಹೇಳಿಕೆಗೂ ಈ ಹೋಲಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯಗಳಲ್ಲ, ಅಂತರಗಳನ್ನು ಕೂಡಿಸಿ.

ಫಲಿತಾಂಶವನ್ನು ಅನುಕ್ರಮ ಕಾಯುವಿಕೆಗಳ ಎಣಿಕೆಯಾಗಿ ಬರೆದಿಡಿ. ಮುಂದಿನ ಎರಡು ವಿಭಾಗಗಳು ಕಡಿಮೆ ಮಾಡಬಲ್ಲ ಪ್ರಮಾಣ ಅದೇ, ಮತ್ತು ಅದು ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ವಾದಿಸಬಹುದಾದ ಸಂಖ್ಯೆ.

ಸ್ವತಂತ್ರ ಕರೆಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡಿ, ಅವಲಂಬಿತವಾದವನ್ನು ಉಳಿಸಿ

ಒಂದರ ಫಲಿತಾಂಶವನ್ನು ಇನ್ನೊಂದು ಓದದ ಎರಡು ಹೇಳಿಕೆಗಳು ಜೊತೆಯಾಗಿ ಪ್ರಯಾಣಿಸಿ ಒಮ್ಮೆ ಸಂಗ್ರಹಗೊಳ್ಳಬಹುದು, ಇದು ಎರಡು ಕಾಯುವಿಕೆಗಳನ್ನು ಒಂದಾಗಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಮೊದಲನೆಯ ಮೌಲ್ಯವನ್ನು ಬೇಕಾಗಿರುವ ಎರಡು ಹೇಳಿಕೆಗಳು ಹಾಗೆ ಮಾಡಲಾರವು, ಏಕೆಂದರೆ ಅವಲಂಬನೆ ನಿಜವಾದದ್ದು ಮತ್ತು ಅದನ್ನು ಬ್ಯಾಚ್ ಮಾಡುವುದು ಪ್ರೋಗ್ರಾಂ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಏನನ್ನೂ ಮರುಬರೆಯುವ ಮೊದಲು ಕರೆಗಳನ್ನು ಆ ಎರಡು ರಾಶಿಗಳಾಗಿ ವಿಂಗಡಿಸಿ; ಪ್ರತಿ ರಾಶಿಯ ಗಾತ್ರ ಏನು ಸಾಧ್ಯ ಎಂದು ಹೇಳುತ್ತದೆ.

ಸೆಟ್ ಆಧಾರಿತ ಕೆಲಸ ಬ್ಯಾಚಿಂಗ್‌ಗಿಂತ ಹೆಚ್ಚು ಸಂಪೂರ್ಣವಾಗಿ ಕಾಯುವಿಕೆಗಳನ್ನು ತೆಗೆಯುತ್ತದೆ. ಲೂಪ್ ಒಂದೊಂದಾಗಿ ಪಡೆಯುತ್ತಿದ್ದ ಸಾಲುಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವ ಒಂದು ಕ್ವೆರಿ ಲೂಪ್ ಮತ್ತು ಸುತ್ತಿನ ಪ್ರಯಾಣಗಳೆರಡನ್ನೂ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಮೊದಲು ಲೂಪ್ ಹುಡುಕಿ, ಏಕೆಂದರೆ ಅದು ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಲಾಭ ಮತ್ತು ಪರಿಶೀಲಿಸಲು ಸುಲಭ ಬದಲಾವಣೆ.

ಬ್ಯಾಚ್ ಇನ್ನೂ ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ಮತ್ತು ವಹಿವಾಟು ಗಡಿಗಳನ್ನು ಕಾಪಾಡಬೇಕು. ಸಂಬಂಧವಿಲ್ಲದ ಹೇಳಿಕೆಗಳನ್ನು ಒಂದೇ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಜೋಡಿಸುವುದು ಸುರಕ್ಷಿತ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಲ, ಮತ್ತು ವಿಫಲ ಹೇಳಿಕೆಯನ್ನು ಯಶಸ್ವಿ ಸಲ್ಲಿಕೆಯ ಹಿಂದೆ ಮರೆಮಾಡುವ ಬ್ಯಾಚ್ ಉಳಿಸಿದ ಕಾಯುವಿಕೆಗಳಿಗಿಂತ ಕೆಟ್ಟದು.

ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಖರೀದಿಸುವ ಮೊದಲು ಸಂಪರ್ಕಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಿ

ಹೊಸ ಸಂಪರ್ಕಕ್ಕೆ ಹೆಸರು ವಿಭೇದನ, TCP ಕೈಕುಲುಕಾಟ, TLS ಮಾತುಕತೆ ಮತ್ತು ದೃಢೀಕರಣ ವೆಚ್ಚವಾಗುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ವಿಳಂಬದ ಮಾರ್ಗದಲ್ಲಿ ಅವು ಪ್ರತಿಯೊಂದೂ ಮೊದಲ ಕ್ವೆರಿ ಓಡುವ ಮೊದಲು ಇನ್ನೊಂದು ಸುತ್ತಿನ ಪ್ರಯಾಣ. ಸಂಪರ್ಕ ಕೊಳಗಳು ಈ ವೆಚ್ಚವನ್ನು ಪ್ರತಿ ಕರೆಗೆ ಒಮ್ಮೆಯಲ್ಲ, ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಒಮ್ಮೆ ತೆರಲು ಇವೆ.

ADO.NET ನಲ್ಲಿ, ಕೊಳದ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚುವುದು ಅಥವಾ dispose ಮಾಡುವುದು ಹೊಸ ಭೌತಿಕ ಸಂಪರ್ಕ ತೆರೆಯುವ ಬದಲು ಅದನ್ನು ಮರುಬಳಕೆಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೋರಿಕೆಯಂತೆ ಕಾಣುವ ಮಾದರಿ ಹಲವು ಬಾರಿ ಸರಿಯಾದ ಬಳಕೆಯೇ. ಕೊಳ ನಿಜವಾಗಿ ಬಳಕೆಯಲ್ಲಿದೆಯೇ ಎಂದು ಊಹಿಸದೆ ಪರಿಶೀಲಿಸಿ: ಭೌತಿಕ ಸಂಪರ್ಕ ಸೃಷ್ಟಿಯನ್ನು ಲಾಗ್ ಮಾಡಿ, ಅಥವಾ ಪರದೆ ಓಡುವಾಗ ಸರ್ವರ್‌ನ ಸೆಷನ್ ಎಣಿಕೆಯನ್ನು ಗಮನಿಸಿ. SQL ಕಾರ್ಯಕ್ಷಮತೆ ಮಾರ್ಗದರ್ಶನ ಸುತ್ತಿನ ಪ್ರಯಾಣಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮತ್ತು ಆಗಾಗ್ಗಿನ ad hoc ಕರೆಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡುವ ಬಗ್ಗೆ ಅದೇ ಅಂಶವನ್ನು ಹೇಳುತ್ತದೆ, ಸೇವಾ-ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ, ಅವನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ನಿಯೋಜನೆಗೆ ಹೊಂದಿಸಬೇಕು.

ಕೊಳ ಮಾಡುವುದು ಸ್ಥಾಪನ ವೆಚ್ಚವನ್ನು ತೆಗೆಯುತ್ತದೆ ಮತ್ತು ಅನುಕ್ರಮ ಕ್ವೆರಿ ಕಾಯುವಿಕೆಗಳನ್ನು ಮುಟ್ಟದೆ ಬಿಡುತ್ತದೆ. ಅದು ಸ್ವತಃ ಪರಿಹಾರವಲ್ಲ, ಸ್ವಚ್ಛ ಮಾಪನಕ್ಕೆ ಪೂರ್ವಾಪೇಕ್ಷೆ.

ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಡೇಟಾದ ಹತ್ತಿರ ಸರಿಸುವುದನ್ನು ತೂಗಿ ನೋಡಿ

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಡೇಟಾಬೇಸ್ ಹತ್ತಿರ ಓಡಿಸುವುದು ಅನೇಕ ದೂರದ ಡೇಟಾಬೇಸ್ ವಿನಿಮಯಗಳನ್ನು ಒಂದೇ ದೂರದ ಪ್ರದರ್ಶನ ಸೆಷನ್‌ನಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ. ಚಾಟಿ ಕೆಲಸಭಾರಕ್ಕೆ ಅದು ದೊಡ್ಡ ಬದಲಾವಣೆಯಾಗಬಹುದು, ಮತ್ತು ಅದು ಕಾರ್ಯಕ್ಷಮತೆಯಷ್ಟೇ ಕಾರ್ಯಾಚರಣೆಯ ಬದಲಾವಣೆಯೂ ಹೌದು: ಸೆಷನ್ ನಿರ್ವಹಣೆ, ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ತಂತ್ರಾಂಶ ನಿಯೋಜನೆ ಮತ್ತು ಬಳಕೆದಾರ ಅನುಭವ ಎಲ್ಲವೂ ಅಪ್ಲಿಕೇಶನ್ ಜೊತೆ ಸರಿಯುತ್ತವೆ.

ಯಾವ ದಿಕ್ಕು ವೇಗ ಎಂದು ಊಹಿಸುವ ಮೊದಲು ನಿಜವಾದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಅದು ವರ್ಗಾಯಿಸುವ ಡೇಟಾವನ್ನು ಅಳೆಯಿರಿ. ದೂರದ ಡೆಸ್ಕ್‌ಟಾಪ್ ಸೆಷನ್ ಪಿಕ್ಸೆಲ್‌ಗಳನ್ನು ಸರಿಸುತ್ತದೆ, ಮತ್ತು ದಟ್ಟ ಗ್ರಾಫಿಕ್ಸ್ ಇರುವ ಪರದೆ ಅದೇ ಮಾರ್ಗದಲ್ಲಿ ಅದು ಬದಲಾಯಿಸಿದ ಕ್ವೆರಿಗಳಿಗಿಂತ ಕೆಟ್ಟದಾಗಿ ನಡೆಯಬಹುದು, ವಿಶೇಷವಾಗಿ ಕ್ಲೈಂಟ್ ನಿರಂತರವಾಗಿ ಮತ್ತೆ ಬರೆದಾಗ.

ನಂತರ ಮೂಲ ಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಮೂರು ಸಂಖ್ಯೆಗಳನ್ನು ಹೋಲಿಸಿ: ಅನುಕ್ರಮ ಕಾಯುವಿಕೆಗಳು, ಫಲಿತಾಂಶದ ಪ್ರಮಾಣ ಮತ್ತು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗಿನ ಪೂರ್ಣಗೊಳ್ಳುವ ಸಮಯ. ಡೇಟಾ ಸರಿಯಾಗಿರುವುದನ್ನು ಮತ್ತು ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಕಾಪಾಡಿಕೊಂಡು ಅಳೆಯಲಾದ ಬಳಕೆದಾರ ಕಾರ್ಯವನ್ನು ಸುಧಾರಿಸುವ ಬದಲಾವಣೆಯೇ ಉಳಿಸಿಕೊಳ್ಳಲು ಯೋಗ್ಯ.