כיצד גילינו בקשות API איטיות באתר WordPress

אנו מפתחים פלטפורמה חינוכית המאפשרת לך:

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

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

הסטק הטכנולוגי של הפלטפורמה

בחרנו ב-Vue.js כמסגרת צד-הלקוח, מה שאפשר לנו להפוך את ממשק המשתמש של הפונקציונליות המרכזית של הפרויקט לרספונסיבי – כלומר, פונקציונליות העורך והצגת השיעורים. המיוחד ביישום טמן בבניית התקשורת בין הלקוח לשרת בצורת בקשות API. הבקשות נשלחות בכמויות גדולות עקב הגישה לניהול פוסטים ב-CMS הנבחר (WordPress), ולכן צמצום מספר הבקשות לא היה אפשרי. עם זאת, מקביליות וביצוע אסינכרוני אפשרו להשיג את התוצאות הרצויות בביצועים.

שרת

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

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

לאחר בחינת לשונית ה-“network” בכלי הפיתוח של הדפדפן, גילינו שכל הבקשות האסינכרוניות לשרת פעלו כצפוי, למעט בקשות API שלקחו לפחות 3 שניות כל אחת. בדיקה מפורטת של הבקשה הראתה TTFB גבוה (זמן לבייט הראשון), המצביע על איטיות בצד הבאקאנד או השרת.

חושב אמפירית שלא משנה אילו פעולות ביצע נקודת הקצה של ה-API, התוצאה תהיה תמיד זהה – לפחות 3 שניות לעיבוד, שגדלות ל-5-6 שניות עם צמיחת מסד הנתונים.

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

שאלנו את עצמנו שוב ושוב את אותה השאלה:

מדוע מהירות בקשת API שאינה משתמשת במסד הנתונים בעת עיבוד לוגיקה פנימית מושפעת מגודל מסד הנתונים?

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

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

תוסף LearnDash השתמש ב-hook של WordPress בשם rest_api_init לא רק כדי לרשום את נקודות הקצה של ה-API והשדות שלו, אלא גם כדי לכלול בקרים נוספים עם לוגיקה, שאחד מהם הכיל בחירה רציפה ענקית ולא מאופטמת ממספר טבלאות במסד הנתונים. כך, ללא קשר לפונקציית ה-API של הנתיב, בחירה זו בוצעה בכל פעם ששלחנו בקשת API לשרת (וכאמור לעיל, נשלחות הרבה בקשות). הסיבה לגישה זו לא הייתה ברורה, אולם נשלחה בקשת הבהרה למפתחי תוסף LearnDash בתקווה לתיקון בגרסאות עתידיות.

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

תגובה מ

צוות הפיתוח של LearnDash

עדכנו זאת ומתכננים לשחרר את השינויים בגרסה הראשית הבאה.

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