ببخشيد منظور از delay در indy چيه؟ indy يك كتابخانه سوكت thread based , Blocked mode هست يعني تا اطلاعات كامل توسط سوكت دريافت نشه كنترل به برنامه برنميگرده براي كار با indy بايد به كار با thread ها هم مسلط باشيد اونوقط ميبينيد كه اين كتابخونه تا جايي كه تعداد thread ها اجازه بده بهترن كيفيت رو ارايه ميده و كاملا stable هست و ميشه براي پروژه هاي بزرگ هم روش حساب كردنوشته شده توسط Gold
ولي هنوزم متوجه نشدم منظور از delay دقيقا چي بوده؟
خوشبختانه هم به indy مسلط هستم هم به تردها.
در پروژه ای که برای مثال عرض کردم : قرار بود برنام ای شبیه به IDM بنویسم. برای این منظور تعداد دلخواه کانکشن میساختم و هر کانکشن هم در ترد مخصوص به خودش در حال دانلود از سرور بود.
زمانی که سرور درگیر بود و نمیتونست با سرعت زیاد دیتا رو بفرسته ، برنامه منتظر میموند تا برادر ایندی همون قضایای بهینه سازی و حتی UseNagle رو رعایت کنه.
واسه همین زمان دانلود کانکشن ها زیاد میشد. بنا بر این مجبور به استفاده از سوکت به طور مستقیم شدم. که دقیقا همین سناریو بدون هیچ افت سرعتی ، حتی بهتر از IDM پیاده شد.
خوب به نظر بنده اين نقطه ضعف indy حساب نميشه ! برنامه نويس بايد با توجه به نوع پروژه از ابزار موجود با توجه به تخصصشون در جاي درست استفاده كنه كه شما هم به همين نتيجه رسيديد و از روش ديگه اي استفاده كرديد. هرچند به نظر من دانلودر رو هم ميشه بدون delay به قول شما با همين indy پياده كرد.
در مورد محصولات synopse من هيچوقت ديد خوش بينانه نداشتم و ندارم. هر وقت به سايتش سر ميرنم حس ميكنم اونجا اصلا پدر و مادر و صاحب نداره هر پروژه براي خودش رها شده معلوم نيست روي چي متمركزن
براي Blocked Socket بهترين كتابخونه indy و براي NoneBlocked بهترين كتابخونه ICS هست و امتحانشو توي خيلي از پروژه ها پس داده. براي مورد دانلودر هم در يكي از برنامه هاي معروف از ICS استفاده شده بود كه اسمش الان خاطرم نيست.
البته فريموركهاي تجاري بزرگي هست كه قيمت بالايي دارن و ميشه ازشون استفاده كرد
بحث به سمت سوكتها رفت اميدوارم در موضوع اصلي بحث اختلال ايجاد نكرده باشم.
میشه اگه در ذهن دارید چند تا از این فریمورک ها رو نام ببرید؟
در مورد تعداد 2000 ترد در نرم افزارها يه زماني من اين مشكل را داشتم يعني با كامپايلر دلفي 7 توي يك سيستم 32 بيتي نياز داشتم به تعداد بيش از 50 هزارتا ترد كه متوجه شدم به صورت پيش فرض تابع CreateThread را وقتي در يك سيستم عامل 32 بيتي صدا ميزنيم عملا تا تعداد حدود 2000 تا بيشتر نميشه ساخت ( اين همين موردي هست كه object pascal بهش اشاره كرده )
اين مورد شايد نشه اسمشو گذاشت باگ ، شايد بشه اسمشو گذاشت حواس پرتي طراحاي اين داستان، شايدم دليلي نميديدن براي تعداد بيشتر تردها در يك نرم افزار :)
يه سرچي زدم ديدم با تغيير پارامترها به شكل زير
CreateThread( nil,20480, @ThreadProc, nil,CREATE_SUSPENDED or STACK_SIZE_PARAM_IS_A_RESERVATION , thid) ;
اين محدوديت 2هزار تايي تا حدود 30 هزارتا برطرف شد.
و البته بعدش هم يه نكته عجيب برخورد كردم يعني همين برنامه 32بيتي كه تا 30هزارتا روي سيستم عامل 32بيتي رفته بود بالا ، روي يك سيستم 64 بيتي با همين ساختار نتونست بيشتر از 5-6 هزارتا ترد بسازه...
خلاصه بيخيالش شدم آخرش و به همين 30 هزارتا بسنده كردم :)
جوکر جان، این برنامه ای که توی اون فروم گذاشتی با کامپایلر 32 بیتی کامپایل شده؟ میشه سورس برنامه رو بذاری تا من با 64 بیتی کامپایل کنم تا ببینم نتیجه چی میشه؟
من با ویندوز 64 بیتی 6000 تا بیشتر نتونستم بسازم!
من یه برنامه خیلی ساده درست کردم و سرور DataSnap رو توی یک VPS گذاشتم، دستور اول سه ثانیه طول کشید، اما بقیه اش توی کمتر از یک ثانیه جواب میده. جریان چیه؟ کش میکنه؟
دلیلش اینه که برقراری ارتباط اولیه طول میکشه. اگه ارتباط برقرار شده باشه دیگه زمانی صرف برقراری اتصال نمیشه.
کش کردن اونطوری نیست. اگر منظورت کش کردن داده ها باشه باید از این روش استفاده بشه:جریان چیه؟ کش میکنه؟
http://www.andreanolanusse.com/en/ca...tasnap-server/
عجب! با وجود اینکه سرور توی آمریکا هست خوب توی سه ثانیه اتصال برقرار میشه. حالا سرور ما که قراره وطنی باشه. تازه VPS هم رم 256 هست. که البته فکر نکنم خیلی به سرعت اتصال مرتبط باشه. با این وجود، خوشمون اومدالان یه برنامه چت گروهی با استفاده از Delphi Lab میسازم بریم حالش رو ببریم.
البته به این نکته هم توجه داشته باش که اگه به جای Http از TCP استفاده کنی سرعت تا حدودی بهتر میشه و توصیه میشه که در صورتی که تعداد کاربران همزمان زیاده از TCP بجای HTTP استفاده بشه.
در ضمن توجه داشته باش که DataSnap تا حدود بسیار زیادی از dbExpress استفاده می کنه. اگه بشه کاری کرد که به جای اون از FireDAC استفاده بشه احتمال داره که سرعت کار تا 20% افزایش پیدا کنه. البته این مورد فعلاً برای من در حد تئوری است و دارم بر روی آن کار می کنم که ببینم امکان داره یا نه؟! اگر تونستم این کار را بکنم نتیجه رو در همین تاپیک قرار می دهم!این مورد هم به خاطر اینه که تست ها نشان داده اند که FireDAC تقریباً 25% از dbExpress سریعتر است. به نظرم اگر تیم توسعه دلفی کاری کنند که در مورد DataSnap غیر از استفاده از dbExpress انتخابهای دیگری هم داشته باشیم خیلی خوب میشه.
آخرین ویرایش به وسیله BORHAN TEC : پنج شنبه 08 فروردین 1392 در 23:25 عصر
آره، از TCP/IP استفاده کردم. البته در حد خیلی مبتدی، همون چیزایی که توی دلفی لبراتور بود. نه تیونی، نه متدهای حرفه ای، البته یه کوچولو تغییرش دادم.البته به این نکته هم توجه داشته باش که اگه به جای Http از TCP استفاده کنی سرعت تا حدودی بهتر میشه و توصیه میشه که در صورتی که تعداد کاربران همزمان زیاده از TCP بجای HTTP استفاده بشه.
فقط یه چیزی، وقتی با ابزار آلات رفع تحریم اینترنت ( دیگه منظورم رو بفهمید
به نظر من Embarcadero اگه پروژه mORMot رو بهینه کنه و روش کار کنه و توسعه اش بده و به عنوان یک کامپوننت بده بیرون خیلی بهتر خواهد شد.
الان داشتم توی وبلاگ حاج مارک گشت میزدم که چشم به این عنوان افتاد "Pushing the Limits of Windows: Processes and Threads" بعد که بازش کردم ببینم چه خبره دیدم این بحث دقیقاً همون چیزیه که قبلاً اینجا (توی این تاپیک) سرش جنگ بود (محدودیت در تعداد Thread های برنامه های 32بیتی ) خودم هنوز کامل نخوندمش ولی اگه بازم کسی با این موضوع مشکل داشت این مطالب رو بخونه مشکلی هم بود حاج Mark مثل شیر توی وبلاگش پاسخ میده
Everything that has a beginning has an end. ... The End?
قوانین ایجاد تاپیک در تالار
