למה אפליקציית SQL פטפטנית זוחלת דרך VPN ומה כדאי לאגד

טופס שנראה ברשת מקומית בפחות משנייה לוקח חמש שניות דרך VPN, בעוד שהעתקת קובץ באותו קישור רצה במלוא המהירות. ההבדל אינו ברוחב הפס. הטופס ממתין לרצף של תשובות ומשלם את מלוא ההלוך-חזור בכל שלב, בעוד שהעתקת הקובץ משאירה בתים בתנועה ברציפות. ספרו את ההמתנות האלה לפני שנוגעים בקו הגישה.

התסמין הוא מסך, לא שאילתה

כל שאילתה במסך הזה יכולה להיות מהירה והמסך עדיין יכול להיות איטי, משום שהסכום הוא סכום ההמתנות ולא סכום זמני ההרצה. פקודה שרצה בשתי אלפיות השנייה עדיין עולה סבב הלוך-חזור שלם כשהלקוח חייב לקבל את תוצאתה לפני שישלח את הבאה. בנתיב עם השהיה של ארבעים אלפיות השנייה, מאה קריאות תלויות מצטברות לכארבע שניות לפני שמתחילה עבודת ציור כלשהי. החשבון הזה הוא מודל של ההמתנה, לא מדידה של הקישור שלכם.

לכן מבחן מהירות נראה תמים. העברה בכמות גדולה מודדת תפוקה, טופס פטפטן מודד השהיה, ו-VPN יכול להיות מצוין באחד ורגיל בשני. לכן אבחון המסך פירושו מדידת המסך ולא הקישור.

רשמו את הזמן מקצה לקצה של פעולת משתמש אחת לפני שמשנים משהו. המספר הזה הוא קו הבסיס היחיד שיכול לומר לכם אם תיקון מאוחר עבד.

ספרו המתנות עוקבות בפעולת משתמש אחת

מדדו בלקוח במקום לנחש. ב-psql הפקודה \timing on מדפיסה את הזמן שחלף לכל פקודה, ו-EXPLAIN (ANALYZE, BUFFERS) מראה כמה מזמן זה השתמש השרת בפועל בעבודה.

הפער בין שני המספרים האלה הוא תקורת הרשת והלקוח שלכם. אם פקודה מבוצעת בשתי אלפיות השנייה והלקוח רושם שישים, חמישים ושמונה הנותרות הן נסיעה ועיבוד מקומי, ואף אינדקס לא יסיר אותן. חזרו על ההשוואה הזאת לכל פקודה שהמסך מוציא וסכמו את הפערים ולא את זמני ההרצה.

רשמו את התוצאה כמניין של המתנות עוקבות. זה הגודל ששני הפרקים הבאים יכולים להקטין, וזה מספר שאפשר להתווכח עליו עם ראיות.

אגדו את הקריאות הבלתי-תלויות, שמרו על התלויות

שתי פקודות שאינן קוראות את התוצאות זו של זו יכולות לנסוע יחד ולהיאסף פעם אחת, מה שהופך שתי המתנות לאחת. שתי פקודות שבהן השנייה זקוקה לערך של הראשונה אינן יכולות, משום שהתלות אמיתית וקיבוץ היה משנה את מה שהתוכנית עושה. מיינו את הקריאות לשתי הערמות האלה לפני שאתם כותבים מחדש משהו, וגודל כל ערמה אומר לכם מה אפשרי.

עבודה מבוססת קבוצות מסירה המתנות ביסודיות רבה יותר מאשר קיבוץ. שאילתה אחת שמחזירה את השורות שלולאה הביאה אחת לאחת מסירה גם את הלולאה וגם את סבבי ההלוך-חזור. חפשו קודם את הלולאה, משום שהיא בדרך כלל הרווח הגדול יותר והשינוי הקל יותר לבדיקה.

אצווה עדיין חייבת לשמר טיפול בשגיאות ואת גבולות הטרנזקציה. שרשור פקודות לא קשורות למחרוזת אחת אינו אופטימיזציה בטוחה, ואצווה שמסתירה פקודה שנכשלה מאחורי שליחה מוצלחת גרועה מההמתנות שחסכה.

השתמשו שוב בחיבורים לפני שקונים רוחב פס

חיבור חדש עולה פענוח שמות, לחיצת יד TCP, משא ומתן TLS ואימות, ובנתיב עם השהיה גבוהה כל אחד מאלה הוא סבב נוסף לפני שהשאילתה הראשונה רצה. מאגרי חיבורים קיימים כדי לשלם את העלות הזאת פעם אחת לכל תהליך ולא פעם אחת לכל קריאה.

ב-ADO.NET, סגירה או השלכה של חיבור מהמאגר מחזירה אותו לשימוש חוזר במקום לפתוח חיבור פיזי חדש, ולכן התבנית שנראית כמו דליפה היא לעתים קרובות השימוש הנכון. ודאו שהמאגר באמת בשימוש במקום להניח זאת: תעדו יצירת חיבורים פיזיים, או עקבו אחר מספר ההפעלות בשרת בזמן שהמסך רץ. הנחיות הביצועים של SQL אומרות את אותו הדבר על צמצום סבבים וקיבוץ קריאות אד-הוק תכופות, עם דוגמאות ספציפיות לשירות שעליכם למפות לפריסה שלכם.

איגוד מסיר את עלות ההקמה ומשאיר את המתנות השאילתות העוקבות ללא שינוי. זהו תנאי מוקדם למדידה נקייה ולא תיקון בפני עצמו.

שקלו להעביר את ההרצה קרוב יותר לנתונים

הרצת האפליקציה ליד מסד הנתונים מחליפה חילופי נתונים מרוחקים רבים בחיבור תצוגה מרוחק אחד. לעומס פטפטן זה יכול להיות שינוי גדול, וזהו שינוי תפעולי לא פחות מאשר שינוי ביצועים: ניהול הפעלות, בקרת גישה, פריסת תוכנה וחוויית משתמש כולם נעים עם האפליקציה.

מדדו את הממשק בפועל ואת הנתונים שהוא מעביר לפני שאתם מניחים שכיוון כלשהו מהיר יותר. הפעלת שולחן עבודה מרוחק מעבירה פיקסלים, ומסך עם גרפיקה צפופה יכול לתפקד גרוע יותר באותו נתיב מאשר השאילתות שהחליף, במיוחד כשהלקוח מצייר מחדש ברציפות.

אחר כך חזרו על הפעולה המקורית והשוו שלושה מספרים: המתנות עוקבות, נפח התוצאות וזמן ההשלמה מקצה לקצה. שיפור שמשנה את משימת המשתמש הנמדדת תוך שמירה על נכונות הנתונים ומדיניות הגישה הוא זה שכדאי לשמור.