ملاحظاتی بر پروژه های Client / Server

سلام.
- - - - - --------------
در هنگام نوشتن پروژه های Client / Server موارد متعددی را جهت بهینه شدن عملکرد برنامه و حتی جلوگیری از هنگ کردن سیستم و .... بایستی در نظر بگیریم که عموما در پروژه های DESKTOP اهمیت چندانی ندارند و برای امثال من که پس از نوشتن چند تا پروژه ی DESKTOP ، هوس میکنند که سراغ Client / Server بروند ، میتواند مفید فایده باشد و البته حیاتی .... حالا من کم کم چیزهایی که یاد میگیرم را مینویسم ... بقیه ی اساتید که " تجربه " ی بسیاری در این زمینه دارند هم همکاری کنند تا مجموعه ی خوب و ارزشمندی گردآوری کنیم .. ان شا الله .....
------------------------------------------------------------------------

::..به حداقل رساندن تعداد اتصالات به سرور ..::
بازنگهداشتن کانکشن های غیر لازم به سرور ، اولین چیزی است که باید از آن دوری جست که هم باعث کند شدن برنامه میشود و هم منابع سرور را هدر میدهد .

::.. چه باید کرد ؟ راه اول ..::
از TDatabase استفاده کنید .
برای کل پروژه ، از یک TDatabase استفاده کنید ...

1- یک کامپوننت TDatabase بر روی فرم اصلی برنامه و یا ماژول آن قرار دهید .
2- خاصیت AliasName را به BDE Alias مربوطه تنظیم کنید .
3- خاصیت DatabaseName را به نامی تنظیم کنید که بصورت پابلیک میخواهید در کل پروژه به آن رجوع کنید .
4- وقتی از TDataset - مثل TTable , TQuery , TStoredProc - استفاده میکنید ، بجای اینکه برای آنها از BDE Alias استفاده کنید ، از DatabaseName ی که برای TDatabase انتخاب کرده بودید استفاده کنید .

اکنون وقتی یک TDataset که به روش فوق تنظیم شده باشد باز میشود ، از کانکشنی که کامپوننت TDatabase فراهم کرده استفاده میکند و لازم نیست که خودش یک کانکشن جدید ایجاد کند .

تذکر >> خاصیت KeepConnection در TDatabase بصورت پیش فرض True‌هست بنابراین با Close کردن TDatabase ، کانکشن به سرور قطع نمیشود . در عوض ، وقتی پروژه تان را ذخیره میکنید و از دلفی خارج میشوید ، وضعیت کانکشن آن ، همراه با پروژه ذخیره میشود و وقتی که دوباره پروژه را باز میکنیم ،‌ بلافاصله پسورد اتصال به دیتا از ما خواسته میشود .

::.. چه باید کرد ؟ راه دوم ..::

از طریق Control Panel ، وارد BDE Administrator‌ شوید ، یک خاصیت SQLPASSTHRU MODE داره که میتونه یکی از سه مقدار NOT SHARED , SHARED AUTOCOMMIT , SHARED NOAUTOCOMMIT را داشته باشه . اگر روی یکی از مقادیر SHARED تنظیمش کنید ، کمک میکنه که تعداد اتصالات بهینه باشه چونکه به BDE اجازه میده که کانکشن هایی که توسط برنامه ی شما ساخته میشه را بصورت SHARE کند و ....

:چشمک:

برای Sql Server با استفاده از Ado هم بگو :)

جداول Paradox ... حداکثر 2 گیگا بایت ظرفیت دارند ... ولی معمولا وقتی حجمشان به 300 مگا بایت میرسد هم مشکلات چشمگیر کاهش سرعت و خطا در ایندکسها ، شروع به نمایان شدن میکند .

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

در عوض ، Sql Server از روش Optimistic Locking استفاده میکند . که اجازه میدهد چندین کاربر بطور همزمان بتوانند بر روی یک رکورد کار کنند ... و تصمیم گیری که نهایتا با این رکوردی که توسط کاربران مختلف آپدیت شده ، چگونه رفتار کند را تا زمان ارسال رکورد از طرف کاربر به سرور ، به تعویق می اندازد .

گفته شده که در دیتابیسهای بزرگ ، عملکرد یک Table میتواند تا 10 برابر هم کند تر از Query باشد .

فراموش نکنیم که Tableها ، ابتدا Scheme جدول مورد نظر را از سرور درخواست میکنند ... سپس همه رکوردهای موجود در آن جدول را به روی کلاینت منتقل میکنند ... حتی اگر عبارتی هم برای Filter کردن Table نوشته باشید ، کمکی به سرور و ترافیک شبکه نخواهید کرد زیرا فیلترینگ برای Table ها ، روی کلاینت انجام میگیرد و نه روی سرور .

Query ها .. بر خلاف Table ها ... نیازی به درخواست Scheme ندارند . ( فعلا 1-0 به نفع Query ) . علاوه بر آن ، عبارت فیلترینگی که در شرط WHERE مینویسیم ، بر روی سرور اجرا میشود و فقط نتیجه آن ، به کلاینت ارسال میشود . مثلا ممکن است که فقط لازم باشد 10 رکورد از جدولی حاوی 5000 رکورد به کلاینت منتقل شود . ( حالا 2-0 به نفع ً Query ) ....

همانطور که در پست قبلی خواندیم ، Table ها ابتدا Schema جدول مورد نظر را به کلاینت منتقل میکنند و این کار را هر بار که به سرور متصل میشوند انجام میدهند که باعث افت سرعت است ...

میتوان این مشکل را برطرف کرد .... بایستی که Schema های Table ها را هر کلاینت برای خودش Cache کند .

برای این کار ؛ در BDE Administrator ، وارد Configuration دیتابیس مورد نظر خود شوید و سه مورد
SCHEMA CHACHE DIR: محلی که کش ها ذخیره خواهند شد .
SCHEMA CHACHE SIZE : تعداد جداولی که شمای آنها ، کش خواهد شد .
SCHEMA CHACHE TIME : تعداد ثانیه هایی ست که کش ها نگه داری خواهند شد . صفر ثانیه یعنی اصلا کش نکن . منفی یک ثانیه ، یعنی تا هنگامی که دیتابیس بسته نشده ، کش ها را نگهداری کن و سایر اعداد ، نشاندهنده ثانیه نگهداری کش هستند .

را تنظیم کنید .-

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

تذکر 2 :: در صورت تمایل به استفاده ، فراموش نکنیم که ENABLE SCHEMA CACHE را هم ، True کنیم !!

فراموش نکنیم که حتی یک دستور تک خطی Table1.Last هم باعث میشود که کل رکوردهای جدول ، از سرور به کلاینت منتقل شوند .... در استفاده از آنها ، سخاوتمندانه عمل نکنیم .

Table ها بصورت کرسورهای دوطرفه BiDirectional Cursor عمل میکنند . در حالیکه در Query ها قادر به انتخاب/ عدم انتخاب حالت UniDirectional هم هستیم . تا اینجای کار خوب است .... لطفا با True کردن Request Alive در Query ها ... کار را خراب نکنید . !! چون در این صورت ، از این لحاظ Query معادل Table عمل خواهد کرد .

در عوض از UpdateSql استفاده کنیم.

اگر از خاصیت Filter همراه با Query استفاده کنیم ، متاسفانه باعث خواهد شد که عمل فیلترینگ بصورت لوکال و توسط BDE انجام شود ( و نه Sql Server ) ... که باعث میشود کل رکوردهای جدول به کلاینت منتقل شود .

چنین کاری ، فقط هنگامی توجیه دارد که کاربر ، شرط فیلتر را اغلب عوض کند که برای Queryها باعث میشود که فقط فیلتر روی کلاینت صورت گیرد و برای Table ها ، باعث میشود که هربار ، BDE ، یک عبارت پرس و جوی جدید را اجرا کند.

خیلی خوبه
فقط اگه ممکنه در مورد ADO هم بگین
ممنون

وضعیت ترافیک خطوط شبکه حالت client / server در مقایسه باحالتی که همان application را روی سرور نصب و share کنیم به چه صورتی است ( با در نظر داشتن مزیت حالت دوم که در آن نیازی به نصب نسخه های جدید سیستم روی تک تک client ها نیست)