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

כמה נקודות
לפי סדר:
1. בדוק RTT (round trip time)
2. נסה לאחד קבצי CSS
3. בדוק הגדרות cache.
4. בדוק למשתמש אנונימי ולמשתמש מזוהה
5. בדוק מהירות גישה ל mysql
apc apc apc!
או eaccelerator, xcache או דומיו
מניסיוני php accelerator יכול לחולל פלאים על vps.
יש כתבות מצוינות על הנושא אצל חאליד מ2bits למשל הכתבה הזו שמסבירה באופן מסודר...
http://2bits.com/articles/php-op-code-caches-accelerators-a-must-for-a-l...
בהצלחה
ליאור קסוס, לינוויט
דרופל, אנדרואיד וקוד פתוח
תודה+
חברים,
קודם כל תודה רבה על התגובה המהירה.
ליאור - בעקבות המלצתך קראתי קצת בנושא ואכן אני מתכוון להתקין את הeAccelerator. כשיהיו מסקנות בנושא, אפרסמן כאן.
yhager
1. איך בודקים RTT?
2. משתמש בgzip compression כך שאיחוד css לא אמור להשפיע משמעותית
3. cache מופעל
4. הבדיקות נעשו על anonymous users (היכן שלcache יש משמעות)
5. איך בודקים את מהירות הגישה לmysql?
ליאור, yhager - מתוך כך שלא התייחסתם למיקום הserver האם עליי להבין שלדעתכם מדובר בפרמטר זניח שאין לו השפעה רבה על הביצועים?
שוב תודה.
apc מול eaccelerator ומיקום השרת
אני בדרך כלל מתקין apc בגלל הפשטות ובגלל שהצוות שעומד מאחוריו אמין קצת יותר rasmus מי שכתב את php למשל.
לגבי מיקום השרת יש השפעה בעיקר לגביי זמני הטעינה והגישה אך עדיין אפשר להגיע לזמני טעינה של פחות מ2 שניות גם בשרתים מרוחקים (בתנאי שהם על תשתיות טובות).
shev.com שמארחים את דרופל ישראל (וגם את השרתים שלי) נותנים זמני תגובה מצוינים.
להבין את ההבדל במהירות בין הארץ לחול אפשר פשוט לעשות פינג לשרתים בארת ובחול ממצאיי (למטה) הגישה לשרתים (סבירים ) בארץ היא מתחת ל20 מילי-שניות ושל האתרים מחול כ200 מילי שניות.
הנה הנתונים בגישה לשרתים שלי...
PING dev.linnovate.net (212.150.164.41): 56 data bytes
64 bytes from 212.150.164.41: icmp_seq=0 ttl=57 time=15.327 ms
64 bytes from 212.150.164.41: icmp_seq=1 ttl=57 time=15.763 ms
64 bytes from 212.150.164.41: icmp_seq=2 ttl=57 time=16.157 ms
64 bytes from 212.150.164.41: icmp_seq=3 ttl=57 time=15.791 ms
^C
--- dev.linnovate.net ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.327/15.759/16.157/0.294 ms
bean:~ lior$ ping aguda.org.il
PING aguda.org.il (69.61.52.242): 56 data bytes
64 bytes from 69.61.52.242: icmp_seq=0 ttl=54 time=192.558 ms
64 bytes from 69.61.52.242: icmp_seq=1 ttl=54 time=193.251 ms
64 bytes from 69.61.52.242: icmp_seq=2 ttl=54 time=194.631 ms
64 bytes from 69.61.52.242: icmp_seq=3 ttl=54 time=194.493 ms
</cdoe?
ליאור קסוס, לינוויט
דרופל, אנדרואיד וקוד פתוח
בעניין: תודה+
אני לא חושב שהכיוון הוא להתקין מנועי cache אם יש לך בעיה בתצוגת דף סטטי בודד.
RTT בודקים ע"י הרצת ping.
gzip compression לא ישנה הרבה אם השרת רחוק, עדיין יידרשו הרבה round trips לשרת.
מיקום השרת לא חשוב, השאלה כמה זמן לוקח להגיע אליו.
מהירות הגישה ל mysql היא נושא מורכב. יש מספר כלים לבדיקות (כמו למשל מודול devel), או אולי הספק שלך נותן לך כלים כאלה.
אני מאמין שאם תסדר את נקודות 1 ו 2 למעלה, הבעיה תסתדר.
שיפור משמעותי בביצועים.
אז ככה...
התחלתי בהתקנת eAccelerator על הVPS - בתמורה קיבלתי שיפור מסוים אך לא די (בחרתי eAccelerator כיוון שהספק שלי המליץ עליו)
השיפור המשמעותי באמת נבע מ:
1. איחוד קבצי CSS. בעניין זה יצאתי מעט טמבל לגבי בתשובתי הקודמת ל-yhager...(משום מה חשבתי שהפעלתי את הכיווץ.)
2. טעינה של מרבית ה-JS בסוף הדף. שינוי זה עלול לייצר בעיות עם רכיבים מסויימים (אני נתקלתי בבעיה עם Coulior Slideshow) ובמקרים אלה יש לדאוג לטעינה מוקדמת של רכיבי הJS של אותו רכיב.
כפי הנראה (וכפי שטענתם) אין משמעות רבה למיקום השרת.
בסיכום שלושת השינויים הנ"ל שיפרו את ביצועי האתר במאות אחוזים...
תודה רבה.
איחוד קבצי CSS.
איחוד קבצי CSS. בעניין זה יצאתי מעט טמבל לגבי בתשובתי הקודמת ל-yhager...(משום מה חשבתי שהפעלתי את הכיווץ.)
שים לב שאתה מחליף פה בין איחוד לכיווץ. איחוד משמעותו טעינה של קובץ אחד שמכיל את המידע מכל קבצי ה CSS השונים במערכת. זה ייתן לך את השיפור המשמעותי.
כיווץ הוא פשוט כיווץ gzip המאפשר לשלוח פחות נתונים על קו התקשורת לצורך העברת אותה כמות של מידע. זה גם נותן שיפור, אבל זה כבר תלוי במרחק מהשרת ובתוכן הקבצים.
טעינה של מרבית ה-JS בסוף הדף.
זה כבר לא דף סטטי. כשאתה בודק ביצועים, כדאי לנטרל JS כדי לזהות איפה הבעיה. אכן, מומלץ לטעון את קבצי ה JS כמה שיותר מאוחר בעמוד (לא בהכרח בסוף). בדרופל קצת קשה להגיע לגרנולריות טובה כאן.
גם קבצי JS ניתן לאחד (ולכווץ) בדרופל 6 זה בנוי בפנים, ב 5 זה מודול להתקנה.
איחוד קבצי javascript
קישור למודול לדרופל 5:
http://drupal.org/project/javascript_aggregator
אמנון-מאיר לבב - ייעוץ משולב - סוף מעשה באפיון תחילה!
אפיון מיזמי אינטרנט, ליווי פרוייקטים בדרופל וייעוץ רב-תחומי
בעניין: איחוד קבצי javascript
בכוונה לא ציינתי את זה.
צריך להתייחס לפונקציונליות הזו בזהירות - למרות שלרוב זה עובד, לפעמים יש עם זה בעיות (למשל עם TinyMCE - http://drupal.org/node/243662).