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

לביצועי המערכת יש חשיבות רבה, אך בעיות ביצועים לא צריכות להטריד סטארט-אפים בתחילת דרכם. הם לא נכשלים בגלל ביצועים, אלא משום שאין להם מספיק משתמשים", כך אמר ויטלי קושנר – מייסד Astrails. קושנר אמר את הדברים ב-Rails Israel – ועידת ה-Ruby on Rails הבינלאומית הראשונה בישראל, שנערכה אתמול (ב') באקסודיה תל אביב בהפקת אנשים ומחשבים. הוא ציין, כי "בתחילת דרכה של גוגל (Google), למשל, הם חשבו שריבוי תוצאות בחיפוש יביא יותר גולשים. בפועל, קרה ההיפך: ריבוי התוצאות גרם לאיטיות בהעלאת הדף והם הפסידו גולשים".

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

"ביצועי המערכת מורכבים ממהירות, מתפוקה (throughput), מיכולת שדרוג (scalability) ומהמהירות שבה המשתמש הסופי חווה את האפליקציה", הסביר. "הבעיה מתחילה כשמתחילים לבזבז זמן על נושא הביצועים והשדרוגים – בעיקר על ביצועי התוכן, שהם הביצועים החשובים ביותר. Rails הם כל כך טובים, שבלי יותר מדי אופטימיזציה, אפשר לצאת לציבור ולהתחיל לקבל ביצועים טובים. כדי להשיג זאת, יש להגביל את מספר ה-records בבסיס הנתונים, להגביל את מספר ה-queries ולהגדיר אינדקסים. בתחילת הדרך לא הייתי ממליץ לעשות caching, כי מאוחר יותר זה עלול להביא לקטסטרופה בביצועים".

ריצ'רד שנימן, מפתח רובי (Ruby) ב-הרוקו (Heroku), אמר בכנס כי "אם יש לכם פרויקט שאתם רוצים לשכפל ולהריץ, אתם חייבים לוודא שקיימת אחידות (Consistency) בכל המכשירים שעליהם הוא אמור לרוץ".

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

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

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

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

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

ערן ברק לוי, מהנדס DevOps בקונטרה טכנולוגיות (Kontera Technologies), דיבר על ארכיטקטורה מוכוונת שירותים (SOA, ר"ת Service Oriented Architecture). לדבריו, "כשמספקים תמיכה לתנועה ברשת, יש לבצע חלוקת תפקידים ולהגדיר את הציפיות מצוות המו"פ. נקודה חשובה נוספת היא היכן האפליקציה רצה. יש לנתח את המלאי של כולם, כדי לאסוף נתונים, פסולת נתונים ועוד".

"הפתרון שלנו", ציין, "הוא לפרוס מערכת MCollective – מכניסים את כל המחשבים ברשת לקולקטיב אחד, כך שאפשר לשלוח שאלות לכל הקולקטיב. אחרי שפתרנו את בעיית המלאי, יש את סוגיית הפריסה (deployment). לשם כך אנחנו עוטפים כל אפליקציה ב-Tarball אחד".