با توجه به آمار انجمن vBulletin آیا واقعا تعداد کوئری گیری مسئله مهمی هست؟

[idocsidocs]

قبلا چند تاپک در مورد سرعت اجرای سایت برنامه نویس ایجاد شده بود.

با این حجم بازدید و تعداد زیاد اطلاعاتی که توی صفحات انجمن نمایش داده می شه برای خودم هم این موضوع جالب بود که چطور سایت هایی که با vBulletin ایجاد شدن با سرعت و بدون اشکال اجرا می شن.

تااینکه توی انجمن http://forum.persiannetworks.com و در انتهای صفحه http://forum.persiannetworks.com/f113.html اطلاعات زیر رو دیدم:
Page generated in 0.2048 seconds with 16 queries

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

بعد از دادن این خبر، چند سوال دارم:

1- وقتی vBulletin کوئری ها رو کش نکرده، بنظرتون بهتر نیست که ما هم از vBulletin تقلید کنیم و کوئری ها رو کش نکنیم؟

2- آیا با فقط با ایندکس کردن فیلدها می تونیم به چنین سرعتی دست پیدا بکنیم؟

3- آیا سرعت vBulletin به سخت افزار اجرا کننده هم مربوط می شه؟

[eshpilen]

یحتمل تازه با کش کردن اون تعداد شده.
البته یوقت هم ممکنه بخاطر بیش از حد شدن پیچیدگی با پیاده سازی یک سیستم کش برای اینطور نرم افزارهای حجیم و پیچیده، ازش تاحدودی صرفنظر کرده باشن (حداقل یه جاهایی).

[idocsidocs]

البته یوقت هم ممکنه بخاطر بیش از حد شدن پیچیدگی با پیاده سازی یک سیستم کش برای اینطور نرم افزارهای حجیم و پیچیده، ازش تاحدودی صرفنظر کرده باشن (حداقل یه جاهایی). به هرحال 16 کوئری برای یه همچین انجمنی باید زیاد باشه ولی همونطور که می بینید این انجمن ساز توی بازدیدهای بالا هم بدون مشکل اجرا می شه.

با توجه به این مسائل می تونیم نتیجه بگیریم که توی سایتهای عادی هم بدون نگرانی در مورد کاهش سرعت، می شه تعداد زیادی (حداکثر 16 تا) کوئری ایجاد کرد ؟

[djsaeedkhan]

سلام
همین سایتی که معرفی کردید ،در صفحه اول انجمن عبارت 42 کوری اجرا شد رو نوشت.
حالا شما حساب کنید سایتی مثل فیش بوک (کتاب فیش حقوقی:چشمک:) که با php هم نوشته شدن و روزانه یا ماهانه از چند هزار تا چندمیلیون کوری اجرا میشن چی میشه گفت (42 تا که هیچی)
پس ربط به یه چیز دیگه داره
قرار نیست برای هر درج یا دریافت یه کوری دریافت یا ارسال بشه. چون ممکنه در همون لحظه که داره ثبت میشه یه کوری بخواد دریافت کنه و ...

در کل منظورم این بود که حتما روش هایی هست که اگر 100 تا کوری هم در یک صفحه اجرا کردیم نتیجش این نباشه که کاربر یه ربع صبر کنه (و عطاش رو به لغاش ببخشه)

[idocsidocs]

در کل منظورم این بود که حتما روش هایی هست که اگر 100 تا کوری هم در یک صفحه اجرا کردیم نتیجش این نباشه که کاربر یه ربع صبر کنه (و عطاش رو به لغاش ببخشه) چه روشی؟ اگر بدونیم که خیلی خوب می شه.

[eshpilen]

حتما سرورشون هم قوی هست دیگه.

[idocsidocs]

حتما سرورشون هم قوی هست دیگه.

بغیر از سرور قو چه فاکتورهای دیگه ای وجود داره؟

[eshpilen]

بنظر من تازه نرم افزارها و سایتهایی که خیلی افراد طراحی میکنن از نظر منطق/الگوریتم بی نقص و محکم، و امنیت، دچار نقص و ضعف هستن.
اگر یه سیستم کامل و اصولی و امن و دقیق طراحی بشه، حجم کد بیشتر خواهد بود، پیچیدگیش بیشتر خواهد بود، تعداد کوئری ها بیشتر خواهد بود، پردازش و مصرف منابع بیشتر خواهد بود، پرفورمنس کمتر خواهد بود، ... .
ولی اکثر افراد اینقدر که روی پرفورمنس وسواس دارن از چیزهای دیگه اصلا انگار اطلاع ندارن.
ضمنا روی پرفورمنس هم جاهایی وسواس دارن که اصلا در عمل چیز مشهودی دیده نمیشه و این بیشتر تخیلات خودشونه.
امروزه روز بخاطر چند میلی ثانیه نباید وقت و انرژی رو هدر داد و کد رو ناخوانا و پیچیده کرد. به اندازهء کافی پیچیدگی و ناخوانایی هست.
البته طبیعتا یه جاهایی و برای کارهای خاصی و کارهای بزرگ، مشکل پرفورمنس پیش میاد. اونجاها خب میایم روی بهینه سازی در اون مواردی که واقعا تاثیر بزرگی دارن کار میکنم. اما نباید انتظار داشته باشیم که هرکاری رو بشه با هر سرور و منابعی انجام داد. خیلی وقتا این کار غیرممکنه، و خیلی وقتا هم عاقلانه نیست و صرف نمیکنه چون برنامه رو باید بصورت خیلی گسترده و پیچیده ای بهینه سازی کرد تا روی یک سرور ضعف بتونه کار کنه که وقت و انرژی زیادی میخواد و از طرف دیگه برنامه ناخواناتر و پیچیده تر میشه و احتمال باگ و مشکل امنیتی توش خیلی بالاتر میره. یحتمل خیلی جاها از بعضی بهینه سازی هایی هم که میتونن انجام بدن بخاطر مشکل پیچیدگی میگذرن (گاهی بصورت موقت)، چون واقعا یه برنامهء بزرگ حرفه ای کامل همینطوریش اونقدری حجم و پیچیدگی داره که خوانایی و توان مدیریت و تست و تحلیل اون خیلی زیاد اهمیت داره و بهینه سازی اغلب وضع این پارامترها رو بدتر میکنه.

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

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