بررسی سیستم های پرتردد با ترافیک بسیار بالا با رکوردهای بسیار زیاد

[intel_amd]

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

اولین مورد که مورد بحث است اینه که ایجاد حلقه بر روی یک کوئری برای گرفتن کوئری های مختلف بسته به الگوریتم تا چه حد مضر و پائین آورنده پرفورمنس می باشد , آیا شما تا به حال شده از حلقه هائی با شمارنده 200 تا مثلا بر روی یک کوئری استفاده نمائید؟

مورد دوم اینکه یک سرور واقعی با linux تا چه حد از یک سیستم ساده core 2 duo با ویندوز و wamp قوی تر است و آیا سیستمی که طراحی شده مثلا اگر بر روی این سخت افزار و نرم افزار به صورت تک کاربره در برخی پردازش ها mysql پردازنده این سخت افزار را تا 50% بالا می برد در یک سرور واقعی با حضور کاربران چند صد هزار نفری و رکوردهای بالا و انجام پردازش های گوناگون توسط یوزر ها سیستم به خوبی عمل میکند؟(البته نکته قابل ذکر اینه که با اینکه سیستم تک کاربره بررسی شده اما رکوردهای زیادی برای مثال در جداول قرار داده ایم فقط تفاوتش با اجرای واقعی اینه که کاربران چند صد هزاری وجود ندارند که حجوم بیاورند و همین پردازش ها را دسته دسته به سمت سرور روانه نمایند)
نکته دیگر قابل ذکر اینه که الان با این سیستم اجرای یک کوئری بسیار ساده در نرم افزار navicat mysql از یک جدول با 10 رکورد هم 10% cpu میگیرد

مورد بعدی اینه که تجربه های ارزنده ای که در کار با سیستم های سنگین کسب کرده اید چنتا مهماشو بفرمائید

[Weblove]

سلام،

نظرم شاید زیاد کارشناسانه نباشه اما می نویسم شاید کمکی بشه
همیشه سروری هست که سایت شما رو پشتیبانی کنه، اما هر چه بهینه تر بنویسید دیر تر نیاز به سرور قوی تر پیدا می کنید
200 کوئری هر چی هم ساده باشه حتی دریافت 1 فیلد زیاده ، هر چند که ممکنه الگوریتم شما بطلبه که این کار رو بکنید ،... اما باید تلاش کنید بهینه تر بنویسه، کوتاه ترین راه رو برای رسید به کوئری نهایی استفاده کنید
مقایسه CPU usage سیستم شما با CPU usage سرور درست نیست،... ( سیستم عامل و امکانات نرم افزاری سرور بسیار میتونه تاثیر گذار باشه )

[intel_amd]

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

[joker]

میزان مصرف یک پروسه برای یک کاربر را بدست بیارید * تعداد ارتباط همزمانی که به صورت نرمال پیش بینی میکنید بکنید
از نظر تئوری محدودیتی نیست ولی در عمل سخت افزارها محدودیت I/O را بلاخره دارند
من تاحالا ندیدم یک سرور به تنهایی چند صد هزار کاربر را در آن واحد بتونه پشتیبانی کنه ، حتی 1 صد هزار چه برسه به چند صد هزار.
برای این کار باید با روشهای کلاستر کردن بار را بین چند سرور پخش کرد. راهی غیر از این نیست برای این تعدادی که مثال زدید.

[rezaonline.net]

اولین مورد که مورد بحث است اینه که ایجاد حلقه بر روی یک کوئری برای گرفتن کوئری های مختلف بسته به الگوریتم تا چه حد مضر و پائین آورنده پرفورمنس می باشد , آیا شما تا به حال شده از حلقه هائی با شمارنده 200 تا مثلا بر روی یک کوئری استفاده نمائید؟
من به ده کوئری در یک پروسس میگم زیاد اونوقت شما 200 تا رو اجرا میکنید :)
اصلا من جایی ندیدم لازم باشه انقدر کوئری اجرا کرد !!!!
یه جای کار مشکل داره سعی کنید بازنگری کنید برروی برنامه تون


مورد دوم اینکه یک سرور واقعی با linux تا چه حد از یک سیستم ساده core 2 duo با ویندوز و wamp قوی تر است
همه چیز به کانفیگ سرور بستگی داره ، ممکنه روی ویندوز بهتر عمل کنه از لینوکس اینا تجربه است

آیا سیستمی که طراحی شده مثلا اگر بر روی این سخت افزار و نرم افزار به صورت تک کاربره در برخی پردازش ها mysql پردازنده این سخت افزار را تا 50% بالا می برد
مانیتور کردن مصرف سی پی یو رو به چه شکلی انجام میدید ؟
در کل رابطه مستقیمی بین مدت زمان اجرای پروسه و مصرف سی پی یو وجود داره .


در یک سرور واقعی با حضور کاربران چند صد هزار نفری و رکوردهای بالا و انجام پردازش های گوناگون توسط یوزر ها سیستم به خوبی عمل میکند؟(البته نکته قابل ذکر اینه که با اینکه سیستم تک کاربره بررسی شده اما رکوردهای زیادی برای مثال در جداول قرار داده ایم فقط تفاوتش با اجرای واقعی اینه که کاربران چند صد هزاری وجود ندارند که حجوم بیاورند و همین پردازش ها را دسته دسته به سمت سرور روانه نمایند)
من الان دارم با 6 میلیون رکورد توی یک جدول دست و پنجه نرم میکنم :)
سوال شما خیلی کلی هست همه چیز بستگی به برنامه تون داره

[intel_amd]

از همه دوستان تشکر میکنم اطلاعات مفیدی دادید


تعداد یوزرها حدود 20,000 یوزر هست اونو دست بالا گفتم که نسبت به گفته ها اوضاع دستم بیاد


اکثر پردازش های سیستمی که طراحی کردم بین 3-4 تا کوئری در هر پردازش خلاصه میشه فقط برخیشون به 10-12 تا میرسه که زیاد این پردازش ها از سمت کاربرها استفاده نمیشه فقط یکی از پردازش هام تقریبا 120 تا کوئری هر 1 ثانیه 1 بار تا زمانی که کاربر دستور توقف ندهد اجرا میکنه که این پردازش زیاد هم از سمت کاربرها استارت میشه !
این طور که مشخص شد تعداد متعارف کوئری در یک پردازش حدود 10 تاست که این پردازش با 120 کوئری با الگوریتم جدیدی که دارم روش کار میکنم باید به 1 کوئری در ثانیه تا پایان توقف از سمت کاربر برسونمش


مانیتور کردن را توسط task manager انجام میدم , داخل پروسس ها mysql.exe هست که وقتی کوئری اجرا میشه cpu میگیره , همچنین بالاترش httpd هست که آپاچی سروره + مانیتورینگ برنامه navicat

[plague]

اصول کلی بهینه سازی رو باید رعایت کنی که دیگه همه میدونن
ایندکس گزاری مناسب و اصولی
نرمال سازی - محدود نگه داشتن تعدا ستون ها در تیبل ها
دوری کردن از جستجو بر اساس رشته و انجام عملیاتی مانند like
استفاده از تریگر ها و حذف آبشاری
و ...............................


مطمئنا کوئری که زمان بیش از زمان نرمال طول بکشه مشکل داره و با بالا رفتن تعداد کاربر ها و سنگین شدن د یتبایس 100% باعث مصرف بیش از حد منابع و در نهایت داون شدن سرور میشه ... همچنین نکته دیگری که باید توجه بهش داشته باشی تعداد کانکش هاست که تا جای ممکن باید پایین نگه داشته بشه .... به همین دلیل شما نمیتونی تو حلقه 200 تایی کوئری بزاری ! چون فقط برای اون قسمت تعداد کانکش ها بیش از 4 برابر تعداد مناسب برای یک صفحه خواهد بود


شما باید با استفاده از راهکار های موجود که معمولا هر فریم ورکی دیگه داره پروسس های سایتت رو زیر نظر بگیری و تعداد و لیست کوئری ها و زمانی که هر کدوم مصرف کردن رو در بیاری در صفحات ( یا میتونی از xdebug استفاده کنی ) .... همچنین میتونی با فعال کردن Slow Query Log سرور رو موظف کنی که شناسایی کنه کوئری های سنگین رو.

بعد هم بهینه سازی کوئری و احتمالا مهندسی متفاوت که باعث بشه مشکل شما حل بشه


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

این مثال هایی که شما میزنید خیلی ویرانگر هستن !
من فکر میکنم شما سوال اشتباهی رو دارید میپرسید
مهندسی کد شما و ساختار دیتبایس شما اشتباه هستش و باید ابتدا اون رو درست کنید وگرنه هرچقدر م کوئری بهینه کنید و استاندارد ها رو رعایت کنید وقتی قرار باشه 120 تا کوئری هر کاربر در هر ثانیه اجرا کنه هیچ کمکی نخواهند کرد

[rezaonline.net]

من هم با نظر plague (http://barnamenevis.org/member.php?123420-plague) موافقم .
اصلا هیچ لزومی به 120 کوئری نیست حتما یه جای کار ایراد داره .
اگر توضیحات بیشتری در مورد پروژه تون بدید میشه راه حل بهتری داد

[intel_amd]

از توضیحات plague متشکرم
الان دارم روی همون 120 کوئری در ثانیه کار میکنم و دارم به روشی دیگه به 1 کوئری در ثانیه میرسونمش
مهندسی کدم خوبه اما دیتابیسم یکم جالب نیست که دارم روش کار میکنم به شرایط استاندارد برسونمش البته با همیاری شما دوستان عزیز طی تاپیک های آینده

[ali2k5]

موضوع خوبی هست :) روی این مسائل چندین سالی کار کردم و کلا از بهینه سازی خوشم میاد :دی
توی دنیای واقعی یک سایت داریم با این میزان مصرف دیتابیس:


Up for: 14d 1h 53m 47s (217M q [178.952 qps], 7M conn, TX: 681B, RX: 19B)



حدود 178 کوئری در ثانیه روی این سرور داره انجام میشه و لود سرور زیر یک هست

up 23 days, 15:00, 1 user, load average: 0.80, 0.89, 1.06



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

دومین نکته تعداد کاربر و تخمین رکورد های دیتابیس یک مبحث در طراحی دیتابیس هست و تعداد بازدید و تعداد درخواست در ثانیه به سرور مبحث کانفیگ و منابع سرور هست و نباید این دو مسئله را با هم قاطی کنید صرفا یک رابطه بین طراحی و میزان مصرف هست.

سومین نکته مقایسه سخت افزاری که روش برنامه نویسی میکنید با منابع سروری که هاست واقعی سایت هست باید با درنظر گرفتن محدودیت های هاست واقعی انجام بشه و دانستن این نکته ها لازمه که هاست واقعی میتونه یک vps با یک core cpu و ram 512مگ محدود باشه که به مراتب از سخت افزار خانگی شما ضعیفتر هست ، میتونه یک سرور اختصاصی با cpu مخصوص سرور و 32gb فرضا رم و هارد ssd باشه که سیستم خانگی شما درمقابلش اسباب بازی هست پس اصلا این مقایسه موضوعیتی بنظر من نداره ، شما این نکته را در نظر بگیرید اگر پروسه ای روی دستگاه خانگی شما با مصرف cpu زیاد اجرا میشه این پروسه وقتی بیاد روی دنیای واقعی و همزمان 10 بار بخواد اجرا بشه قطعا اون سرور رو به سمت هنگ کردن می بره ... اصل درست نوشتن کوئری ها است

چهارمین نکته طراحی درست جدول ها ، ایندکس گزاری صحیح ، نوشتن کوئری صحیح بر اساس ایندکس ها و شرط های درست نکته اصلی بهینه بودن مصرف دیتابیس هستند و برای فهمیدن مشکلات دیتابیس باید slow log فعال بشه و بعد از 24 ساعت فعالیت واقعی سرور با mysql sla انالیز مصرف و زمان کوئری ها گرفته بشه و بعد هرکوئری که بیشترین وضعیت حاد مصرف و زمان رو دارد با explain در sql بررسی بشه و با تغییر کوئری مشکلش حل بشه ...

پنجمین نکته کانفیگ mysql هست ، منابعی که به سرویس mysql روی یک سرور اختصاص پیاده میکنه تاثیر زیادی در سرعت عمل این سرویس دارد و باید بعد از حداقل 24 ساعت فعالیت واقعی این سرویس کانفیگ متناسب با مصرف سرور انجام بشود ، کانفیگ نشدن صحیح سرویس باعث کندی پاسخ گویی کوئری ها خواهد شد همیشه توی حل مشکل دیتابیس سایت های پرمصرف و بزرگ اول این همینجا شروع می کنند.

[intel_amd]

از اطلاعات خوبتون ممنون سعی میکنم روشون کار کنم و اینجا با تاپیک های جدید مرتبط موضوعاتو پیگیری کنم البته با همیاری شما دوستان

کلیه نظرات اینو ثابت کرد که 120 کوئری در ثانیه با یک کاربر برای 1 پردازش خیلی سنگینه و اگر بره روی سرور و حجوم بیاد روش شاید 1000 نفر بخاد این پردازش 120 کوئری در ثانیه رو بفرسته رو سرور که میشه 1000*120 کوئری در ثانیه که فکر کنم هر سروری داون شه پس 100% روی این کار میکنم و دارم برسیش میکنم که 120 کوئری در ثانیه این پردازشمو به 1 کوئری در ثانیه برسونم

این بحث مانیتورینگی که گفتین جالبه و اگر در مورد نحوه فعال سازی و برسیش بیشتر بگید ممنون میشم مثلا اینکه آیا میشه نموداری در طی زمانی خاص فعال کرد که بعد از کار مثلا 24 ساعت سرور بشه اون نمودارو دید و بررسی کرد؟ یا مثلا برای بخش های مختلف بشه نمودار گذاشت مثلا فعالیت mysql و http و socket و connect و ....

[plague]

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


البته من به اندازه شما چند سال روی بهینه سازی کار نکردم و مواردی هست که اینور و اونور بهشون برخوردم

ولی منطقی که من بهش رسیدم به من میگه که اینجوری نیست که تعداد کوئری ها مهم نباشه (حداقل توی mysql )

حتما میدونید که یه سری محدودیت ها در سرور اعمال میشه ... مثل زمان اجرای کد یا max_execution_time و ...

من به این محدودیت ها به چشم سیستم احساس درد در بدن انسان نگاه میکنم , همونجوری که میدونید وقتی بدن ما آسیبی میبینه ما احساس درد میکنیم این روش بدن ماست که به ما بفهمونه این کار مضره و نباید انجام بشه

در تنظیمات mysql گزینه max_connections قرار داره که تعداد کانکشن های مجاز رو مشخص میکنه و اگه از اون حد فرا تر بریم با اررور مواجه خواهیم شد

حالا جدا از اینکه خوده این اررور دلیل موجه ای هستش ! که از زیاد شدن کانکشن ها جلوگیری کنیم , حتی اگه این محدودیت رو بردارم مطمئنا کار اشتباهی خواهد بود و حتما دلیلی وجود داره که این محدودیت بر روی دیتبایس اعمال میشه که زیاد نیازی به فکر کردن نیست تا اون دلایل رو متوجه شد

[ali2k5]

البته من به اندازه شما چند سال روی بهینه سازی کار نکردم و مواردی هست که اینور و اونور بهشون برخوردم

ولی منطقی که من بهش رسیدم به من میگه که اینجوری نیست که تعداد کوئری ها مهم نباشه (حداقل توی mysql )

حتما میدونید که یه سری محدودیت ها در سرور اعمال میشه ... مثل زمان اجرای کد یا max_execution_time و ...

من به این محدودیت ها به چشم سیستم احساس درد در بدن انسان نگاه میکنم , همونجوری که میدونید وقتی بدن ما آسیبی میبینه ما احساس درد میکنیم این روش بدن ماست که به ما بفهمونه این کار مضره و نباید انجام بشه

در تنظیمات mysql گزینه max_connections قرار داره که تعداد کانکشن های مجاز رو مشخص میکنه و اگه از اون حد فرا تر بریم با اررور مواجه خواهیم شد

حالا جدا از اینکه خوده این اررور دلیل موجه ای هستش ! که از زیاد شدن کانکشن ها جلوگیری کنیم , حتی اگه این محدودیت رو بردارم مطمئنا کار اشتباهی خواهد بود و حتما دلیلی وجود داره که این محدودیت بر روی دیتبایس اعمال میشه که زیاد نیازی به فکر کردن نیست تا اون دلایل رو متوجه شد

در مورد تعداد کوئری کاملا با اطمینان خدمتتان عرض میکنم ، اگر دوست داشتید تجربه کنید
این کوئری را مشاهده بفرمائید

SELECT * FROM `com`


در همین جدول 6 میلیون رکورد هست با حجم جدول 3.4 گیگ



6,028,720
MyISAM
utf8_general_ci

3.4 GiB




خب حالا زمان اجرای این کوئری چقدر هست ؟

Showing rows 0 - 24 (6028725 total, Query took 0.0002 seconds.)


در یک سرور واقعی با ترافیک واقعی یک جدول با 6 میلیون رکورد و 3 گیگ حجم داره در 0.0002 ثانیه اجرا میشه حالا همین کوئری را یک شرط هم بهش اضافه می کنیم که کوئری دنیای واقعی نزدیکتر شود

SELECT * FROM `com` WHERE `uid` = 17672


زمان اجرا میشه

Showing rows 0 - 24 (2696 total, Query took 0.0005 seconds.)


یعنی همچین کوئری توی یک جدول درست و بهینه فقط 0.0005 ثانیه طول میکشه حالا شما همین کوئری را 100 بار اجرا کنید زمان اجرا میشه 0.05 ثانیه که اصلا زمان اجرای مهمی نیست پس میتوانیم نتیجه بگیریم تعداد کوئری ملاک بهینه سازی نیست و مهم اجرای کوئری هست و زمان اجرای کوئری ها.


نیتجه گیری من این هست که تعداد کوئری مشکلی ندارد شما اگر یک کوئری داشته باشید که بهینه نباشه و 1 ثانیه طول بکشه همین یک کوئری هم زیاد هست ولی اگر 100 تا کوئری داشته باشید که در چندهزارم ثانیه اجرا میشوند اصلا مسئله ای نیست.

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

در مورد max_connections این پارامتر در مورد تعداد کانکشن ها هست و علتش را خواهم گفت ولی قبلش لازم هست بدانیم به ازای هر کوئری یک کانکشن برقرار نمیشه پس این پارامتر مربوط به تعداد کوئری نیست روی یک کانکشن تا زمانیکه باز هست میشه هر تعداد کوئری که لازم باشه انجام داد ؛ علت محدود کردن تعداد کانکشن ها در mysql منابع سرور هست به ازای ایجاد هر کانکشن مقداری از منابع سرور اختصاص پیدا می کند که اگر این محدودیت درست رعایت نشود منابع سرور هدر میرود و درصورت عدم ایجاد محدودیت صحیح موجب هنگ کردن سرویس و لود بالا میشود.

[ali2k5]

باعرض پوزش پافشاری زیادی روی مسئله تعداد کوئری ندارم و صرفا هدفم جا نیفتادن این باور هست و تاکید بیشتر روی اصل مطلب یعنی کوئری بهینه نه تعداد کوئری ببخشید سرتان رو درد آوردم.

[rezaonline.net]

یعنی همچین کوئری توی یک جدول درست و بهینه فقط 0.0005 ثانیه طول میکشه حالا شما همین کوئری را 100 بار اجرا کنید زمان اجرا میشه 0.05 ثانیه که اصلا زمان اجرای مهمی نیست پس میتوانیم نتیجه بگیریم تعداد کوئری ملاک بهینه سازی نیست و مهم اجرای کوئری هست و زمان اجرای کوئری ها.
یه نگاه به سی پی یوتونم بندازید بد نیست :)
ممنون میشم ساختار جدولتون + مشخصات سرورتون رو بذارید .
همچنین انجین دیتابیستون myisam هست که نسبت به innodb سریعتره
بنده هم تجربه 6 میلیون رکورد روی یک سرور معمولی (رم یک گیگ سی پی یو اشتراکی) دارم که روزانه بیش از سیصد هزار بازدید داره و زمانش مشابه زمان شماست حتی انجین هم innodb هست
:)
حقیقتا من استدلالتون برای مجاز بودن تعداد کوئری ها رو قبول ندارم .
تعداد کوئری های بالا (ولو اینکه سرعت اجرای ناچیزی هم داشته باشند) موجب افزایش کانکشن ها با دیتابیس و بالا رفتن سرعت لود میشود وقتی تعداد بازدیدها بالا بره .

[intel_amd]

یک سوال مهم که نسبت به این میخوام یک بخش مهمی از سیستممو طراحی کنم که خیلی حساسه
یک جدول دارم با 7 فیلد که بار زیادی از لحاظ پردازشی و ترافیک روش میافته و الان می خوام 10 فیلد دیگه بهش اضافه کنم که یکی از فیلدهاشم متن طولانی میتونه باشه
حالا سوال اینجاست که این 10 فیلدو یک جدول جدا کنم یا اینکه به همین جدول اضافه کنم و باعث سنگین شدن کار نمیشه؟

[joker]

نمیدونم سیستمتون بر چه اساسی هست ولی به طور کلی : آیا از مکانیز کش کردن هم استفاده میکنید ؟
شاید نیاز نباشه هر لحظه کل دیتا از اول پردازش کنید

[intel_amd]

سیستم یک طوریه که باید اطلاعات به روز هر بار لود شه

[intel_amd]

قوی ترین برنامه برای کد کردن فایل های php بهم گفتن zend guard هست حالا میخاستم ازش استفاده کنم میخاستم ببینم توی اینجور سیستم های سنگین تاثیر منفی نمیذاره؟
قوی تر یا بهینه تر از zend guard اگر چیزی هست بگین هرچند همون zend guard 5.5 با کرک هم پیدا نکردم