مرجع تخصصی برنامه نویسان

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

نیاز به راهنمایی در رابطه با دریافت اطلاعات از دیتابیس mysqli

یکشنبه, 13 خرداد 1397 09:08

نیاز به راهنمایی در رابطه با دریافت اطلاعات از دیتابیس mysqli

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

من دو صفحه ایجاد کردم که یکی به نوعی صفحه شخصی کاربران سایت هست و دیگری صفحه نمایش پست های کاربران

کاربران در صفحه شخصی خودشون میتونند پست اضافه کرده و منتشر کنند.

دیگر افراد میتونند کاربران مورد نظر خودشون را دنبال کنند و پس از دنبال کردند، باید در صفحه نمایش پست ها، پستهای کاربرانی که دنبال کردند را بتوانند مشاهده کنند.

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

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

// میتوان در یک دیتابیس لیست افرادی که دنبال می کنند را ذخیره کرد و سپس یکی یکی آی دی اون افراد جستجو بشه و پست ها نمایش داده بشه اما این کار اصلاً جالب نیست و همچنین وقتی کاربر مثلاً 400 نفر را دنبال کند این کار اصلاً منطقی نیست چون هم زمان زیادی صرف دریافت اطلاعات از سرور می شود و هم اینکه چهارصد مرتبه اتصال به دیتابیس جهت دریافت اطلاعات با هر رفرش مناسب نیست

لطفاً روش انجام این کار را به من بگید، پروتکل و روش و راه جستجوی پستهای افرادی که دنبال شدند را بهم بگید ممنون میشم

دوشنبه, 14 خرداد 1397 21:21

سلام

یک راه حل  میتونه این باشه که یک جدول بگذاری در دیتابیس که افرادی که هر کاربر دنبال میکنه رو در اون جدول ذخیره کنی. هر رکورد جدول، یک دنبال کننده. این جدول شامل دو فیلد مهم هست. فیلد اول، شناسه کاربر و فیلد دوم شناسه کاربری که دنبال میکنه.

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

مثلا یه چیزی شبیه این:

فرض کن جدولی که در بالا گفتم این مدلی باشه:

نام جدول: users_follow

فیلدها:

id: شناسه جدول

user_id: شناسه کاربر

follow_user_id: شناسه کاربری که دنبال میکند

حالا کوئری گرفتن پستهای کاربرانی که دنبال میشن یه چیزی شبیه این هست:

select * from posts 
where posts.user_id in (select follow_user_id from users_follow where user_id = 5)

اون عدد ۵ هم شناسه کاربری هست که لاگین کرده و posts.user_id هم شناسه کاربری هست که پست رو گذاشته.

البته از * هم استفاده نکنید و فیلدهای مورد نظرتون رو بنویسید.

این کار راه های دیگه ای هم داره.مثلا از join هم میشه استفاده کرد که اگر درست بنویسیدش، یه خورده بهینه تر از ساب کوئری که نوشتم هست.

دوشنبه, 14 خرداد 1397 22:12

سلام جناب فرخی

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

مثلاً فرض کنید 2000 کاربر توسط یک نفر فالو شوند

حالا یک همچین جستجویی با هر مرتبه رفرش اصطلاحاً برابر هست با مرگ دیتابیس

در سایت بیش از 100 هزار کاربر فعال هستند

به این شکل انجام جستجو عملکرد خوبی نخواهد داشت

مثلاً شبکه اجتماعی اینستاگرام را در نظر بگیرید که شما به طور مثال 3000 نفر را دنبال می کنید، سپس خیلی سریع پست های افرادی که فالو کردید را می توانید مشاهده کنید

اگر به شکل ساده جستجو انجام بشه زمان خیلی خیلی زیادی صرف جستجو با هر مرتبه رفرش شدن میشه که اصلاً منطقی نخواهد بود

الان اگر شما میکروتایم بگیرید از دستوری که خودتون فرمودید با فرض 1000 فالوور، بین 15 تا 20 ثانیه جستجو طول میکشه که بسیار وحشتناک خواهد بود برای سرور که هر جستجوی هر کاربر این مقدار زمانبر باشد

ﺳﻪ شنبه, 15 خرداد 1397 19:37

سلام

کاملا درست هست صحبتتون و این کدی که من نوشتم چندان بهینه نیست البته نه دیگه ۱۵ الی ۲۰ ثانیه برای اجرا.

اگر واقعا این زمان رو بدست آوردین، یه بررسی کدهاتون، طراحی دیتابیس و تنظیماتش رو بکنید چون زمان خیلی زیادی هست و منطقی نیست.

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

سایتها و نرم افزارهای بزرگ کلا از ساختارهای عادی برای بهینه شدن استفاده نمیکنن. کلی تنظیمات روی سیستم عامل سرور، نرم افزار وب سرور، دیتابیس و ... انجام میدن. از اینها گذشته، سخت افزار سرور هم مهمه. بعدش اونها از یک دیتابیس و یک سرور استفاده نمیکنن. دنبال مباحث load balancing هم باشین.

بعد از تمام تنظیمات فوق، تازه میرسیم سر کدها که واقعا نمیشه همینجوری گفت که باید چطوری بهینه بشن.

از ساده ترین ها شروع میکن، مثلا از ایندکسها استفاده کردین؟ روی کدوم فیلدهاتون؟ و چه نوعی؟

ساختار جدولها رو درست تنظیم کردین؟

انجین جدولهای دیتابیستون رو چی قرار دادین؟

بعدش میریم توی کد، سایت شما که این همه کاربر داره، چرا دارین از mysqli استفاده میکنین؟

توی مرحله بعد باید نوع فراخونی کوئری ها رو بررسی کنید. مثلا همین موردی که گفتید که «حالا یک همچین جستجویی با هر مرتبه رفرش اصطلاحاً برابر هست با مرگ دیتابیس» چرا این اتفاق برای کدهاتون میوفته؟ در حالت عادی این کدی که من نوشتم به ازای هر کاربر، فقط یک بار اجرا میشه. تازه مواردی که باید شرط بگذارین رو دیگه ننوشتم که خودتون تنظیم کنید، که اونها هم باعث سریعتر اجرا شدن کد میشن.

ساختارهای lazy loading رو دارید توی کدهاتون؟

داشت یادم میرفت، کش روی کوئری ها و کدها تون دارین؟

همه اینها که گفتم تازه بخشی از دریای بهینه سازی اجرای سایت هست. شما تا کجا جلو رفتین و الان به چه مشکلی برخوردین؟

کسانی که از این پست تشکر کرده اند : rewrew,
ﺳﻪ شنبه, 15 خرداد 1397 20:41

سلام قربان؛ واقعاً از شما متشکرم استاد بابت راهنمایی‌هاتون . ممنونم که پاسخ میدید.

-- تا حد 15 تا 20 ثانیه اغراق نبود و دلیلش اشتباه بنده در بارگزاری اطلاعات بود که اصلاح شد ولی باز هم به این شکل که جستجو به صورت column in (ids) باشه زمان خیلی زیادی اتلاف میشه جهت دریافت اطلاعات

 

-- به طور کلی باید عرض کنم خدمتتون که یک شبکه اجتماعی نیمه خصوصی هست که دارم که کارش ارتباط تک به تک بود قبلاً و الان در حال توسعه اون هستم و بخش های گسترده و ارتباط گروهی و ... را دارم بهش اضافه می کنم و چون من کارم چیز دیگه ای هست و صرفاً جهت علاقه شخصی قبلاً در رابطه با کدنویسی مطالعه کرده بودم و خودم بدون کلاس آموزشی سعی کرده بودم برنامه نویسی را یاد بگیرم از زبان های سمت سرور و دیتابیس فقط php و mysql را یاد گرفتم، به همین دلیل توانایی کدنویسی به زبان ها و دیتابیس های دیگه رو ندارم.

 

-- دیتابیس به این شکل هست الان که یک جدول برای پست ها قرار داده شده به طور خلاصه به این شکل

id / time / userid / ...

و جدول دیگه ای قرار دادم برای ذخیره اطلاعات دنبال کردن به شکل زیر

id / time / userid / followid

در دیتابیس ها ستون id به صورت خودکار تکمیل میشه که کاری بهش نداریم فعلاً و ستون تایم هم که زمان ثبت میشه مهم نیست، میرسیم به ستون userid

در جدول اول کسی که پست منتشر میکنه و میذاره userid اون ثبت میشه و در جدول دوم کسی که یک نفر رو فالو کنه userid و followid که همون آی دی کسی هست که فالو کرده ثبت میشه

جدول کاربران را هم دارم که تقریباً به همین شکل هست و هر نفر یک آی دی میگیره و ...

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

حالا من اصلاً نمیدونم در شبکه های اجتماعی هم اطلاعات دنبال کننده ها رو به این شکل به صورت تک تک در دیتابیس ذخیره می کنند یا نه ، به هر حال الان من به این شکل کدنویسی کردن که شما اگر کاربر 5400 را دنبال کنید یک رکورد در جدول دوم ایجاد میشه که زمان و آی دی شما و آی دی 5400 توش ثبت میشه (البته اگر قبلاً این کاربر را دنبال کرده باشید دیگه ثبت نمیشه چون نیازی نیست و هر کاربر را تنها یک مرتبه میتونید دنبال کنید)

کد خیلی خیلی ساده جستجو به این شکل هست که شما هم خلاصه تر لطف کردید و کد را نوشتید

من یک مرتبه جستجو میکردم لیست آی دی های دنبال شده توسط کاربر X را در یک Array قرار میدادم و میذاشتم توی دستور سلکت بعدی

select Columns from DB where userid in (array)

کدی که شما فرمودید خلاصه تر هست اما در نهایت همین کار را انجام میده حالا مشکل اینجاست که مثلاً وقتی کاربر X تعداد 2000 نفر را دنبال کرده باشه جستجو برای خط بالا خیلی زمان بر تر خواهد بود

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

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

فرمودید "توی اون متن هم نوشتم که مثلا جوین از این بهینه تر هست اما شما نگفته بودین که خودتون چقدر بلد هستین."، من متاسفانه نمیدونم به چه صورت میتونم از دستور join در این قسمت استفاده کنم.

"سایتها و نرم افزارهای بزرگ کلا از ساختارهای عادی برای بهینه شدن استفاده نمیکنن. کلی تنظیمات روی سیستم عامل سرور، نرم افزار وب سرور، دیتابیس و ... انجام میدن. از اینها گذشته، سخت افزار سرور هم مهمه. بعدش اونها از یک دیتابیس و یک سرور استفاده نمیکنن. دنبال مباحث load balancing هم باشین."

راستش این حالت با توجه به رایگان بودن و عدم سود آوری فعلاً قابل انجام نیست و توی هزینه های همین یک سرور هم موندم

 

"مثلا از ایندکسها استفاده کردین؟ روی کدوم فیلدهاتون؟ و چه نوعی؟ ساختار جدولها رو درست تنظیم کردین؟ انجین جدولهای دیتابیستون رو چی قرار دادین؟"

جدول ها رو تا حد امکان از نظر تعداد کاراکتر و نوع فیلد ورودی سعی کردم مناسب انتخاب بشه مثلاً فیلدهای id تماماً int هست و به صورت AUTO_INCREMENT مقدار دهی میشه و فیلد زمان unixtime دریافت میشه که شناسه زمان هست به صورت عددی 10 رقمی فکر کنم باشه و int انتخاب شده که توسط سورس مقدار دهی میشه با دستور time() در php  و فیلد userid هم int هست و مابقی موارد هم به همین شکل بر اساس مقدار دیتای ورودی تنظیم شدن و فیلد متن پست ها هم با توجه به اینکه حدود یک سوم کاربران ایرانی هستند، utf8 و فیلد varchar استفاده شده با تعداد ورودی 500 کاراکتر (چون ماکسیمم کاراکتر مجاز در پست ها 500 کاراکتر هست) {البته به صورت Text هم گذاشتم اما فرقی نکرد و برگردوندم به همون varchar} / انجین دیتابیس چون از mysqli استفاده میکنم پیشفرض innodb خودش تنظیم کرد و منم تغییر ندادم

 

"بعدش میریم توی کد، سایت شما که این همه کاربر داره، چرا دارین از mysqli استفاده میکنین؟"

چون تخصصی در زبانهای برنامه نویسی ندارم و به صورت خیلی دست و پا شکسته تونستم خودم php و mysqli رو یاد بگیرم

 

"توی مرحله بعد باید نوع فراخونی کوئری ها رو بررسی کنید. مثلا همین موردی که گفتید که «حالا یک همچین جستجویی با هر مرتبه رفرش اصطلاحاً برابر هست با مرگ دیتابیس» چرا این اتفاق برای کدهاتون میوفته؟ در حالت عادی این کدی که من نوشتم به ازای هر کاربر، فقط یک بار اجرا میشه. تازه مواردی که باید شرط بگذارین رو دیگه ننوشتم که خودتون تنظیم کنید، که اونها هم باعث سریعتر اجرا شدن کد میشن."

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

 

"ساختارهای lazy loading رو دارید توی کدهاتون؟"

تصاویر نداریم فعلاً و فقط متن ساده هست بنابراین lazyload استفاده نشده

 

"داشت یادم میرفت، کش روی کوئری ها و کدها تون دارین؟"

متاسفانه اطلاعی در این باره ندارم و کوئری ها به چه شکل میتونه کش بشه ؟ آخه توی هر لحظه اطلاعات تغییر پیدا میکنه و پست های جدید اضافه میشه ؟!!!

 

مشکل کند بودن در دریافت اطلاعات از دیتابیس هست و تمام مشکل به خاطر تعداد بالا بودن کاربران هست، چند روز قبل با یکی از دوستانم مشورت کردم قبل از اینکه تیکت بزنم پیشنهاد داد محدودیت دنبال کردن بذارم و گفت که در اینستاگرام فقط میشه 8000 نفر را فالو کرد و بیشتر از اون مجاز نیست اون هم با توجه به چندین میلیون کاربر و پیشنهاد داد که با توجه به اینکه تعداد کاربران فعلی خیلی کم هست و حدود 100 هزار نفر هست محدودیت مثلاً ماکسیسمم 250 نفر دنبال کردن را بذارم؛ به نوعی میشه گفت منطقیه اما دوست داشتم کاربران آزاد باشند و بدون محدودیت بتونند از این سیستم استفاده کنند

 

من واقعاً معذرت میخوام که این همه متن طولانی و سوال نوشتم و وقت شما رو گرفتم، ببخشید.

لطفاً اگر وقت آزاد داشتید و امکان پذیر بود بنده رو راهنمایی بفرمایید. متشکرم.

ﺳﻪ شنبه, 15 خرداد 1397 21:05

ببخشید چند تا سوال دیگه هم داشتم

-------

1: طبق فرموده شما "بعدش میریم توی کد، سایت شما که این همه کاربر داره، چرا دارین از mysqli استفاده میکنین؟" از چه نوع دیتابیس دیگه ای میشه استفاده کرد که بهینه تر باشه و بتونم با php ازش استفاده کنم ؟

------

2: بهنرین روش ارسال اطلاع رسانی های سایت به چه صورت است ؟ (منظور اطلاع رسانی پیامکی و ایمیلی و ... هست)

در حال حاضر فقط برای بخش عضویت کاربران و تأیید شماره موبایل پیامک ارسال میکنم که از پنل پیامک sms.ir استفاده میشه

وب سرویس خوبی داره که به دو حالت تا حالا استفاده کردم اما هیچ کدام مطلوب نبود:

حالت اول :  وب سرویس را با متد http که filegetcontent آدرس هست استفاده کردم میانگین 1.5 الی 2.5 ثانیه طول میکشه؛ همین ارسال و به صورت curl هم انجام دادم باز هم به همین شکل بود، پنل های دیگه ای رو هم تست کردم از این کند تر بودند و زمانیکه کاربر روی عضویت کلیک میکنه حداقل یک ثانیه طول میکشه تا عضویت انجام بشه به طور عادی جهت ذخیره اطلاعات در دیتابیس جهت عضویت و وقتی از پیامک هم استفاده بشه دیگه خیلی طول میکشه این مورد.

حالت دوم : اطلاعات پیامک ها رو در دیتابیس ذخیره می کردم و به کمک cronjob دقیقه ای یک مرتبه دیتابیس چک میشد و اگر پیامک ارسال نشده ای بود ارسال انجام میشد و وضعیت به ارسال شده بروزرسانی میشد که این حالت بهتر بود چون عضویت طول نمی کشید خیلی اما مشکل این بود که پیامک همون لحظه عضویت به کاربر ارسال نمیشد و به همین دلیل مناسب نبود

حالا راهی وجود داره که همون لحظه عضویت پیامک ارسال بشه اما از زمان عضویت کاسته نشه ؟ مثلاً اطلاعات برای یک صفحه جانبی در سرور ارسال بشه و اون صفحه کار ارسال پیامک رو جدا انجام بده؟ چون با curl هم این کار انجام شد اما باز هم اون مقدار زمان طول میکشید

-------

3: اگر بخوام برای کاربران ایمیل هم ارسال کنم در حالات خاص، مثلاً عضویت و تأیید آدرس ایمیل یا مثلاً پذیرفته شدن درخواست فالو توسط افرادی که پیجشون خصوصی هست و ...؛ ارسال ایمیل به چه صورت خواهد بود ؟

چون دقیقاً مشابه با مشکل ارسال پیامک، طول زمانی ارسال ایمیل هم 2 ثانیه طول بکشه اون وقت کاربر از عضویت پشیمون میشه ... :D

------

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

(یه چیزی مشابه با این که مثلاً فلان نرم افزار در پس زمینه کارش رو انجام میده)

چهارشنبه, 16 خرداد 1397 12:49

سلام

توصیه اول من این هست که حالا که دارید کدتون رو توسعه میدید، روی php ۷ کار کنید که بازدهی خیلی بالاتری داره.

برای ارتباط با دیتابیس هم از pdo استفاده کنید. البته میدونم که کلی داستان خواهید داشت برای تغییر کدهاتون اما ارزشش رو داره.

در مورد انجین های mysql حتما مطالعه کنید. لازم نیست همه جدول ها از نوع innodb باشن . برای بعضی جدولها باید myisam استفاده کنید.

در مورد ایندکس ها هم مطالعه کنید. مثلا اینجا برای شروع خوبه:

https://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html

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

این موارد چون خیلی طولانی هستن رو نمیشه اینجا مطرح کرد. هر کدومشون یه مقاله طولانی هستن.

یه نکته ای رو در مورد فراخونی در نظر بگیرین: فرض کنید طبق مثال خودتون یه کاربری ۲۰۰۰ تا فالوئر داشته باشه. حالا فرض کنید که همه این کاربرها هر کدومشون یک پست گذاشتن (حداقل)، وقتی کاربر میخواد پستهای اونها رو ببینه، لازم نیست که شما همه ۲۰۰۰ تا پست رو باهم از دیتابیس بخونید و بیارید. کاربر که همه رو با هم نمیبینه.

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

البته توصیه میکنم اگر میخواهید با ajax پست های بعدی رو لود کنید خیلی دقت کنید که حالا این دفعه ajax سایتتون رو از کار نندازه. به نظرم آنگولار برا اینکار بهتر باشه.

ساختارهای lazy load فقط برای تصاویر استفاده نمیشن. معمولا برای تصاویر استفاده میشن.

در مورد کش هم اونجوری که فکر میکنید نیست، مخصوصا در مورد کوئری ها. اینجا رو مطالعه کنید:

https://dev.mysql.com/doc/refman/5.6/en/query-cache.html

مشکل کند بودن خواندن اطلاعات از دیتابیس رو میتونید با افزایش سخت افزار خصوصا cpu و ram سرور تا حدی بهتر کنید. در مرحله بعد باید حتما  از سیستم عامل گرفته تا دیتابیس رو درست کانفیگ کنین. این دیگه توی حوزه تخصص ادمین های سرور هست. اگر با شرکتی که سرورتون رو ازشون تهیه کردین تماس بگیرین، معمولا در ازای دریافت هزینه ای، خودشون توی خیلی از موارد بهتون کمک میکنن. حالا درسته که هزینه هاتون بالاتر میره، اما خیلی از مشکلاتتون رو تا حدی حل میکنه.

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

در مورد پیامک و ایمیل هم مدت زمان پاسخگویی فقط مرتبط با کد شما نیست، اون سرویس دهنده ها هم تاثیر میگذارن و پیامک که اپراتورهای تلفن همراه هم دخیل میشن. یه مدت زمانی که همیشه هست. مطمئنا کاربر ها رو اذیت نمیکنه. البته اگر هرچه کوتاه هتر بشه این زمان بهتره.

برای دریافت پیامک در پنل sms.ir (خودم ازشون استفاده کردم) چرا از سرویس ارسال پیامک به url استفاده نمیکنید؟

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

نگران اون ۲ ثانیه نباشین چون معمولا نمیشه کاریش کرد. نهایتا اگر خیلی نگران هستین که کاربر پشیمون بشه، خوب اصلا حذفش کنید این تاییدیه مربوط به کاربر رو.

یه نکته ای بگم: توی چرخه زندگی نرم افزارها (هر نوعش از سایت گرفته تا اپ ها و نرم افزارهای سیستمی) گاهی اوقات توسعه ای قراره اتفاق بیوفته که کلی تغییرات باید توی کدها داده بشه. در این جور مواقع معمولا پیشنهاد میشه که نرم افزار از اول و بر اساس نیازهای جدید نوشته بشه.

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

چهارشنبه, 16 خرداد 1397 15:08

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

متشکرم از شما که پاسخ دادید و وقت خودتون رو در اختیار من قرار دادید ممنونم

یک مقدار بررسی انجام دادم و عملاً تغییر از mysqli به pdo از توانایی من خارج هست

در رابطه با انجین ها که فرمودید، باید مطالعه کنم چون اطلاعاتی در این رابطه ندارم و فقط از innodb پیشفرض خود mysqli استفاده کردم، البته جایی قبلاً خونده بودم که myisam زمان انجام پردازش اصطلاحا کل جدول را قفل میکنه readonly میکنه و بعد مجدد باز میکنه اما innodb فقط همون سطر رو قفل میکنه و اینکه حالت innodb برای دیتابیس هایی که حجم خیلی زیادی دارند و تغییر اطلاعاتشون زیاد هست بهتر عمل میکنه تا myisam و یک مورد دیگه که مطمئن نیستم و شاید اشتباه کنم، فکر کنم اگر myisam باشه موقع بک آپ گرفتن کل دیتابیس از کار می افته تا بک آپ گیری کامل بشه ولی در حالت innodb اینجوری نیست و هر لحظه میشه از دیتابیس بک آپ گرفت (البته این رو مطمئن نیستم و از یک برنامه نویس در رابطه با علت اینکه برخی از سایت ها مثل nic.ir زمان بک آپ گیری سایتشون را تعطیل میکنند مثلاً برای 15 دقیقه یا نیم ساعت پرسیده بودم و پاسخ اون تفاوت در نوع این دیتابیس ها بود)

در رابطه با index ها که فرمودید من فکر میکردم فقط یکی از ستون ها رو میشه ایندکس تعریف کرد !

از limit استفاده کردم در کوئری ها برای اینکه تمام پست ها با هم لود نشوند البته اطلاعی در رابطه با نحوه استفاده از angular نداشتم و از ajax هم استفاده نکردم و فعلاً صفحه بندی ساده گذاشتم تا بعداً در آینده در صورت امکان گسترش بدم سورس را

""ساختارهای lazy load فقط برای تصاویر استفاده نمیشن. معمولا برای تصاویر استفاده میشن."" : مطالعه کردم متوجه شدم تفاوت eager load و lazy load در نحوه بارگزاری اطلاعات

""در مورد کش هم اونجوری که فکر میکنید نیست، مخصوصا در مورد کوئری ها. اینجا رو مطالعه کنید:"" : خوندم اما درست متوجه منظور کلی مطلب نشدم و باید بیشتر مطالعه کنم، اما تا حدودی مثل این هست که کاربردش برای درخواست های تکراری و مشابه هست

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

 

""برای دریافت پیامک در پنل sms.ir (خودم ازشون استفاده کردم) چرا از سرویس ارسال پیامک به url استفاده نمیکنید؟"" : منظورم از http همون ارسال پیامک به url بود که به شکل  file_get_contents() آدرس رو فراخوانی میکردم، اما همین قسمت خودش یک مدت زمانی رو نیاز داره و طول زمانی کلی افزایش پیدا میکنه

 

""برای ارسال پیامک (یا ایمیل حتی)، هم نیاز نیست منتظر جواب سروری که بهش ارسال کردید، بمونید که زمان بگیره، یه لینکی، دکمه ای قرار بدین که اگر کاربر پیامک رو دریافت نکرد، دوباره درخواست کنه. این منتظر موندن برای پاسخ سرور، جالب نیست مخصوصا در مواقعی که ترافیک زیادی روی شبکه های اپراتورهای تلفن همراه هست و بعضا پیامک ها با تاخیرهای طولانی به گوشی کاربر ارسال میشن."" : جسارتاً مثلاً در مثال خیلی خیلی ساده جهت ارسال پیامک شما مثلاً ربات تلگرامی که شما اطلاعات را ارسال میکنید با فرضاً curl در نهایت باید منتظر پاسخ ارسال موفق اطلاعات باشید که مثلاً در حالت پیامک مقدار 1 برگشت داده میشه یا در مثلاً تلگرام send true در json کد نمایش داده میشه؛ آیا راهی هست که همین که ارسال انجام بشه کفایت کنه و منتظر این پاسخ از سمت سرور مقصد نباشیم ؟

 

""نگران اون ۲ ثانیه نباشین چون معمولا نمیشه کاریش کرد. نهایتا اگر خیلی نگران هستین که کاربر پشیمون بشه، خوب اصلا حذفش کنید این تاییدیه مربوط به کاربر رو."" : راستش مشکل 2 ثانیه نیست بلکه قطره قطره حجم گردد وانگهی دریا شود هست، 2 ثانیه پیامک طول میکشه 2 ثانیه ایمیل بخواد طول بکشه و 1 ثانیه ارسال اطلاعات و عضویت طول بکشه و بعدش مثلاً 1 ثانیه ثبت و دریافت مابقی اطلاعات همینجور این موارد باعث افزایش زمان می شوند، میشه این ها رو حذف کرد و وقتی کاربر وارد شد براش دکمه ای رو قرار داد که با کلیک روی اون پیامک ارسال بشه یا ... اما خیلی جالب نیست

 

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

 

مسلماً بسیار بسیار بهتر هست که من کار را به یک برنامه نویس بسپارم و اون شخص یا گروه بهترین و استاندارد ترین کد رو واسم بنویسند، اما حسی که خود آدم کدش رو بنویسه و یاد بگیره و بدونه چکار کرده خیلی متفاوت هست ... . یک جورایی حس پدرانه دارم نسبت به این سیستم و کدها

 

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

 

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

ارسال پاسخ برای این تاپیک

ارسال پاسخ مخصوص اعضا سایت می باشد ! میتوانید با حساب کاربری خود وارد سایت شده یا ثبت نام کنید