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

[tomalaki]

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

تعداد 200-250 تا کلاینت داریم. کاربر برای ورود به برنامه ی کلاینت (که با دلفی قراره نوشته بشه) نیاز به ورود یک نام کاربری و رمزعبور می باشد. این نام کاربری و رمز عبور در یک پایگاه داده در یک سرور در یه جای دنیا قرار دارند. برنامه کلاینت با استفاده از بستر اینترنت به پایگاه داده مذکور متصل میشه. حالا میخوام بدونم که چطور باید این سناریو رو پیاده سازی کرد؟ اگر بخوام از یک تابع استفاده کنم که اگه نام کاربری و رمز عبور وجود داشت مقدار 1 رو برگردونه و فرم اصلی رو باز کنه، باید با استفاده از CallBackها پیاده سازی کنم؟ چون به نظر میاد هر کلاینت باید یک CallBackId و ClientId مجزا داشته باشند.

[BORHAN TEC]

سلام، من هم سال نو رو به شما تبریک میگم.

تعداد 200-250 تا کلاینت داریم.
شوخی میکنی؟! :گیج: بازم کارمند نمیخواین؟!!! :شیطان:

اگر بخوام از یک تابع استفاده کنم که اگه نام کاربری و رمز عبور وجود داشت مقدار 1 رو برگردونه و فرم اصلی رو باز کنه، باید با استفاده از CallBackها پیاده سازی کنم؟
این مورد رو میتونید با Rule ها به راحتی حل کنید. به طوری که مثلاً اگر Rule مربوط به یک کاربر X باشه بتونه در پایگاه داده فلان عملیات رو انجام بده و اگر کسی یک Rule مجاز رو نداشته باشه هیچ کاری نمیتونه بکنه. مثالی از این دست به صورت کامل در مقاله ای تحت عنوان DataSnap XE in Action (البته توی مقاله نوشته DataSnap in Action) نوشته آقای Bob Swart پیاده سازی شده است. اگر این مقاله 49 صفحه ای را به دقت(!) بخوانید همه چیز دستتون میاد.
موفق باشید...

[tomalaki]

شوخی میکنی؟! :گیج: بازم کارمند نمیخواین؟!!! :شیطان:

شما رئیس هستین، این حرفا نزنید. البته کارمند نه اون کارمندی که فکر میکنید، اصلا پروژه اداری نیست، یه چیز خیلی جالبیه. ایشاالله راه که افتاد حتما به شما میگم.
فقط DataSnap مشکلی که با تعداد 200-250 تا که نداره انشاالله؟! البته کار و حجم اطلاعاتی که توی شبکه و اینترنت رد و بدل میشه در حد 5 مگ در 24 ساعت نمیشه.

[BORHAN TEC]

ایشاالله راه که افتاد حتما به شما میگم.
انشاالله.

فقط DataSnap مشکلی که با تعداد 200-250 تا که نداره انشاالله؟!
از لحاظ تئوری و طبق گفته سازندگان ویندوز هر برنامه در محیط ویندوز می تواند حدود 2000 نخ(:متعجب:) داشته باشد. با این توضیحات و تئوری ها از آنجایی که DataSnap مبتنی بر Indy است و Indy هم به صورت Thread Base است باید بتواند تا حدود 2000 کاربر مختلف را مدیریت کند. همانطور که قبلاً هم گفتم Indy یک مقدار Delay بالایی داره پس باید کار کنید که ترافیک کم باشه و روی Tier میانی باید اصولی تر کار کنید و از تکنیکهایی استفاده کنید که ترافیک رو پایین بیاره و یک دفعه هر کاربری یک جدول 100000 رکوردی رو در سیستمش لود نکند! نمونه ای از این مشکل ساعتی پیش مطرح شد که به آن پاسخ دادم. حالا فرض کنید که اگر در موقع طراحی این مورد را در نظر نگیرید با 250 کاربر همزمان چه فاجعه ای به وجود میاد؟! این هم آدرس تاپیک مربوطه:
http://barnamenevis.org/showthread.php?390367
به عنوان یک توصیه برادرانه همیشه سعی کنید که در برنامه هایی که کاربران همزمان زیادی دارند ترافیک شبکه را با ابزارهایی مثل Net Limiter و ... اندازه گیری کنید و تا حد ممکن سعی کنید آن را کاهش دهید.
در مورد DataSnap استفاده از تکنیک هایی مثل Connection Pooling میتونه در بهینه سازی موثر باشه و تعداد کاربران همزمان رو به شدت افزایش بده، چون با استفاده از این تکنیک نیاز نیست که به ازای هر کلاینت یک Threat ساخته بشه و به کلام ساده میشه کاری کرد که به ازای چند کاربر یک نخ ایجاد بشه! یکسری روشهای بهینه سازی هم در جاهای مختلفی از اینترنت مثل اینها وجود داره که خوندن اونها توصیه میشه:

در این دو مورد کامنت ها رو بخوانید:
http://robertocschneiders.wordpress.com/2012/11/22/datasnap-analysis-based-on-speed-stability-tests/
http://robertocschneiders.wordpress.com/2013/01/09/datasnap-analysis-based-on-speed-stability-tests-part-2/

این مطلب از آقای Marco Cantu خیلی جالبه:
http://blog.marcocantu.com/blog/datasnap_deployment_performance.html

موفق باشید...

[tomalaki]

راهی بهتر و سریعتر از DataSnap هست؟ :(

[BORHAN TEC]

راهی بهتر و سریعتر از DataSnap هست؟ :(
mORMot، این محصول کاملاً رایگانه و راهنمای 1000 صفحه ای داره، فروم فعال داره، به شدت پایدار و سریع است و برای ساخت برنامه هایی که چند هزار(!) کاربر همزمان داره مناسب ترین گزینه در دلفی به شمار میره. طبق اون لینکها و تست هایی که انجام شده میشه متوجه شد که خیلی بهتر از WCF و فریم ورکهای مختلف دیگه عمل میکنه و نیازهای حافظه ای خیلی کمی داره (مناسب برای سرورهای ضعیف). اینم سایتشه که تمام توضیحات اونجا وجود داره:
http://synopse.info

[BORHAN TEC]

نکاتی رو فراموش کردم بگم:

- اگر تعداد کاربران خیلی زیاد باشه بهتره که از پروتکل TCP استفاده کنید و نه پروتکل HTTP.

- درسته که DataSnap فعلاً سرعت پایینتری داره ولی از لحاظ قابلیت واقعاً کامله: مثل پشتیبانی از REST و ساخت Interface برای کلاینتهای مبتنی بر موبایل مثل Android و Blackberry و iOS و زبانهای دیگر مثل Java و C# و ... . در حالت کلی بعید به نظر میرسه که برای 250 کاربر همزمان مشکلی داشته باشه. مگه 250 کاربر همزمان چقدر میتونه ترافیک داشته باشه؟ درسته که یه کمی سرعتش پایینه ولی این مورد موقعی مسئله سازه که تعداد کاربران واقعاً زیاد باشه. البته با توجه به جنجالی که اون دو تا مقاله ایجاد کرد طبیعتاً شاهد بالا رفتن Performance مربوط به DataSnap در آینده خواهیم بود.

[tomalaki]

ممنون، رفتم یه مقدار سطحی در موردش دونستم. فقط چیزی که هست ما چون Callback نیاز داریم فعلا نمیتونیم از mORMot استفاده کنیم. البته توی RoadMap که دیدم قرار هست که Callbackها بهش اضافه بشه. اما پرسشم اینه که این One-Way Callback منظروش چیه؟ آیا همون Publish کردن یک Event به همه ی کلاینت ها هست؟ آیا امکان ارتباط با تنها یک کلاینت با یک کانال اختصاصی مثل DataSnap بهش اضافه خواهد شد؟

[BORHAN TEC]

اما پرسشم اینه که این One-Way Callback منظروش چیه؟
اگه اشتباه نکنم یعنی "یه جور کالبک" و معنی فنی نباید داشته باشه، به عبارتی یعنی روشی برای پیاده سازی مکانیزم CallBack! این رو کجا خوندی؟

آیا همون Publish کردن یک Event به همه ی کلاینت ها هست؟
بلی، کالبک کالبکه، چه در DataSnap و چه محصولات دیگه.

آیا امکان ارتباط با تنها یک کلاینت با یک کانال اختصاصی مثل DataSnap بهش اضافه خواهد شد؟
این مورد فقط ربطی به یک کلاینت نداره و میشه اون رو برادکست کرد و یا فقط به چند کلاینت انتساب داد.

راستی به این نکته توجه داشته باش که اون موردی که در مورد AnyDac یا FireDAC گفتم هیچ ربطی به CallBack موجود در DataSnap و ... نداره ها. اون جزو پشتیبانی ذاتی Firebird و FireDac از مسئله مذکور است. منظورم پست شماره 3 تاپیک زیر هست:
http://barnamenevis.org/showthread.php?389227

[tomalaki]

اگه اشتباه نکنم یعنی "یه جور کالبک" و معنی فنی نباید داشته باشه! این رو کجا خوندی؟
توی RoadMap بود : http://synopse.info/fossil/wiki?name=RoadMap
اینم توی بلاگش خوندم: http://blog.synopse.info/post/2012/09/06/Roadmap%3A-interface-based-callbacks-for-Event-Collaboration

[tomalaki]

فکر میکنم که منبع خوبی برای On-Way-Callback باشه: http://msdn.microsoft.com/en-us/magazine/cc163537.aspx

[MohsenB]

سلام


...از لحاظ تئوری و طبق گفته سازندگان ویندوز هر برنامه در محیط ویندوز می تواند حدود 2000 نخ(:متعجب:) داشته باشد. با این توضیحات و تئوری ها از آنجایی که DataSnap مبتنی بر Indy است و Indy هم به صورت Thread Base است باید بتواند تا حدود 2000 کاربر مختلف را مدیریت کند ...

مطمئنید ؟! من الان برنامه ای رو میشناسم که با دلفی + Indy ساخته شده که کاربران آنلاینش به بیش از بیست و پنج هزار تا هم میرسه .


...همانطور که قبلاً هم گفتم Indy یک مقدار Delay بالایی داره ...

میشه منبعی یا جدول مقایسه ای برای این معرفی کنید ؟

[BORHAN TEC]

سلام،

فکر میکنم که منبع خوبی برای On-Way-Callback باشه: http://msdn.microsoft.com/en-us/magazine/cc163537.aspx
ممنون که معرفی کردی، الان دقیقاً نمیدونم چیه و باید سر فرصت این مقاله رو بخونم تا بفهمم چیه.

مطمئنید ؟! من الان برنامه ای رو میشناسم که با دلفی + Indy ساخته شده که کاربران آنلاینش به بیش از بیست و پنج هزار تا هم میرسه .
شدنیه، به شرطی که از Thread Pool استفاده بشه. آیا منظور شما 25000 کانال ارتباطی باز به صورت همزمان است؟ یعنی کاربران دیسکانکت میشن و موقع نیاز کانکت میشن یا اینکه همه کانکشن ها باز هستند؟
البته این رو هنوز نمیدونم که تعداد Thread ها در سیستم عاملهای 64 بیتی میتونه بیشتر از این مقدار باشه یا نه؟! :متفکر:

میشه منبعی یا جدول مقایسه ای برای این معرفی کنید ؟
جدولی سراغ ندارم. این رو آقای Primož Gabrijelčič گفته بودند(اگه اشتباه نکنم توی StackOverFlow). ایشون در Thread ها و پروتکلهای اینترنتی مهارت زیادی دارند و سازنده OmniThreadLibrary هستند. در صورتی که می خواهید از این موضوع مطلع شوید میتونید به خودشون ایمیل بزنید و بپرسید.

[MohsenB]

... آیا منظور شما 25000 کانال ارتباطی باز به صورت همزمان است؟

بله ، بصورت همزمان . همچنین تو دلفی 7 و ویندوز 32 بیتی .

[BORHAN TEC]

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

[MohsenB]

نه شاهین جان ارتباطی باهاشون ندارم . چند تا نرم افزار چت هستن . شما این رو که معرفی کردین باهاش کار کردین تا حالا ؟ میتونه جای Indy کار کنه ؟

[BORHAN TEC]

شما این رو که معرفی کردین باهاش کار کردین تا حالا ؟
نه هنوز ولی مطالعات خیلی کمی در موردش داشتم. اگه ورژن 1.18 اون بیاد باهاش کار میکنم.

میتونه جای Indy کار کنه ؟
نه، Indy و mORMot با هم قابل مقایسه نیستند چون برای کاربرد های کاملاً متفاوتی طراحی شده اند. شما باید mORMot رو با DataSnap مقایسه کنید. Indy برای برنامه نویسی سوکت و شبکه است و پروتکل های تحت شبکه را پیاده سازی کرده است در صورتی که DataSnap و mORMot برای ایجاد برنامه های Middle-Tier (کلاینت/سروری) هستند. البته توجه داشته باشید که DataSnap بر پایه Indy است ولی mORMot اینگونه نیست و ضعفهای ذاتی Indy رو نداره. این delay که Indy داره برای خیلی از برنامه های رایج مثل چت و ... خودش رو نشون نمیده و موقعی مشکل به وجود میاره که به کاربرد های شبه Realtime نیاز داشته باشیم (مثل برخی از پروژه های نظامی و ...). البته این مورد آخر رو همینطوری گفتم و الا من نمیدونم که آیا در پروژه های نظامی مثل کنترل موشکهای غیر حرارتی و ... از همین روش ها استفاده میشه یا نه؟ آیا از راه دور کنترل میشه یا همه چیز روی همون وسیله وصله و یا ...؟ :متفکر:

[Felony]

از لحاظ تئوری و طبق گفته سازندگان ویندوز هر برنامه در محیط ویندوز می تواند حدود 2000 نخ() داشته باشد.
سازندگان ویندوز کجا اینو گفتن ؟ تو کل Windows Internals و کتاب هایی که در مورد ساختار ویندوز خوندم یادم نمیاد به همچین محدودیتی اشاره شده باشه .
این موضوع با به وجود اومدن مفاهیمی مثل PAE (http://en.wikipedia.org/wiki/Physical_Address_Extension) و AWE (http://en.wikipedia.org/wiki/Address_Windowing_Extensions) بی معنی هست .
99 % موارد این محدودیت ها به دلیل نا آشنایی برنامه نویس ها با نحوه پیاده سازی Threading ، نحوه مدیریت ، سازمان دهی ، زمان بندی و ... در سیستم عامل هست .


mORMot، این محصول کاملاً رایگانه و راهنمای 1000 صفحه ای داره، فروم فعال داره، به شدت پایدار و سریع است و برای ساخت برنامه هایی که چند هزار(!) کاربر همزمان داره مناسب ترین گزینه در دلفی به شمار میره. طبق اون لینکها و تست هایی که انجام شده میشه متوجه شد که خیلی بهتر از WCF و فریم ورکهای مختلف دیگه عمل میکنه و نیازهای حافظه ای خیلی کمی داره (مناسب برای سرورهای ضعیف). اینم سایتشه که تمام توضیحات اونجا وجود داره:
http://synopse.info

1- راهنمای 1000 صفحه ایش به درد عمش میخوره .
2- انجمش هاش هم به هیچ عنوان فعال و پاسخگو نیست چون افرادی که با mORMot کم و بیش کار میکنند توش فعالیت میکنند نه سازندگان و توسعه دهندگانش ( هستن ولی فعالیت خاصی نمیکنن ) .

همون دو مورد بالا برای یک پروژه متن باز یعنی مرگ .


mORMot و WCF هر دو از درایور http.sys که یک درایور Kernel Mode هست استفاده میکنند تا Performance بهینه و رفتاری پایدار داشته باشند ، تو همون تست های جنجالی هم این دو فریمورک امتیازاتشون خیلی به هم نزدیک هستند ، علاوه بر اون WCF با اون تیم توسعه ای که من ازش دیدم الان بعد از گذشت این مدت خیلی جلوتر از تیم دره پیت mORMot باید باشه .


مطمئنید ؟! من الان برنامه ای رو میشناسم که با دلفی + Indy ساخته شده که کاربران آنلاینش به بیش از بیست و پنج هزار تا هم میرسه .
Datasnap بر پایه Indy بنا شده ولی کسی سورسش رو نخونده ببینه چه غلطی کردن ، بنابراین رو حساب اینکه اون پشت Indy هست نباید توقع قدریت و پایداری Indy رو داشت ، باید دید چقدر از این امکانات به درستی و اصولی استفاده شده ، من با همون Indy پروژه های خیلی بزرگتر از این هایی که گفتید رو دیدم ، تو این نوع کارها بیشتر از اینکه ابزار تعیین کننده نتیجه باشه ، فن هست که تعیین کننده هست :)

در آخر ، برای پروژه های بزرگ و تجاری فعلا هیچ گزینه ی مناسبی برای Delphi وجود نداره که در یک پروژه Enterprise امتحان خودشو پس داده باشه ، بنابراین فعلا تقیه کنید و از WCF استفاده کنید تا ببینیم این کانتو و تیمش چه غلطی میکنن .

:)

[یوسف زالی]

One-Way = یک طرفه
:گیج:

[tomalaki]

در آخر ، برای پروژه های بزرگ و تجاری فعلا هیچ گزینه ی مناسبی برای Delphi وجود نداره که در یک پروژه Enterprise امتحان خودشو پس داده باشه ، بنابراین فعلا تقیه کنید و از WCF استفاده کنید تا ببینیم این کانتو و تیمش چه غلطی میکنن .
:)

خب، اگرچه دوست داشتم واسه این پروژه تجاری از دلفی استفاده کنم، اما خب دیگه، باید بزنیم توی کار Net. و #C و WCF. به امید روزی که کانتو یه ابزار قدرتمند برای دلفی برای ساخت اینجور برنامه ها بسازه.
با تشکر از همه ی دوستان به خاطر راهنمایی های گرانبهایشان.

[BORHAN TEC]

سلام،

سازندگان ویندوز کجا اینو گفتن ؟ تو کل Windows Internals و کتاب هایی که در مورد ساختار ویندوز خوندم یادم نمیاد به همچین محدودیتی اشاره شده باشه .
الان که در این مورد تحقیق کردم دیدم که کسانی که این را گفته اند خواسته و یا ناخواسته دچار اشتباه شده اند و اصلاً چنین چیزی گفته نشده ولی اگر ادامه رو بخونی متوجه میشی که در هیچ کدوم از کتابهای Windows Internals به باگ داخلی سیستم عامل ویندوز اشاره نشده است. یعنی امکان نداره که نویسندگان اون کتابها هم اشتباه کنند و موردی رو ندانند؟ شایدم تا به حال کسی به این موضوع پی نبرده باشه! :متفکر:

99 % موارد این محدودیت ها به دلیل نا آشنایی برنامه نویس ها با نحوه پیاده سازی Threading ، نحوه مدیریت ، سازمان دهی ، زمان بندی و ... در سیستم عامل هست .

جالبه طبق تست هایی که الان انجام دادم متوجه شدم که این موضوع بیشتر به نسخه سیستم عامل بستگی داره.
من کد زیر را که وظیفه شمارش تردهای ایجاد شده را دارد در دو سیستم عامل مختلف تست کردم و نتایجی حاصل شد:
program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
Winapi.Windows,
System.SysUtils;

var
I: Integer;
h: THandle;
id: DWORD;

function ThreadProc: DWORD;
begin
Result := 0;
end;

begin
for I := 0 to 10000000 do
begin
h := CreateThread(nil, 0, @ThreadProc, nil, 0, id);
if (h = 0) then
begin
Break;
CloseHandle(h);
end;
end;

write('Create ', I, ' threads');
Readln;

end.
تست اول:
توضیحات:
استفاده از Windows XP x86، کامپایل برنامه توسط کامپایلر 32 بیتی و در حالت Release و با تنظیمات پیش فرض- نسخه استفاده شده XE3:
نتیجه:
تعداد ترد های ایجاد شده: 185989
========================================
تست دوم:
توضیحات:
استفاده از Windows 8 x64، کامپایل برنامه توسط کامپایلر 32 بیتی و در حالت Release و با تنظیمات پیش فرض- نسخه استفاده شده XE3:
نتیجه:
تعداد ترد های ایجاد شده: 2642
نکته جالب اینجاست که در هر بار اجرا تعداد تردهای ایجاد شده متفاوت از تستهای قبل است.
========================================
تست سوم:
توضیحات:
استفاده از Windows 8 x64، کامپایل برنامه توسط کامپایلر 64 بیتی و در حالت Release و با تنظیمات پیش فرض- نسخه استفاده شده XE3:
نتیجه:
تعداد ترد های ایجاد شده: آنقدر زیاد که قادر به اندازه گیری دقیق آن نیستم
========================================
نتیجه ای که با تست های مختلف کسب کرده ام حاکی از آن است که تمامی مواردی از این دست که میگویند تعداد تردها نهایتاً برای هر برنامه حدود 2000 عدد است اشتباه است! البته در اینجا یک نکته بسیار کلیدی وجود دارد و آن این است که در صورتی این اتفاق می افتد که ما یک برنامه 32 بیتی را در سیستم عامل 64 بیتی تست کنیم. پس برای ماکزیمم کردن کارایی توجه به این نکته ضروری است که اگر سیستم عامل سرور ما 64 بیتی است حتماً و حتماً برنامه تحت سرور ما باید با کامپایلر 64 بیتی کامپایل شود. من حتماً این مورد رو به Microsoft گزارش خواهم داد. به نظر میرسه خیلی از اختلالاتی که در تستهای مختلف به وجود میاد به خاطر همین باگ سیستم عامل ویندوز باشه. جالبه که در صفحه زیر هم اشاره ای به این مورد نشده:
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx

با توجه به نتایجی که حاصل کردم آن تست مربوط به DataSnap اگر در شرایطی که بیان کردم تست شده باشد از نظر من کاملا مردود است. در چنین شرایطی (استفاده از برنامه سرور 32 بیتی در ویندوز 64 بیتی) به دلیل باگ داخلی ویندوز تست انجام شده اعتباری ندارد. اگر دقت کنید در آن تست انجام شده بقیه زبانها به صورت VM هستند و به عنوان یک زبان کامپایلری فقط از دلفی استفاده شده است. در این تست نا عادلانه تنها فریم ورک هایی دوام می آورند که به صورت Thread Base نباشند و به صورت IOCP باشند و یا اینکه به صورت کامپایلری نباشند و به صورت VM باشند.

1- راهنمای 1000 صفحه ایش [B]به درد عمش میخوره .

این مدت خیلی جلوتر از تیم دره پیت mORMot باید باشه .

Datasnap بر پایه Indy بنا شده ولی کسی سورسش رو نخونده ببینه چه غلطی کردن

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

[Felony]

ولی اگر ادامه رو بخونی متوجه میشی که در هیچ کدوم از کتابهای Windows Internals به باگ داخلی سیستم عامل ویندوز اشاره نشده است.
باگ نیست :)

[BORHAN TEC]

باگ نیست :)
اگه باگ نیست، یک طراحی کاملاً غلط و اشتباه است، چه به صورت عمدی و یا غیر عمدی! به هر حال اگه باگ نیست چرا این مورد را من در هیچکدام از مستندات مایکروسافت ندیده ام که به صورت کاملاً واضح و روشن این مورد رو توضیح بده؟ اگر ویندوز را بنا به دلایلی اینگونه طراحی کرده اند چرا راجع به آن هیچ توضیحی نداده اند؟ یعنی تمام تست هایی که برای Performane برنامه های مختلف انجام شده همش کشکه؟ :متفکر:
در هر صورت من نمیتونم اسم این رو مزیت و قابلیت بزارم. آنچه که هست این یک نقطه ضعف بزرگ و کوتاهی از طرف Microsoft است.

[tomalaki]

شاهین خان،چرا خودت DataSnap رو تست نمیکنی؟ نتیجه اش رو هم به ما بگو.

[Felony]

باگ نیست ، به خاطر معماری سیستم عامل ها و پیشرفت اون ها هست ( در هر نسخه تعاریف و تکنولوژی های جدیدی به سیستم عامل اضافه میشه ) ، Stack و Heap اختصاص داده شده توسط کامپایلر به یک برنامه به صورت پیش فرض و ... هست .

با توجه به همون موارد بالا تفاوت طبیعی هست ، مثل این میمونه بگی لامبورگینی فلان مدل چرا آپشن هاش و امکاناتش کمتر از لامبورگینی گالاردو هست :)

فصل 5 کتاب Windows Internals که عنوان Process, Threads, Jobs رو داره و فصل 8 با عنوان Storage Management و فصل 3 از کتاب Rootkit Arsenal با عنوان Windows System Architecture میتونه دیدتون رو راجع به این موضوع تغییر بده .

در وب سایت ها هم هیچ وقت به این مباحث پرداخته نمیشه چون کسی به این تعداد Thread احتیاج پیدا نمیکنه ، کمپانی هایی هم که احتیاج پیدا میکنن اصولا برای یک پروژه درست و درمون بهش نیاز دارن و اصولا پروژه های درست و درمون کمپانی ها برنامه نویسان درست و درمون داره که با این موارد آشنایی دارن، برنامه نویسانی هم که با این موارد ( Thread Management و Memory Management ) آشنایی دارن مشکلی براشون پیش نمیاد ، همونطور که نرم افزارهایی خیلی بزرگی وجود دارند که روی سیستم عامل های مختلف منجمله Windows Server پردازش های خیلی خیلی وحشتناک رو مثل آب خوردن انجام میدن ( برنامه های شبیه ساز صد ، Data Mining و ... )

مثل این میمونه بگی چرا خیابان های ایران گنجایش 200 میلیون ماشین رو نداره ، خوب معلومه ؛ چون نیازی به این گنجایش نداره ، حالا اگر دوست دارید خر شهردار و ... رو بگیریم ببینم چرا خیابونهامون همچین گنجایشی نداره :)

[BORHAN TEC]

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

با توجه به همون موارد بالا تفاوت طبیعی هست ، مثل این میمونه بگی لامبورگینی فلان مدل چرا آپشن هاش و امکاناتش کمتر از لامبورگینی گالاردو هست :)
من این مورد رو با ویندوز 7 نسخه های 32 بیتی و 64 بیتی هم تست کردم و نتیجه همون چیزی بود که قبلاً گفتم. یعنی ویندوز 7 نسخه 32 بیتی لامبورگینی فلان مدل است و نسخه 64 بیتی لامبورگینی گلاردو! این حرفت توی کت من نمیره!
میگی کمپانی های بزرگ برنامه نویسان بزرگ دارند. یعنی برنامه نویسانی که بر روی دلفی کار می کنند برنامه نویسان کوچکی هستند و به این دلیله که تا به حال هیچکدام از آن ها به این موضوع پی نبرده اند. توی اون تست انجام شده برنامه نویسان بزرگی کامنت گذاشته اند ولی چرا بازم هیچکدومشون به این موضوع پی نبرده اند!

در وب سایت ها هم هیچ وقت به این مباحث پرداخته نمیشه چون کسی به این تعداد Thread احتیاج پیدا نمیکنه
اگه اینطوره پس چرا توی وبلاگ مایکروسافت هم که دقیقاً به همین موضوع پرداخته اشاره ای به این مسئله نشده؟
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx

به هر حال با تمام احترامی که بهت قائلم و خودتم خوب میدونی نمیتونم نظراتت در این مورد خاص رو بپذیرم.

[Felony]

من این مورد رو با ویندوز 7 نسخه های 32 بیتی و 64 بیتی هم تست کردم و نتیجه همون چیزی بود که قبلاً گفتم. یعنی ویندوز 7 نسخه 32 بیتی لامبورگینی فلان مدل است و نسخه 64 بیتی لامبورگینی گلاردو! این حرفت توی کت من نمیره!
الان من دارم سر موضوعی بحث میکنم که به نظر شما اطلاعات خاصی ازش ندارید و بر اساس یکسری شواهد غیر مستند دارید روی موضع پافشاری میکنید ، بله که 32 بیتی و 64 بیتی زمین تا آسمون معماریشون با هم فرق میکنه .

حتما اون فصل 8 از Windows Internals رو مطاله کن ، بعد این فصل همین کتاب رو تو نسخه های مختلف کتاب با هم یه مقایسه کلی بکن ببین چقدر فرق میکنن .

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

[BORHAN TEC]

الان من دارم سر موضوعی بحث میکنم که به نظر شما اطلاعات خاصی ازش ندارید و بر اساس یکسری شواهد غیر مستند دارید روی موضع پافشاری میکنید ، بله که 32 بیتی و 64 بیتی زمین تا آسمون معماریشون با هم فرق میکنه .ماهان جان، مثل اینکه کلاً منظورم رو بد رسوندم و کامل منظورم رو متوجه نشدی. سعی می کنم که منظورم رو بهتر برسونم. من این رو میدونم که ویندوز 64 بیتی با 32 بیتی فرق داره. از نظر میزان توانایی در آدرسدهی حافظه و خیلی از موارد دیگه.

اگه به اون آزمایشی که انجام دادم دقت کنی متوجه میشی که یک برنامه 32 بیتی هم در WinX64 و هم در WinX32 اجرا شده است. نکته اصلی اینجاست که با اجرای برنامه در WinX64 کارایی برنامه صدها و یا شاید هزاران برابر نسبت به اجرایش در ویندوز 32 بیتی کاهش پیدا کرده است! این مسئله واقعاً برای من عجیب است! توجه داشته باش سیستمی که من بر روی آن ویندوز 32 بیتی نصب کرده ام خیلی ضعیفتر از سیستمی است که بر روی آن سیستم عامل 64 بیتی نصب کرده ام. در چنین شرایطی انتظار میرود که اجرای برنامه 32 بیتی در یک ویندوز 64 بیتی همان کارایی را داشته باشد که در اجرا در ویندوز 32 بیتی دارد و اگر هم قرار است اختلافی وجود داشته باشد نباید زیاد باشد. این که کارایی برنامه صدها و شاید هزاران برابر کاهش پیدا کنه قابل قبول نیست و وجود یک مشکل بسیار اساسی در سیستم عامل ویندوز را نشان میدهد!

همانطور که مشخص است ویندوز 64 بیتی در اجرای برنامه های 32 بیتی Performance خیلی پایینی داره که تمام مشکل همینجاست!:متفکر: پس به عنوان یک نتیجه و یک نکته بسیار کلیدی باید به این مورد توجه کنیم:

"اگر سیستم عاملی که می خواهیم برنامه تحت سرورمان را در آن اجرا کنیم 32 بیتی باشد، باید برنامه خود را با کامپایلر 32 بیتی کامپایل کنیم(این مورد کاملاً بدیهی است چرا سیستم عامل 32 بیتی توانایی اجرای برنامه های 64 بیتی را ندارد). در شرایطی دیگر، اگر سیستم عامل مربوطه 64 بیتی بود باید برنامه تحت سرور را با کامپایلر 64 بیتی کامپایل کنیم و اگر در این وضعیت برنامه خود را با کامپایلر 32 بیتی کامپایل کنیم و بخواهیم آن را در سیسم عامل 64 بیتی اجرا کنیم نه تنها کارایی ای معادل اجرا در سیستم عامل 32 بیتی را نداریم، بلکه کارایی ای معادل صدها و یا شاید هزاران برابر کمتر از آن را خواهیم داشت" و به عنوان یک نتیجه کلی استفاده از برنامه سرور 32 بیتی در سیستم عامل 64 بیتی ویندوز بدترین کارایی ممکن را خواهد داشت.:چشمک:

بعد از نکته ذکر شده توجه به این نکته ضروری است که اگر بخواهیم توانایی ساخت تعداد تردهای برنامه را افزایش دهیم می توانیم حافظه Stack برنامه را کم کنیم. :چشمک:

1- راهنمای 1000 صفحه ایش به درد خودش میخوره .از نظر من mORMot راهنمای خوبی داره. توضیحات اصلی و مثالها در حدوداً 300 صفحه اول هست و بقیه هم کلاسها و متدهای مربوطه رو کامل توضیح داده.

2- انجمش هاش هم به هیچ عنوان فعال و پاسخگو نیست چون افرادی که با mORMot کم و بیش کار میکنند توش فعالیت میکنند نه سازندگان و توسعه دهندگانش ( هستن ولی فعالیت خاصی نمیکنن ) .کاملاً اشتباه می کنید. آدرس فرومش اینه:
http://synopse.info/forum
بد نیست که دوباره سری بهش بزنید. شخصی که در اونجا با نام کاربری ab میبینید جزو سازندگان mORMot است و میبینید که در اکثر تاپیکها به صورت منظم به سوالات کاربران پاسخ داده است و هیچ سوال بی جوابی وجود ندارد.

[Felony]

اول راجع به mORMot :


نظر من mORMot راهنمای خوبی داره. توضیحات اصلی و مثالها در حدوداً 300 صفحه اول هست و بقیه هم کلاسها و متدهای مربوطه رو کامل توضیح داده.

کاملاً اشتباه می کنید. آدرس فرومش اینه:
شما چقدر روی این mORMot کار کردید ؟ من 2 هفته تمام وقتم رو راجع به تحقیق درمورد توانایی های این فریم ورک و مزایا ومعایبش گذاشتم ، اون تجربه من بود ، میتونید تست کنید .


بد نیست که دوباره سری بهش بزنید. شخصی که در اونجا با نام کاربری ab میبینید جزو سازندگان mORMot است و میبینید که در اکثر تاپیکها به صورت منظم به سوالات کاربران پاسخ داده است و هیچ سوال بی جوابی وجود ندارد.
اولا که به تمام سوالات جواب نداده و مشکلات عدیده ای هستند که باگ محسوب میشند و دارن روش کار میکنند ،دوما همون که اون آقای ab فقط اونجا جوابگو هست یعن بندازش دور ، من دقیقا یکی از دلیلم برای بیخیال شدن از استفاده از این فریمورک در یک پروژه Enterprise همین بود ، اومدیم و من شروع کردم با این mORMot پروژه و نوشتم و این آقای ab غیبش زد ، چه کنیم؟!

شما هر طور بخوای حساب کنی فعلا WCF خلی ، خیلی جلوتر هست .


اگر سیستم عاملی که می خواهیم برنامه تحت سرورمان را در آن اجرا کنیم 32 بیتی باشد، باید برنامه خود را با کامپایلر 32 بیتی کامپایل کنیم(این مورد کاملاً بدیهی است چرا سیستم عامل 32 بیتی توانایی اجرای برنامه های 64 بیتی را ندارد). در شرایطی دیگر، اگر سیستم عامل مربوطه 64 بیتی بود باید برنامه تحت سرور را با کامپایلر 64 بیتی کامپایل کنیم و اگر در این وضعیت برنامه خود را با کامپایلر 32 بیتی کامپایل کنیم و بخواهیم آن را در سیسم عامل 64 بیتی اجرا کنیم نه تنها کارایی ای معادل اجرا در سیستم عامل 32 بیتی را نداریم، بلکه کارایی ای معادل صدها و یا شاید هزاران برابر کمتر از آن را خواهیم داشت" و به عنوان یک نتیجه کلی استفاده از برنامه سرور 32 بیتی در سیستم عامل 64 بیتی ویندوز بدترین کارایی ممکن را خواهد داشت.

این جواب :


In a 64-bit environment old 32-bit application run owing to Wow64 subsystem. This subsystem emulates 32-bit environment by means of an additional layer between a 32-bit application and 64-bit Windows API. In some localities this layer is thin, in others it’s thicker. For an average program the productivity loss caused by this layer is about 2%. For some programs this value may be larger. 2% are certainly not much but still we have to take into account the fact that 32-bit applications function a bit slower under a 64-bit operation system than under a 32-bit one.

Compiling of a 64-bit code not only eliminates Wow64 but also increases performance. It’s related to architectural alterations in microprocessors, such as the increase in number of general-purpose registers. For an average program the expected performance growth caused by an ordinary compilation is 5-15%. But in this case everything depends upon the application and data types. For instance, Adobe Company claims that new 64-bit "Photoshop CS4" is 12% faster than its 32-bit version.

و توضیحات گهربار مایکروسافت که همون کلمه Emulate فصل الخطاب هست :

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384249(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384274(v=vs.85).aspx

همه چیز خیلی ، خیلی واضحه ، Ok ؟

با این تفاسیر من بارها تو نت این همچین سوالاتی دیدم از انجمن های ایرانی مثل شبگرد و ... بگیر تا انجمن های گردن کلفت مثل Stack overflow و Kernelmode.info ولی هیچ کس جواب درست و درمونی به این موضوع نداده ( با اینکه به نظر من هیچ پیچیدگی خاصی نداره ، همه چیز واضحه ) ، حالا نمیدونم چرا ، ولی اگر راضی نشدی برای شما و هر شخص دیگه ای من تا صبح دلیل و مدرک برات میارم که این موضوع باگ نیست و به دلیل ساختار و تعاریف و تکنولوژی های مختلف در نسخه های مختلف ویندوز هست .

این تاپیک علاقمو به Windows Internals چند برابر کرد ، باید نسخه جدید رو شروع به خوندن کنم ، ممنون بابت این جوی که دادید D:

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

یا حق .

[tomalaki]

آقا من معذرت میخوام! اصلا پروژه رو بیخیال میشم میرم سیگارفروشی میزنم :لبخند:

[BORHAN TEC]

به عنوان آخرین پستم توی این تاپیک: :خجالت:

این تاپیک علاقمو به Windows Internals چند برابر کرد ، باید نسخه جدید رو شروع به خوندن کنم ، ممنون بابت این جوی که دادید D:
خوشحالم که تونستم بهت جو بدم و همچنین تشکر می کنم بابت توضیحات خوبی که دادی. من هم علاقه مند شدم که این کتاب رو بخونم تا ببینیم چطوری تونسته این کاهش کارایی به این میزان بالا رو ماست مالی کنه؟! :لبخند: تمام حرفهات رو قبول دارم ولی اینکه کارایی برنامه 32 بیتی با emulate کردن چند صد برابر و یا شاید چند هزار برابر کاهش پیدا کنه رو نه! چه توی Windows Internals بگه، چه بیل گیتس بگه و یا هر شخص دیگه ای! اگه این کارایی به ده برابر کاهش پیدا می کرد باز هم قابل قبول بود ولی در واقعیت این مقدار بسیار وحشتناک است که مشخص می کند که این emulator مشکلات اساسی دارد و باید روی Performance آن خیلی بیشتر از این کار شود!

آقا من معذرت میخوام! اصلا پروژه رو بیخیال میشم میرم سیگارفروشی میزنم
این کار بد آموزی داره، بهتره بریم سبزی فروشی بزنیم. به صورت سیار و با وانت! :لبخند:

[دلفــي]

چرا از Intraweb يا همون VCL for the Web استفاده نمي كني ، به راحتي ميتوني از Sessionها و ساير كنترلرهاي موجود براي كنترل كاربران استفاده كني !

[BORHAN TEC]

چرا از Intraweb يا همون VCL for the Web استفاده نمي كني ، به راحتي ميتوني از Sessionها و ساير كنترلرهاي موجود براي كنترل كاربران استفاده كني !قرار بود که پست قبلی آخرین پستم توی تاپیک جاری باشه ولی چه کنم که این بحث برای من هم همیشه یکی از چالشهای اساسی بوده و هنوز هم هست و موضوع بحث یه جورایی من رو قلقلک میده!
این که DataSnap توانایی کنترل 250 کاربر همزمان را دارد که به نظرم امکان پذیره. البته در این خصوص توجه به نکات بیان شده در پست 28 ضروری است. توجه داشته باشید که در این مورد هم عوامل دیگری هم دخیل است، مثل قدرت سرور، پهنای باند اینترنت، ساختار دیسک سخت (اسکازی یا موارد دیگه) و ... . در همین رابطه قرار بود مدتی قبل پروژه ای را با همکاری یک شرکت شروع کنیم و همین موضوع یکی از چالشهای اساسی ما بود که در این خصوص سوالی را در SO پرسیدم:
http://stackoverflow.com/questions/13211613/is-datasnap-optimized-for-responding-to-more-than-1k-users-at-the-same-time
متاسفانه این پروژه بنا به دلایلی از جمله تحریم به حالت تعلیق درآمد و نتونستم تجاربی در این خصوص در دنیای واقعی کسب کنم. :ناراحت: چیزی که ما در ادامه تاپیک جاری پیش گرفتیم مربوط به کنترل کاربران بیشتری است (شاید بیش از چند هزارتا) و نه 250 تا. :لبخندساده:

در خطاب به ماهان عزیز:

دوما همون که اون آقای ab فقط اونجا جوابگو هست یعن بندازش دورنمیدونم قبول داری یا نه ولی به نظر من پشتیبانی از Indy هم در آقای Remy Le Bua خلاصه شده است. این رو خودت بهتر می دونی! توی Forum2.Atozed هم اون کسی که با نام gambit47 میبینی همین آقای Remy Le Bua هست و شخص دیگری نیست. به عبارتی دیگه در همه جاهای مهم اینترنت مثل SO و Atozed و Delphi Pages و Forum.Embarcadero همین ایشون هستند که به بیشتر مسائل مربوط به Indy پاسخ می دهند. پس این حرفت تا حدود زیادی منطقی نیست!

[tomalaki]

خب بیاین ادامه بدیم تا به یه نتیجه برسیم. بالاخره اپلیکیشن ها دارن به سمت برنامه نویسی سرویسگرا پیش میرن. الان شما برنامه های اندوید و iOS و حتی برنامه های ویندوز رو میبینیم که دیگه اطلاعات فقط از یک پایگاه داده در یک سرور در یک یا چندین جای دنیا میاد. نمونه اش پروژه ی خودم. یک پروژه تجاری هست که قرار هست فعلا 200 تا 250 تا کلاینت داشته باشه. اونم فقط توی سطح شهر خودمون. اگه قرار باشه این پروژه رو به سایر شهرهای دیگه بسط بدیم شاید به همون 1000تا برسه.

مطمئنا من نتیجه پروژه رو اینجا میذارم تا شاید کمک کنه. البته فعلا بقیه ی برنامه نویس ها رفتند عید دیدنی فعلا پروژه متوقف هست.

[BORHAN TEC]

اگه قرار باشه این پروژه رو به سایر شهرهای دیگه بسط بدیم شاید به همون 1000تا برسه.
در این صورت باید از تکنیکهای Load Balancing استفاده کنید تا ترافیک را بین سرورهای مختلف تقسیم کنید. در مورد DataSnap قدیما آقای Andreano Lanusse توضیحاتی رو ارائه داده اند. در کامل کردن توضیحات ایشون باید بگم که در قسمت پایگاه داده هم باید از Replication استفاده کنید که در مورد پایگاه داده Firebird میتونید از ابزار غیر رایگانی مثل IPReplicator استفاده کنید، چون فعلاً به صورت ذاتی این قابلیت رو نداره.
البته به نظر من استفاده از سرورهای مختلف بیشتر به دلیل محدودیتهای مربوط به خواندن و نوشتن بر/از روی دیسک سخت است(البته فقط این نیست و دلایل دیگری هم دارد مثل بالابردن تحمل خطا و ...). اگر در انتخاب دیسک سخت و تکنولوژی به کار رفته در آن توجه بیشتری شود ممکن است که بیشتر مشکلات حل شوند. خلاصه در این مسئله باید موارد متعددی مورد توجه قرار بگیرد و فقط بحث نرم افزاری نیست.

امیدوارم که این پست واقعاً آخرین پستم توی این تاپیک باشه! :لبخندساده:

[tomalaki]

خب اینم از معماری منطقی DataSnap
101991

[Felony]

نمیدونم قبول داری یا نه ولی به نظر من پشتیبانی از Indy هم در آقای Remy Le Bua خلاصه شده است. این رو خودت بهتر می دونی! توی Forum2.Atozed هم اون کسی که با نام gambit47 میبینی همین آقای Remy Le Bua هست و شخص دیگری نیست. به عبارتی دیگه در همه جاهای مهم اینترنت مثل SO و Atozed و Delphi Pages و Forum.Embarcadero همین ایشون هستند که به بیشتر مسائل مربوط به Indy پاسخ می دهند. پس این حرفت تا حدود زیادی منطقی نیست!
معماری و مهندسی ، Documentation و Sample ها و تعداد کاربران خبره Indy رو با mORMot مقایسه میکنی ؟! شاید اگر از تولد mORMot چندین سال گذشته بود و تعداد زیادی کاربر داشت و آدم از توسعش مطمئن بود ( Indy مجبوره توسعه پیدا کنه چون با Embarcadero قرارداد داره ) همچین حرفی نمیزد ، ولی در حال حاظر مقایسه جالبی نیست !

خود شما حاظری یک پروژه Enterpeise رو الان با mORMot شروع کنی و توسعه بدی و تحویل کارفرما بدی و بعدش هم پشتیبانیش کنی ؟! اگر بله تو تصمیمت تجدید نظر کن ، پروژه های Enterprise جای این نوع ریسک ها نیست .

[MohsenB]

سلام

بروجچ کافیه کل کل ، شاهین جان این یه باگ هست ، ماهان این باگ نیست .
به قول یکی از دوستان اون زبانی قدرت داره که بیشتر بلدی . ممکنه یه نفر با وی بی 6 یه برنامه بنویسه که یه نفر دیگه با دلفی جدید نتونه بنویسه . البته و صد البته استفاده از تجربیات دیگران و همچنین نگاهی به سابقه و سطح استفاده از یک ابزار خیلی مفیده و از طرفی هر ابزاری هم باید از یه جایی شروع بشه ...
یادمه تو این کتاب Windows Internals اشاره به اینکه بچه های خوبی باشید و مطلب علمی جدیدی به هم یاد بدید نشده بود :لبخند:

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

این پست هم آخرین پستم تو این تاپیک نیست

موفق باشید

[Mask]

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

[tomalaki]

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

[Delphi_Tips]

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

ببخشيد منظور از delay در indy چيه؟ indy يك كتابخانه سوكت thread based , Blocked mode هست يعني تا اطلاعات كامل توسط سوكت دريافت نشه كنترل به برنامه برنميگرده براي كار با indy بايد به كار با thread ها هم مسلط باشيد اونوقط ميبينيد كه اين كتابخونه تا جايي كه تعداد thread ها اجازه بده بهترن كيفيت رو ارايه ميده و كاملا stable هست و ميشه براي پروژه هاي بزرگ هم روش حساب كرد

ولي هنوزم متوجه نشدم منظور از delay دقيقا چي بوده؟

[Mask]

ببخشيد منظور از delay در indy چيه؟ indy يك كتابخانه سوكت thread based , Blocked mode هست يعني تا اطلاعات كامل توسط سوكت دريافت نشه كنترل به برنامه برنميگرده براي كار با indy بايد به كار با thread ها هم مسلط باشيد اونوقط ميبينيد كه اين كتابخونه تا جايي كه تعداد thread ها اجازه بده بهترن كيفيت رو ارايه ميده و كاملا stable هست و ميشه براي پروژه هاي بزرگ هم روش حساب كرد

ولي هنوزم متوجه نشدم منظور از delay دقيقا چي بوده؟
خوشبختانه هم به indy مسلط هستم هم به تردها.
در پروژه ای که برای مثال عرض کردم : قرار بود برنام ای شبیه به IDM بنویسم. برای این منظور تعداد دلخواه کانکشن میساختم و هر کانکشن هم در ترد مخصوص به خودش در حال دانلود از سرور بود.
زمانی که سرور درگیر بود و نمیتونست با سرعت زیاد دیتا رو بفرسته ، برنامه منتظر میموند تا برادر ایندی همون قضایای بهینه سازی و حتی UseNagle رو رعایت کنه.
واسه همین زمان دانلود کانکشن ها زیاد میشد. بنا بر این مجبور به استفاده از سوکت به طور مستقیم شدم. که دقیقا همین سناریو بدون هیچ افت سرعتی ، حتی بهتر از IDM پیاده شد.

[Delphi_Tips]

خوشبختانه هم به indy مسلط هستم هم به تردها.
در پروژه ای که برای مثال عرض کردم : قرار بود برنام ای شبیه به IDM بنویسم. برای این منظور تعداد دلخواه کانکشن میساختم و هر کانکشن هم در ترد مخصوص به خودش در حال دانلود از سرور بود.
زمانی که سرور درگیر بود و نمیتونست با سرعت زیاد دیتا رو بفرسته ، برنامه منتظر میموند تا برادر ایندی همون قضایای بهینه سازی و حتی UseNagle رو رعایت کنه.
واسه همین زمان دانلود کانکشن ها زیاد میشد. بنا بر این مجبور به استفاده از سوکت به طور مستقیم شدم. که دقیقا همین سناریو بدون هیچ افت سرعتی ، حتی بهتر از IDM پیاده شد.

خوب به نظر بنده اين نقطه ضعف indy حساب نميشه ! برنامه نويس بايد با توجه به نوع پروژه از ابزار موجود با توجه به تخصصشون در جاي درست استفاده كنه كه شما هم به همين نتيجه رسيديد و از روش ديگه اي استفاده كرديد. هرچند به نظر من دانلودر رو هم ميشه بدون delay به قول شما با همين indy پياده كرد.

در مورد محصولات synopse من هيچوقت ديد خوش بينانه نداشتم و ندارم. هر وقت به سايتش سر ميرنم حس ميكنم اونجا اصلا پدر و مادر و صاحب نداره هر پروژه براي خودش رها شده معلوم نيست روي چي متمركزن

براي Blocked Socket بهترين كتابخونه indy و براي NoneBlocked بهترين كتابخونه ICS هست و امتحانشو توي خيلي از پروژه ها پس داده. براي مورد دانلودر هم در يكي از برنامه هاي معروف از ICS استفاده شده بود كه اسمش الان خاطرم نيست.

البته فريموركهاي تجاري بزرگي هست كه قيمت بالايي دارن و ميشه ازشون استفاده كرد

بحث به سمت سوكتها رفت اميدوارم در موضوع اصلي بحث اختلال ايجاد نكرده باشم.

[tomalaki]

البته فريموركهاي تجاري بزرگي هست كه قيمت بالايي دارن و ميشه ازشون استفاده كرد


میشه اگه در ذهن دارید چند تا از این فریمورک ها رو نام ببرید؟

[joker]

در مورد تعداد 2000 ترد در نرم افزارها يه زماني من اين مشكل را داشتم (http://www.shabgard.org/forums/showthread.php?24184) يعني با كامپايلر دلفي 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 هزارتا بسنده كردم :)

[tomalaki]

جوکر جان، این برنامه ای که توی اون فروم گذاشتی با کامپایلر 32 بیتی کامپایل شده؟ میشه سورس برنامه رو بذاری تا من با 64 بیتی کامپایل کنم تا ببینم نتیجه چی میشه؟
من با ویندوز 64 بیتی 6000 تا بیشتر نتونستم بسازم!

[tomalaki]

من یه برنامه خیلی ساده درست کردم و سرور DataSnap رو توی یک VPS گذاشتم، دستور اول سه ثانیه طول کشید، اما بقیه اش توی کمتر از یک ثانیه جواب میده. جریان چیه؟ کش میکنه؟

[BORHAN TEC]

دلیلش اینه که برقراری ارتباط اولیه طول میکشه. اگه ارتباط برقرار شده باشه دیگه زمانی صرف برقراری اتصال نمیشه.

جریان چیه؟ کش میکنه؟
کش کردن اونطوری نیست. اگر منظورت کش کردن داده ها باشه باید از این روش استفاده بشه:
http://www.andreanolanusse.com/en/caching-data-on-datasnap-server/

[tomalaki]

دلیلش اینه که برقراری ارتباط اولیه طول میکشه. اگه ارتباط برقرار شده باشه دیگه زمانی صرف برقراری اتصال نمیشه.

کش کردن اونطوری نیست. اگر منظورت کش کردن داده ها باشه باید از این روش استفاده بشه:
http://www.andreanolanusse.com/en/caching-data-on-datasnap-server/
عجب! با وجود اینکه سرور توی آمریکا هست خوب توی سه ثانیه اتصال برقرار میشه. حالا سرور ما که قراره وطنی باشه. تازه VPS هم رم 256 هست. که البته فکر نکنم خیلی به سرعت اتصال مرتبط باشه. با این وجود، خوشمون اومد :لبخند: الان یه برنامه چت گروهی با استفاده از Delphi Lab میسازم بریم حالش رو ببریم.

[BORHAN TEC]

البته به این نکته هم توجه داشته باش که اگه به جای Http از TCP استفاده کنی سرعت تا حدودی بهتر میشه و توصیه میشه که در صورتی که تعداد کاربران همزمان زیاده از TCP بجای HTTP استفاده بشه. :چشمک::چشمک::چشمک::چشمک::چشمک:
در ضمن توجه داشته باش که DataSnap تا حدود بسیار زیادی از dbExpress استفاده می کنه. اگه بشه کاری کرد که به جای اون از FireDAC استفاده بشه احتمال داره که سرعت کار تا 20% افزایش پیدا کنه. البته این مورد فعلاً برای من در حد تئوری است و دارم بر روی آن کار می کنم که ببینم امکان داره یا نه؟! اگر تونستم این کار را بکنم نتیجه رو در همین تاپیک قرار می دهم!:متفکر: این مورد هم به خاطر اینه که تست ها نشان داده اند که FireDAC تقریباً 25% از dbExpress سریعتر است. به نظرم اگر تیم توسعه دلفی کاری کنند که در مورد DataSnap غیر از استفاده از dbExpress انتخابهای دیگری هم داشته باشیم خیلی خوب میشه. :متفکر:

[tomalaki]

البته به این نکته هم توجه داشته باش که اگه به جای Http از TCP استفاده کنی سرعت تا حدودی بهتر میشه و توصیه میشه که در صورتی که تعداد کاربران همزمان زیاده از TCP بجای HTTP استفاده بشه. :چشمک::چشمک::چشمک::چشمک::چشمک:

آره، از TCP/IP استفاده کردم. البته در حد خیلی مبتدی، همون چیزایی که توی دلفی لبراتور بود. نه تیونی، نه متدهای حرفه ای، البته یه کوچولو تغییرش دادم.

[tomalaki]

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

[tomalaki]

به نظرم اگر تیم توسعه دلفی کاری کنند که در مورد DataSnap غیر از استفاده از dbExpress انتخابهای دیگری هم داشته باشیم خیلی خوب میشه.
به نظر من Embarcadero اگه پروژه mORMot رو بهینه کنه و روش کار کنه و توسعه اش بده و به عنوان یک کامپوننت بده بیرون خیلی بهتر خواهد شد.

[بهروز عباسی]

الان داشتم توی وبلاگ حاج مارک گشت میزدم که چشم به این عنوان افتاد "Pushing the Limits of Windows: Processes and Threads (http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx)" بعد که بازش کردم ببینم چه خبره دیدم این بحث دقیقاً همون چیزیه که قبلاً اینجا (توی این تاپیک) سرش جنگ بود (محدودیت در تعداد Thread های برنامه های 32بیتی ) خودم هنوز کامل نخوندمش ولی اگه بازم کسی با این موضوع مشکل داشت این مطالب رو بخونه مشکلی هم بود حاج Mark مثل شیر توی وبلاگش پاسخ میده:بامزه: