دروپال

افزایش سرعت دیتابیس MySQlL InnoDB در ویندوز برای دروپال

اگر تا به حال دروپال را بر روی ویندوز نصب کرده باشید، احتمالا متوجه کند بودن بیش از حد آن شده اید. به خصوص در موقع نصب کردن یک ماژول جدید یا خالی کردن cache

دیتابیس MySQL دارای موتور های ذخیره سازی متعددی هست که از مهم ترین آن ها می توان به MyISAM و InnoDB اشاره کرد. موتور InnoDB قابلیت های پیشرفته تری دارد و دروپال 7 هم به طور پیش فرض از این موتور ذخیره سازی استفاده میکند.

اما InnoDB در ویندوز، سرعت نوشتن بسیار کندی دارد. و این باعث میشود که وقتی میخواهید صفحه ی مدیریت ماژول ها رو در دروپال باز کنید، بهتون به اندازه ی کافی فرصت میده که ناهارتون رو بخورید! :)

انتخاب بهترین میزبان یا هاست برای دروپال

دروپال هاست Drupalhost.ir is extremely awesomeشما دروپال را یاد میگیرید، آن را نصب میکنید، پیکربندی میکنید، به تدریج با محیط آن آشنا می شوید و کم کم نیازمندی های خودتان را بهتر می شناسید. سپس به سراغ ماژول ها می روید و سعی میکنید نیازمندی هایتان را با نصب ماژول ها برطرف کنید. بعد از مدت کوتاهی می بینید که سایت تان کند شده است، با صفحه ی سفید (کاملا خالی) روبرو می شوید، خطا های عجیب غریب در سایت تان می بینید و نمی دانید کجای مسیرتان را اشتباه آمده اید.
این مقاله برای شماست. در این مقاله قصد دارم کمی در مورد دروپال توضیح دهم و مسیر را برای شما روشن کنم. تا شناخت بهتری نسبت به دروپال و نیازمندی های آن ییدا کنید و سایت تان را دوباره احیا کنید.

بنا بر تعریف، دروپال، قادر به اجرا بر روی تقریبا هر پلاتفرمی هست. بر روی تمام سیستم عامل ها، اعم از ویندوز، لینوکس، سولاریس، bsd، اندروید، و خانواده ی Unix و هر جایی که php بتواند اجرا شود و افزونه های مورد نیاز دروپال قادر به اجرا باشند، و هر جا که MySQL یا Postgresql یا یک دیتابیس سازگار دیگر قابل اجرا باشد، دروپال نیز می تواند کار کند.

بنا بر جمله ی فوق، دروپال یک سیستم بسیار قابل حمل می باشد. این جمله نشان می دهد که شما دروپال را تقریبا در هر محیطی می توانید استفاده کنید. اما کدام محیط بهینه تر و بهتر است؟ مسئله اینجاست.

من سابقا مجموعه مقالاتی رو در مورد کارایی دروپال و افزایش سرعت آن نوشته بودم. برای این که تکرار مکررات نشود، لطفا به مقالات زیر هم سری بزنید:

در ادامه نیازمندی های دروپال را شرح میدهم و توضیح میدهم که پارامتر های مهم برای اجرای بهینه ی دروپال چیست و راه حل هایی را نیز معرفی خواهم کرد.
و آخر بحث هم سرویس بی نظیر Drupalhost.ir (میزبان دروپال هاست) را معرفی خواهم کرد. و شرح خواهم داد که چگونه دروپال هاست، تمامی استاندارد ها و نیازمندی های دروپال را به بهترین شیوه رعایت کرده است.

نصب Drush به شیوه ی جدید

مدتی است که نصب دراش از طریق کانال های PEAR منسوخ شده است و روش نصب دراش به صورت مدرن، با استفاده از نرم افزار composer می باشد.

اگر سعی کرده باشید Drush را در سرور با composer نصب کنید، احتمالا متوجه شده اید که اگر طبق روشی که در سایت رسمی آن شرح داده شده پیش بروید، دراش برای همه ی کاربران نصب نمی شود.

برای حل این مشکل، راه حلی وجود دارد. که در زیر شرح می دهم.

مرحله ی اول این است که composer رو به طور global نصب کنید:

یک پیکربندی دیگر برای امنیت دروپال

Drupal security

یک پیکربندی مناسب دیگر برای میزبانی اشتراکی سایت ها، توسط php و apache به این صورت می باشد که پروسه ی apache تحت کاربر و گروه www-data:www-data اجرا می شود. و برای هر وب سایت نیز یک کاربر و گروه در لینوکس ایجاد می کنیم.

مثلا برای سایت test1.com کاربر و گروه test1:test1 و برای سایت test2.com، کاربر و گروه test2:test2 را ایجاد می کنیم.

نکات امنیتی دروپال در لینوکس

Drupal security

برای میزبانی دروپال در هاست های اشتراکی، برخی دغدغه های امنیتی وجود دارد. که من در این جا برخی از آن ها را مطرح می کنم. این مطلب برای مدیران سرور مفید خواهد بود.
سیستم عامل مورد شرح در این مطلب، لینوکس Debian 6 squeeze می باشد و دروپال مورد استفاده نسخه ی 7.25 می باشد. گرچه سایر نسخه ها و توزیع های لینوکس و دروپال نیز، مشابه خواهند بود.

مجوز فایل های اصلی دروپال

یک کانفیگ بسیار مناسب و متداول برای میزبانی اپلیکیشن های PHP به این صورت است که از وب سرور apache2 همراه با ماژول fastcgi و سرویس php-fpm استفاده می شود.
برای شرح بیشتر راجع به این نوع کانفیگ، به لینک زیر مراجعه کنید. دقت کنید که ادامه ی مطلب دقیقا بر اساس لینک زیر نمی باشد. لینک زیر فقط برای راه اندازی یک حالت خاص از کانفیگی که نام بردم می باشد:
Install Drupal in php-fpm (fastcgi) with Apache and a chroot php-fpm

نکته:برای شرح بیشتر در خصوص مجوز ها در لینوکس، این لینک را مطالعه کنید

در این پیکربندی، ما برای میزبانی هر سایت، یک کاربر جدید در لینوکس ایجاد می کنیم و در php-fpm یک pool جدید ایجاد می کنیم و تنظیم می کنیم که php-fpm برای هر سایت، با سطح دسترسی و هویت کاربر صاحب سایت اجرا شود.
فایده ی این کار این است که اگر چندین سایت مختلف داشته باشیم، هر سایت با مجوز های صاحب همان سایت اجرا می شود و اگر نفوذگر بتواند به یکی از سایت ها نفوذ کند، به سایر سایت ها دسترسی نخواهد داشت.

اما روال اجرای کار به این سادگی هم نیست. چند تا نکته را باید مد نظر قرار داد:

اولا وب سرور apache معمولا تحت کاربر www-data و گروه www-data اجرا می شود و وب سرور باید بتواند به فایل های دروپال (دست کم، پوشه ی اصلی سایت و پوشه ی files) دسترسی داشته باشد.
ثانیا، باید طوری تنظیم کنیم که سایر کاربرها، به جز www-data به فایل ها دسترسی نداشته باشند.

برای رسیدن به هدف اول، کافی است که group owner فایل های دروپال را به www-data تغییر دهیم.

chmod 711 /home/siteuser
chown siteuser:www-data -R /home/siteuser/public_html
chmod 750 /home/siteuser/public_html

اکنون که group owner فایل های دروپال با www-data تنظیم شده، باید مجوز فایل ها را طوری تنظیم کنیم که فقط php و apache به آن ها دسترسی داشته باشند. برای این منظور، مجوز پوشه ها را برابر 750 و مجوز فایل ها را برابر 640 در نظر می گیریم:

cd /home/siteuser/public_html
find -type d -exec chmod 750 {} \;
find -type f -exec chmod 640 {} \;

مجوز فایل های خاص

همچنین باید مجوز پوشه ی اصلی سایت و فایل settings.php را تنظیم کنیم. (البته این کار توسط دروپال هم انجام می شود.)

chmod 550 sites/default
chmod 440 sites/default/settings.php

مجوز فایل های جدید

اکنون مشکل در گام اول برطرف شده است، اما در گام بعدی، متوجه می شویم که فایل های جدیدی که توسط دروپال ایجاد می شود، مجوزهایشان صحیح نیست.
دو نوع فایل توسط دروپال قابل ایجاد است. یکی فایل هایی که مستقیما توسط php ایجاد شود. و دیگری فایل هایی که کاربر در سایت آپلود می کند.

تفاوت این دو دسته فایل در این است که در حالت اول، صرفا فایل ایجاد می شود، اما در حالت دوم، فایل پس از ایجاد، توسط تابع drupal_chmod مجوز دهی می شود. عمده ی تمرکز ما روی حالت دوم است. زیرا حالت اول معمولا رخ نمی دهد.

برای تغییر مجوز فایل های ایجاد شده توسط PHP باید از دستور umask استفاده کنیم. با توجه به این که می خواهیم کاربر other به فایل ها هیچ دسترسی نداشته باشد، umask قابل استفاده 0027 می باشد. ساده ترین راه برای انچام این تنظیم، این است که خط زیر را به ابتدای فایل index.php دروپال اضافه کنیم. (ظاهرا می توان آن را به فایل settings.php هم اضافه کرد که در این صورت بهتر خواهد بود.)

umask(0027);

به این ترتیب، پوشه هایی که توسط php ایجاد می شوند، با مجوز 750 و فایل ها با مجوز 640 ایجاد خواهند شد که مطلوب ماست.

نکته ی دیگر این است که فایل هایی که توسط کاربر آپلود می شوند (مانند فایل های ضمیمه ی ارسال شده در node ها) به طور خودکار توسط دروپال مجوز 644 و پوشه ها مجوز 755 می گیرند و این مطلوب ما نیست.

خوشبختانه دروپال گزینه ای برای تنظیم این موضوع دارد. یک variable موجود است به نام file_chmod_directory که مجوز پوشه های جدید را مشخص می کند و variable دیگری به نام file_chmod_file وجود داره که مجوز فایل های جدید را مشخص می کند. می توان این دو variable را به کمک تابع variable_set تنظیم کرد. اما روش ساده تر و ایمن تر این است که دو تا خط زیر را به انتهای فایل settings.php دروپال اضافه کنیم.

دو خط زیر سبب می شود که variable های فوق override شوند و از مقادیر مشخص شده در فایل settings.php استفاده شود:

$conf['file_chmod_directory'] = octdec('0750');
$conf['file_chmod_file'] = octdec('0640');

سپس فایل settings.php را ذخیره می کنیم (دقت کنید که این فایل read only است و باید در موقع ذخیره کردن با برنامه ی vim، از ! استفاده کرد.)

صاحب فایل های آپلود شده و ایجاد شده ی جدید

آخرین موضوع برای حل کردن این است که وقتی یک فایل جدید در دروپال آپلود می شود، از آن جایی که فایل توسط php ذخیره می شود که owner سایت ذخیره می شود. در حالی که ما می خواهیم group owner آن www-data باشد. چون در غیر این صورت در فایل توسط apache قابل serve شدن نخواهد بود و بارز ترین و سریع ترین واکنشی که مشاهده می کنیم این است که دروپال بدون استایل لود می شود و کلیه ی صفحات سایت بدون هیچ شکل و شمایلی نشان داده می شوند و یا کد های javascript اجرا نمی شود.

اگر در این حالت firebug را باز کنیم، می بینیم که علت بروز این مشکل، خطای 403 در هنگام لود شدن استایل ها و فایل های جاوااسکریپ می باشد.

مروری بر روش های بهینه سازی دروپال برای سرعت بیشتر (قسمت چهارم)

این مقاله، دنباله ی مقاله ی قبلی است. برای مطالعه ی قسمت پیشین آن، لطفا به لینک های زیر مطلب مراجعه کنید
بهینه سازی فایل های JavaScript و css و تصاویر
10 - یکی از اصلی ترین دلایل کندی بارگذاری یک سایت ناشی از حجم بالای صفحات آن می باشد. هرچه حجم صفحات را کاهش دهید، سرعت بارگذاری بیشتر، رنکینگ بهتر و بازدیدگنندگان بیشتری را بدست می آورید.

مروری بر روش های بهینه سازی دروپال برای سرعت بیشتر (قسمت سوم)

این مقاله، دنباله ی مقاله ی قبلی است. برای مطالعه ی قسمت پیشین آن، لطفا به لینک های زیر مطلب مراجعه کنید
تغییر پایگاه داده ی سایت به یک سیستم سریع تر
8 - پایگاه داده ی پیش فرض دروپال MySQL می باشد که پایگاه داده ی بسیار قدرتمندی می باشد. اما در برخی موارد بهترین گزینه نیست. در برخی موارد هم راه حل های سریع تری موجود می باشد:

مروری بر روش های بهینه سازی دروپال برای سرعت بیشتر (قسمت دوم)

این مقاله، دنباله ی مقاله ی قبلی است. برای مطالعه ی قسمت پیشین آن، لطفا به لینک های زیر مطلب مراجعه کنید
ESI ‎(‎Edge Side Includes‎)‎
4 - ESI و یا Edge side includes یک راه حل پیشرفته برای کشینگ صفحات سایت برای کاربرانی که در سایت لاگین هستند می باشد. ماژول آن در این صفحه موجود می باشد:
http://drupal.org/project/esi
راه اندازی و استفاده از این راه حل مستلزم تغییرات زیادی در ساختار سایت می باشد و یک کار فنی می باشد.
کشینگ درون ساخت دروپال

مروری بر روش های بهینه سازی دروپال برای سرعت بیشتر (قسمت اول)

در این مقاله به برخی از راه حل هایی که منجر به افزایش سرعت یک سایت دروپالی می شود می پردازیم.

من تقریبا اکثر راه حل هایی که منجر به افزایش سرعت دروپال می شوند را آزمایش کرده ام. و بهترین کار برای شما هم احتمالا این است که روش های مختلف را آزمایش کنید و روش مناسب را برای خودتان پیدا کنید.

ماژول htmlmail و خراب کردن فیلد ارسال کننده ی ایمیل

ماژول htmlmail یکی از ماژول های دروپال است که کمک می کند ایمیل های ارسال شده توسط دروپال، استایل دهی شوند.

به این ترتیب که شما می توانید یک فایل قالب (.tpl.php) ایجاد کنید و ایمیل های ارسالی توسط دروپال (به تفکیک نوع ایمیل) توسط این فایل template قالب دهی شوند.

ماژول htmlmail به ماژول mailsystem به عنوان پیش نیاز، احتیاج دارد.

متاسفانه یک مشکلی که این ماژول ایجاد می کند، این است که آدرس ارسال کننده ی ایمیل را دستکاری می کند و آن را خراب می کند.

صفحه‌ها

اشتراک در RSS - دروپال