استفاده از cache یا برگردوندن همه ی دیتای دریافتی

[n0o0b_sina]

سلام
دوستان با بررسی هایی که توی هسته ی وردپرس انجام دادم دیدم وردپرس هنگام بارگزاری اطلاعات پست ها متا تگ های اونها رو به جای اینکه همراه با پست توی آرایه برگردونه توی کلاس cache و متغیر خصوصی cache ذخیره میکنه! و موقعی که میخوایم با تابع get_post_meta مقدار اون پست متا رو بدست بیاریم از اون مقدار cache شده میخونه، و اگه مقدار ثبت نشده باشه query میزنه، چرا؟!
یعنی با برگردوندن همه ی اطلاعات مثلا همه ی متا تگ های اون پست با نتایج query سیستم سنگین تر میشه که این اینجوری عمل کرده؟!
پیشنهاد شما چیه؟ مام مثله وردپرس عمل کنیم یا با یه join توی query همرو با هم برگردونیم؟! چیزای ثابتی مثله دسته بندی ها برچسب ها و متا تگ های هر پست رو برگردونیم و اگه نیازی شد توی loop راحت استفاده کنیم تنها با 1 query
-----
و یه سوال دیگ، چطوری میشه query هایی که به mysql فرستاده میشن رو log کرد؟ حالا چه توی سیستم خودمون چه وردپرس

[MMSHFE]

سرعت خوندن اطلاعات از فایل سریعتر از دیتابیسه. وقتی بخشهایی از صفحه تغییر زیادی ندارن، میتونین توی کش (فایلهای خام) ذخیره کنید و از اونجا بخونین و اگه فایل نبود، از دیتابیس بخونین و توی فایل ذخیره کنین. هروقت هم توی دیتابیس تغییری ایجاد شد، فایل کش اون قسمت رو حذف کنید تا در اولین درخواست بعدی، دوباره ساخته بشه. کوئریهای زیاد به دیتابیس خیلی هم بد نیست ولی بستگی به نوع کوئری و میزان درخواستش داره. ضمناً Join رو اگه درست استفاده نکنید، قاتل Performance محسوب میشه.

درمورد Log کردن هم یک راه مناسب، تغییر متدی هست که کوئری رو میفرسته تا همون کوئری رو توی فایل لاگ ذخیره کنه. درمورد Logging mysql queries in php جستجو کنید.

[n0o0b_sina]

سرعت خوندن اطلاعات از فایل سریعتر از دیتابیسه. وقتی بخشهایی از صفحه تغییر زیادی ندارن، میتونین توی کش (فایلهای خام) ذخیره کنید و از اونجا بخونین و اگه فایل نبود، از دیتابیس بخونین و توی فایل ذخیره کنین. هروقت هم توی دیتابیس تغییری ایجاد شد، فایل کش اون قسمت رو حذف کنید تا در اولین درخواست بعدی، دوباره ساخته بشه. کوئریهای زیاد به دیتابیس خیلی هم بد نیست ولی بستگی به نوع کوئری و میزان درخواستش داره. ضمناً Join رو اگه درست استفاده نکنید، قاتل Performance محسوب میشه.

درمورد Log کردن هم یک راه مناسب، تغییر متدی هست که کوئری رو میفرسته تا همون کوئری رو توی فایل لاگ ذخیره کنه. درمورد Logging mysql queries in php جستجو کنید.
یعنی استفاده از join اینقدر بده که وردپرس 10 دور توی سیستم میچرخه واسه یه متا تگ؟ :دی
البته وردپرسم از join استفاده کرده ولی نتایج join رو کش میکنه و بر نمیگردونه و فقط نتایج پست اصلی رو بر میگردونه
من وردپرس رو خیلی بررسی کردم کلا از 14 مگی که وردپرس هست 10 مگش اضافست!!! شاید دقت کرده باشید هنگام آپلود تصاویر هم اونها رو توی 4 تا سایز ذخیره میکنه! با اینکه با کد php راحت میتونه تصویر رو کوچیک کنه!

[MMSHFE]

وردپرس خیلی خوب نوشته شده (البته نه کاملاً اصولی) ولی یکسری چیزهاش خیلی خوبه. برای مثال همینکه از کش تا جایی که میشه استفاده میکنه که به دیتابیس فشار نیاد و مدام توی بازدیدهای بالا (که از خاصیت وبلاگهاست) با خطای max_connection توی MySQL مواجه نشین، خیلی خوبه. وقتی میشه اطلاعات رو کش کرد و تا وقتی تغییر نکرده، دیگه به دیتابیس مراجعه نکنیم، خوب چرا اینکار رو انجام ندیم؟ درمورد بد بودن Join (تأکید میکنم - اگه به شکل بهینه و مناسب ازش استفاده نکنید - شک نداشته باشین).

مورد بعدی همون آپلود تصاویر در چند سایزه که باز هم خوب کار شده چون تولید تصویر با PHP (اونهم فقط برای مقاصدی مثل تغییر سایز)، علاوه بر افزایش حجم تصویر نسبت به تصویر اولیه (که با نرم افزارهای ذخیره سازی تصویر میشه خیلی خوب فشرده اش کرد)، سربار زیادی هم روی پردازنده داره. بعلاوه کلاینت باید منتظر بمونه توی هر بازدید که تصویر جدید ساخته بشه و بعد مرورگر دانلودش کنه درحالی که اگه آدرس عکس مستقیم بود، چنین کارهایی لازم نبود و میشد صفحه باز بشه و محتوا رو ببینه و کم کم تصاویر دانلود بشن. این مورد بیشتر در زمانهایی خودش رو نشون میده که شما تصویر رو مستقیماً با PHP میسازین (بصورت base64 توی src استفاده میکنید).

[n0o0b_sina]

وردپرس خیلی خوب نوشته شده (البته نه کاملاً اصولی) ولی یکسری چیزهاش خیلی خوبه. برای مثال همینکه از کش تا جایی که میشه استفاده میکنه که به دیتابیس فشار نیاد و مدام توی بازدیدهای بالا (که از خاصیت وبلاگهاست) با خطای max_connection توی MySQL مواجه نشین، خیلی خوبه. وقتی میشه اطلاعات رو کش کرد و تا وقتی تغییر نکرده، دیگه به دیتابیس مراجعه نکنیم، خوب چرا اینکار رو انجام ندیم؟ درمورد بد بودن Join (تأکید میکنم - اگه به شکل بهینه و مناسب ازش استفاده نکنید - شک نداشته باشین).

مورد بعدی همون آپلود تصاویر در چند سایزه که باز هم خوب کار شده چون تولید تصویر با PHP (اونهم فقط برای مقاصدی مثل تغییر سایز)، علاوه بر افزایش حجم تصویر نسبت به تصویر اولیه (که با نرم افزارهای ذخیره سازی تصویر میشه خیلی خوب فشرده اش کرد)، سربار زیادی هم روی پردازنده داره. بعلاوه کلاینت باید منتظر بمونه توی هر بازدید که تصویر جدید ساخته بشه و بعد مرورگر دانلودش کنه درحالی که اگه آدرس عکس مستقیم بود، چنین کارهایی لازم نبود و میشد صفحه باز بشه و محتوا رو ببینه و کم کم تصاویر دانلود بشن. این مورد بیشتر در زمانهایی خودش رو نشون میده که شما تصویر رو مستقیماً با PHP میسازین (بصورت base64 توی src استفاده میکنید).
من متوجه نشدم چطوری از join استفاده کنیم که اصولی باشه؟
این الان چقدر اصولیه؟


SELECT{$posts_tn}.*,
{$users_tn}.username AS author_username,
{$users_tn}.display_name AS author_display_name,
{$users_tn}.email AS author_email,
{$taxonomy_r_tn}.taxonomy_id AS taxonomy_id,
{$taxonomies_tn}.name AS taxonomy_name,
{$taxonomies_tn}.slug AS taxonomy_slug,
{$taxonomies_tn}.type AS taxonomy_type,
{$taxonomies_tn}.parent AS taxonomy_parent,
{$meta_tn}.key AS meta_key,
{$meta_tn}.value AS meta_value,
(SELECT COUNT(*) FROM {$comments_tn} WHERE {$comments_tn}.post_id = {$posts_tn}.id) as comment_count
FROM {$posts_tn}
LEFT JOIN {$users_tn} ON {$users_tn}.id = {$posts_tn}.author
LEFT JOIN {$taxonomy_r_tn} ON {$taxonomy_r_tn}.object_id = {$posts_tn}.id
LEFT JOIN {$taxonomies_tn} ON {$taxonomies_tn}.id = {$taxonomy_r_tn}.taxonomy_id
LEFT JOIN {$meta_tn} ON {$meta_tn}.object_id = {$posts_tn}.id AND {$meta_tn}.type = 'posts'
WHERE {$posts_tn}.type = 'posts'
خب شاید اینطور باشه و یکم توی زمان لود تصویر فرق کنه ولی توی حجم نه چون توی چند تا از پروژها به عینه تست کردم! خب وردپرس به جای اینکه توی هر بار آپلود عکس 4 تا از اون بسازه هنگامی که کاربر میخواد سایز تصویر رو تغییر بده این کارو بکنه!
یعنی رسایز عکس با php اینقدر فشار وارد میکنه به سرور؟!

[MMSHFE]

شما یکبار عکسهاتون رو با Advanced JPEG Compressor فشرده کنید تا متوجه تفاوتها بشین. برای اینکه کیفیت کم نشه هم پروفایل Screenshot رو توی برنامه انتخاب کنید. اونوقت میبینید که در بدترین حالت، حجم تصویر فشرده شده نصف حجم تصویری هست که به روش On the fly تولید میکنید. اون 4 تصویری هم که وردپرس میسازه هرکدوم برای بخشهای مختلفی از سایت استفاده میشه.

[MMSHFE]

من متوجه نشدم چطوری از join استفاده کنیم که اصولی باشه؟

خیلی جاها هست که میشه بجای Join از کوئریهای متوالی استفاده کرد. خیلی جاها نوع ایندکس فیلدی که برای Join استفاده میشه و پارامتر Cardinality اون میتونه روی سرعت کار Join اثر بگذاره. اینکه از Left Join استفاده بشه یا Right Join، اینکه شرطهای قسمت Where رو چطوری بنویسیم که همون اول تعداد زیادی از رکوردها حذف بشن، اینکه چه فیلدهایی رو توی SELECT استخراج کنیم، اینکه چقدر از فیلدهای ایندکس توی شرطهامون استفاده میکنیم، اینکه جدول براساس چی داره مرتب میشه، انجین مورد استفاده و... همگی بخشهایی از اصولی هستن که توی میزان بهینگی کوئری تأثیر دارن.