האצת מחברי PHP עבור Tarantool באמצעות Async, Swoole ו-Parallel

במערכת האקולוגית של PHP ישנם כיום שני מחברים לעבודה עם שרת Tarantool - זוהי הרחבה הרשמית של PECL tarantool/tarantool-php, כתוב ב-C, ו tarantool-php/client, כתוב ב-PHP. אני המחבר של האחרון.

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

מה נבדוק?

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

• סוול ― מסגרת אסינכרונית בעלת ביצועים גבוהים עבור PHP. בשימוש על ידי ענקיות אינטרנט כמו עליבאבא ובאידו. מאז גרסה 4.1.0 הופיעה שיטת קסם SwooleRuntime::enableCoroutine(), המאפשר לך "להמיר ספריות רשת PHP סינכרוניות לספריות אסינכרוניות עם שורת קוד אחת."
• Async הייתה עד לאחרונה הרחבה מבטיחה מאוד לעבודה אסינכרונית ב-PHP. למה עד לאחרונה? לצערי, מסיבה שאינה ידועה לי, המחבר מחק את המאגר וגורלו העתידי של הפרויקט אינו ברור. אני אצטרך להשתמש בו одним ממזלגות. בדומה ל-Swoole, הרחבה זו מאפשרת לך להפעיל בקלות את המכנסיים בלחיצת כף היד כדי לאפשר אסינכרון על ידי החלפת היישום הסטנדרטי של זרמי TCP ו-TLS בגרסאות הא-סינכרוניות שלהם. זה נעשה באמצעות האפשרות "async.tcp = 1".
• מקביל - הרחבה חדשה למדי של ג'ו ווטקינס הידוע, מחברם של ספריות כמו phpdbg, apcu, pthreads, pcov, uopz. התוסף מספק API לריבוי הליכי שרשור ב-PHP וממוקם כתחליף ל-pthreads. מגבלה משמעותית של הספרייה היא שהיא עובדת רק עם גרסת ZTS (Zend Thread Safe) של PHP.

איך נבדוק?

בואו נשיק מופע של Tarantool עם רישום כתיבה קדימה מושבת (wal_mode = אין) ומאגר רשת מוגדל (readahead = 1 * 1024 * 1024). האפשרות הראשונה תבטל את העבודה עם הדיסק, השנייה תאפשר לקרוא בקשות נוספות ממאגר מערכת ההפעלה ובכך למזער את מספר קריאות המערכת.

עבור בנצ'מרקים שעובדים עם נתונים (הוספה, מחיקה, קריאה וכו'), לפני התחלת ה-benchmark, יווצר (מחדש) רווח memtx, שבו ערכי האינדקס העיקריים נוצרים על ידי מחולל של ערכי מספרים שלמים מסודרים (רצף).
המרחב DDL נראה כך:

space = box.schema.space.create(config.space_name, {id = config.space_id, temporary = true})
space:create_index('primary', {type = 'tree', parts = {1, 'unsigned'}, sequence = true})
space:format({{name = 'id', type = 'unsigned'}, {name = 'name', type = 'string', is_nullable = false}})

במידת הצורך, לפני הפעלת הבנצ'מרק, החלל מתמלא ב-10,000 טופלים של הטופס

{id, "tuplе_<id>"}

ניתן לגשת לטופלים באמצעות ערך מפתח אקראי.

המדד עצמו הוא בקשה בודדת לשרת, אשר מבוצעת 10,000 פעמים (סיבובים), אשר, בתורם, מבוצעות באיטרציות. האיטרציות חוזרות על עצמן עד שכל סטיות הזמן בין 5 איטרציות נמצאות בשגיאה מקובלת של 3%*. לאחר מכן, התוצאה הממוצעת נלקחת. יש הפסקה של שנייה אחת בין איטרציות כדי למנוע מהמעבד להחניק. אספן האשפה של לואה מושבת לפני כל איטרציה ונאלץ להתחיל לאחר סיומו. תהליך ה-PHP מופעל רק עם ההרחבות הנחוצות למבחן השוואת ביצועים, כאשר אחסון פלט מופעל ואוסף האשפה מושבת.

* ניתן לשנות את מספר הסיבובים, האיטרציות וסף השגיאה בהגדרות המבחן.

סביבת בדיקה

התוצאות שפורסמו להלן נעשו ב-MacBookPro (2015), מערכת הפעלה - Fedora 30 (גרסת ליבה 5.3.8-200.fc30.x86_64). Tarantool הושק ב-docker עם הפרמטר "--network host".

גרסאות חבילה:

Tarantool: 2.3.0-115-g5ba5ed37e
דוקר: 19.03.3, בניית a872fc2f86
PHP: 7.3.11 (cli) (נבנה: 22 באוקטובר 2019 08:11:04)
tarantool/client: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ תיקון עבור 7.3)*
ext-msgpack: 2.0.3
אסינכרון חיצוני: 0.3.0-8c1da46
אקסט-wool: 4.4.12
מקביל חיצוני: 1.1.3

* למרבה הצער, המחבר הרשמי לא עובד עם גירסת PHP > 7.2. כדי לקמפל ולהפעיל את התוסף ב-PHP 7.3, הייתי צריך להשתמש תיקון.

ממצאים

מצב סינכרוני

פרוטוקול Tarantool משתמש בפורמט בינארי חבילת הודעות לעשות סדרה של הודעות. במחבר ה-PECL, הסידרה מוסתרת עמוק במעמקי הספרייה ומשפיעה על תהליך הקידוד מקוד Userland לא נראה אפשרי. מחבר PHP טהור, להיפך, מספק את היכולת להתאים אישית את תהליך הקידוד על ידי הרחבת המקודד הסטנדרטי או על ידי שימוש ביישום משלך. ישנם שני מקודדים זמינים מהקופסה, אחד מבוסס על msgpack/msgpack-php (הרחבה הרשמית של MessagePack PECL), השני פועל rybakit/msgpack (ב-PHP טהור).

לפני השוואת מחברים, נמדוד את הביצועים של מקודדי MessagePack עבור מחבר PHP ובבדיקות נוספות נשתמש בזה שמראה את התוצאה הטובה ביותר:

למרות שגרסת ה-PHP (Pure) נחותה מהרחבת PECL במהירות, בפרויקטים אמיתיים עדיין הייתי ממליץ להשתמש בה rybakit/msgpack, כי בהרחבה הרשמית של MessagePack מפרט הפורמט מיושם באופן חלקי בלבד (לדוגמה, אין תמיכה בסוגי נתונים מותאמים אישית, שבלעדיו לא תוכל להשתמש ב-Decimal - סוג נתונים חדש שהוצג ב-Tarantool 2.3) ויש לו מספר אחרים проблем (כולל בעיות תאימות עם PHP 7.4). ובכן, באופן כללי, הפרויקט נראה נטוש.

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

כפי שניתן לראות מהגרף, מחבר PECL (Tarantool) מציג ביצועים טובים יותר בהשוואה למחבר PHP (Client). אבל זה לא מפתיע, בהתחשב בכך שהאחרון, בנוסף להיותו מיושם בשפה איטית יותר, למעשה עושה יותר עבודה: אובייקט חדש נוצר עם כל קריאה בקש и תְגוּבָה (במקרה של Select - גם קריטריונים, ובמקרה של Update/Upsert - תפעול), ישויות נפרדות הקשר, אורז и הנדלר הם גם מוסיפים תקורה. ברור שלגמישות יש מחיר. עם זאת, באופן כללי, מתורגמן PHP מציג ביצועים טובים, למרות שיש הבדל, הוא חסר משמעות ואולי יהיה אפילו פחות בעת שימוש בטעינה מוקדמת ב-PHP 7.4, שלא לדבר על JIT ב-PHP 8.

בוא נמשיך הלאה. Tarantool 2.0 הוסיפה תמיכה עבור SQL. בואו ננסה לבצע פעולות Select, Insert, Update and Delete באמצעות פרוטוקול SQL ולהשוות את התוצאות עם המקבילות noSQL (בינאריות):

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

אסינק

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

"פזר" 10,000 פעולות על פני 25 קורותינים וראה מה קורה:

מספר הפעולות לשנייה גדל ביותר מפי 3 עבור tarantool-php/client!

למרבה הצער, מחבר PECL לא התחיל עם אסינכרון חיצוני.

מה עם SQL?

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

סוול

שוב אנו מגלים את המספר האופטימלי של קורוטינים, הפעם עבור Swoole:

בואו נעצור ב-25. בואו נחזור על אותו טריק כמו עם הרחבה Async - נחלק 10,000 פעולות בין 25 קורוטינים. בנוסף, נוסיף בדיקה נוספת בה נחלק את כל העבודה ל-2 שני תהליכים (כלומר, כל תהליך יבצע 5,000 פעולות ב-25 קורוטינים). תהליכים ייווצרו באמצעות SwooleProcess.

תוצאות:

Swole מציגה תוצאה מעט נמוכה יותר בהשוואה ל-Async כשהיא מופעלת בתהליך אחד, אבל עם 2 תהליכים התמונה משתנה בצורה דרמטית (המספר 2 לא נבחר במקרה; במכונה שלי, היו אלה 2 תהליכים שהראו את התוצאה הטובה ביותר).

אגב, בתוסף Async יש גם API לעבודה עם תהליכים, אבל שם לא הבחנתי בשום הבדל מהפעלת benchmarks בתהליכים אחד או יותר (ייתכן שפישלתי איפשהו).

SQL לעומת פרוטוקול בינארי:

כמו ב-Async, ההבדל בין פעולות בינאריות ל-SQL מתבטל במצב אסינכרוני.

מקביל

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

זה שווה ל-16 במחשב שלי. בוא נריץ נקודות מידה של מחברים על 16 פתילים מקבילים:

כפי שאתה יכול לראות, התוצאה אפילו טובה יותר מאשר עם הרחבות אסינכרוניות (לא סופר את Swoole שפועל על 2 תהליכים). שים לב שעבור מחבר PECL, פעולות העדכון וההעלאה ריקות. זה נובע מהעובדה שפעולות אלה נכשלו עם שגיאה - אני לא יודע אם זו הייתה אשמתו של ext-parallel, ext-tarantool, או שניהם.

כעת נשווה את ביצועי SQL:

שמתם לב לדמיון עם הגרף עבור מחברים הפועלים באופן סינכרוני?

יַחַד

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

* לא ניתן היה להשיק Swoole coroutines עם Parallel; נראה שהרחבות אלו אינן תואמות.

אז התוצאות הסופיות:

במקום מסקנה

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

מקור: www.habr.com