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

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

آیا این به نظر می رسد آشنا است؟شما یک برنامه را اجرا می کنید - به عنوان مثال ، برای اسکن پرونده ها در SharePoint Online - اما شما لرزان می شوید. یا حتی بدتر ، مسدود می شوید. چه اتفاقی می افتد و برای متوقف کردن آن چه کاری می توانید انجام دهید؟

لرزش چیست؟

SharePoint Online از Throttling برای حفظ عملکرد بهینه و قابلیت اطمینان سرویس آنلاین SharePoint استفاده می کند. پرتاب تعداد تماس های API یا عملیات در یک پنجره زمانی را برای جلوگیری از استفاده بیش از حد از منابع محدود می کند.

چه اتفاقی می افتد که در SharePoint Online دچار فشار می شوید؟

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

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

برای درخواست هایی که یک برنامه از جمله Microsoft Graph ، CSOM یا تماس های REST ، SharePoint Online Retu Http Code 429 ("بیش از حد درخواست ها") یا 503 ("سرور خیلی شلوغ") بازگرداند و درخواست ها شکست خواهند خورد.

• HTTP 429 نشان می دهد که برنامه فراخوانی درخواست های زیادی را در یک پنجره زمانی ارسال کرده و از یک حد از پیش تعیین شده فراتر رفته است.
• HTTP 503 نشان می دهد که این سرویس آماده رسیدگی به درخواست نیست. علت متداول این است که این سرویس در حال تجربه سنبله های موقت موقت است که انتظار می رود.

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

اگر برنامه توهین آمیز از محدودیت های استفاده فراتر رود ، SharePoint Online ممکن است برنامه یا الگوهای درخواست خاص را از برنامه مسدود کند. در این حالت ، برنامه از وضعیت HTTP کد 503 استفاده می کند و مایکروسافت به مستاجر بلوک در مرکز پیام Office 365 اطلاع می دهد.

کارآموز

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

گفته می شود ، این نادر است که یک کاربر در SharePoint بصورت آنلاین دچار لرزش شود. این سرویس قوی است و برای کنترل حجم بالا طراحی شده است. اگر به دلیل کد سفارشی ، 99 ٪ از زمان استفاده کنید ، به دلیل کد سفارشی مانند قطعات وب سفارشی ، نمایش لیست پیچیده و نمایش داده شد ، یا برنامه های سفارشی کاربران اجرا می شوند. این بدان معنا نیست که راه های دیگری برای لرزیدن وجود ندارد ، فقط این که آنها کمتر رایج هستند. به عنوان مثال ، یک کاربر که همگام سازی داده های زیادی را در 10 دستگاه همزمان همگام سازی می کند ، می تواند باعث لرزش شود.

کاربردی

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

هر برنامه در یک مستاجر محدودیت های خاص خود را دارد که براساس تعداد مجوزهای خریداری شده در هر سازمان است (به برنامه های ذکر شده در محدوده SharePoint برای مجوزهای موجود مراجعه کنید). هر درخواستی که یک برنامه در تمام نقاط پایانی API ، از جمله Microsoft Graph ، CSOM و REST ایجاد می کند ، به سمت استفاده از برنامه ها حساب می شود.

شیرپوینت API های مختلفی را ارائه می دهد. API های مختلف بسته به پیچیدگی API هزینه های مختلفی دارند. هزینه API ها توسط SharePoint عادی شده و توسط واحدهای منابع بیان می شود. محدودیت های برنامه نیز با استفاده از واحدهای منابع تعریف شده است.

جدول زیر محدودیت های واحد منابع را برای یک برنامه در یک مستاجر تعریف می کند:

ما این حق را داریم که محدودیت های واحد منابع را تغییر دهیم.

از نظر هزینه های API ، API های نمودار مایکروسافت هزینه واحد منابع از پیش تعیین شده در هر درخواست دارند:

ما این حق را داریم که هزینه واحد منابع API را تغییر دهیم.

Delta با یک نشانه کارآمدترین روش برای اسکن محتوا در SharePoint است و ما در بهترین روشها برای اسکن برنامه ها با جزئیات بیشتر صحبت می کنیم. برای کمک به برنامه هایی که از راهنمایی پیروی می کنند ، ما هزینه واحد منابع درخواست دلتا را با یک نشانه به 1 واحد منابع کاهش می دهیم ، اگرچه این یک پرس و جو چند ماده ای است. درخواست دلتا بدون نشانه یک پرس و جو چند ماده ای در نظر گرفته می شود و در هر درخواست 2 واحد منابع را هزینه می کند.

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

CSOM و REST هزینه واحد منبع از پیش تعیین شده ای ندارند و معمولاً واحدهای منبع بیشتری نسبت به APIهای Microsoft Graph برای دستیابی به عملکرد مشابه مصرف می کنند. و علاوه بر محدودیت های واحد منبع، CSOM و REST نیز مشمول محدودیت های منابع داخلی دیگری هستند، بنابراین اگر برنامه ها CSOM و REST را فراخوانی کنند، ممکن است فشار بیشتری نسبت به محدودیت های توضیح داده شده در این سند تجربه کنند. اکیداً توصیه می کنیم در صورت امکان Microsoft Graph API را به جای APIهای CSOM و REST انتخاب کنید.

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

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

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

در زیر خلاصه ای سریع از بهترین روش ها برای کنترل دریچه گاز آورده شده است:

• تعداد درخواست های همزمان را کاهش دهید
• از افزایش درخواست خودداری کنید
• در صورت امکان، APIهای Microsoft Graph را به جای APIهای CSOM و REST انتخاب کنید
• از هدرهای HTTP Retry-After و RateLimit استفاده کنید
• ترافیک خود را تزئین کنید تا ما بدانیم شما چه کسی هستید (به بخش بهترین تمرینات دکوراسیون ترافیک در زیر مراجعه کنید)

همانطور که قبلاً گفته شد، Microsoft Graph APIهای ابری است که دارای آخرین پیشرفت ها و بهینه سازی ها هستند. به طور کلی، مایکروسافت گراف نسبت به CSOM و REST منابع کمتری را برای دستیابی به عملکرد یکسان مصرف می کند. از این رو، استفاده از مایکروسافت گراف می تواند عملکرد برنامه را بهبود بخشد و فشار را کاهش دهد.

اگر با دریچه گاز مواجه شدید، ما باید از هدر HTTP Retry-After استفاده کنیم تا از حداقل تأخیر تا حذف دریچه گاز اطمینان حاصل کنیم. هدرهای RateLimit HTTP هنگامی که به محدودیت ها نزدیک می شوید سیگنال های اولیه را برای شما ارسال می کنند و می توانید به طور فعال درخواست ها را کاهش دهید تا از ضربه زدن به دریچه گاز جلوگیری کنید.

سرصفحه بعد از امتحان مجدد

هنگامی که برنامه ها با کاهش فشار مواجه می شوند، شیرپوینت آنلاین یک هدر Retry-After HTTP را در درخواست برمی گرداند که نشان می دهد برنامه تماس گیرنده چه مدت در ثانیه باید قبل از تلاش مجدد یا درخواست جدید منتظر بماند.

احترام به هدر HTTP پس از HTTP سریعترین راه برای رسیدگی به لرزه است زیرا SharePoint آنلاین به صورت پویا زمان مناسب برای امتحان کردن را تعیین می کند.

درخواست های پرتاب شده به محدودیت های استفاده است ، بنابراین عدم احترام به آزمایش مجدد پس از آن ممکن است منجر به فشار بیشتر شود. به عبارت دیگر ، قیام های تهاجمی در برابر تماس با برنامه ها کار می کنند زیرا حتی اگر تماس ها شکست بخورد ، آنها هنوز هم به محدودیت های استفاده می پردازند. احترام به عنوان مجدد HTTP پس از HTTP ، کوتاهترین تأخیر و کاهش سهمیه هدر رفتن در درخواست های پرتاب را تضمین می کند.

هدرهای Ratelimit - پیش نمایش

علاوه بر عنوان مجدد ، پس از مجدد در پاسخ به درخواست های پرتاب ، SharePoint Online همچنین عنوان های IETF Ratelimit را برای محدودیت های انتخاب شده در شرایط خاص باز می گرداند تا به برنامه ها کمک کند تا نرخ محدودیت نرخ را مدیریت کند. ما برای جلوگیری از ضربه زدن به دریچه گاز ، برنامه هایی را برای استفاده از این هدرها توصیه می کنیم.

• Ratelimit-Limit حاوی محدودیت در پنجره زمانی فعلی است.
• Ratelimit-Remaining سهمیه باقی مانده را در پنجره فعلی نشان می دهد.
• Ratelimit-reset تعداد ثانیه ها را تا زمان پر شدن سهمیه نشان می دهد.

این هدرها در حال حاضر در بتا هستند و در معرض تغییر هستند. در زمان تصویب هدرها ، مشخصات IETF در پیش نویس بود. اجرای فعلی بر اساس پیش نویس 03 مشخصات IETF است. در صورت نهایی بودن مشخصات ، احتمال تغییرات وجود دارد و ما در آینده با آن تغییرات سازگار خواهیم شد.

هدرهای Ratelimit به صورت بهترین تلاش بازگردانده می شوند ، بنابراین برنامه ها ممکن است تحت هر شرایطی هدرها را دریافت نکنند. علاوه بر این ، محدودیت های دیگری نیز وجود دارد که در هدرهای Ratelimit ارائه نمی شود ، بنابراین برنامه ها حتی قبل از رسیدن به حد توصیف شده در هدرهای Ratelimit می توانند از بین بروند. در زیر لیستی از محدودیت هایی که ما از هدرهای Ratelimit پشتیبانی می کنیم. سیاست ها و ارزش ها در معرض تغییر هستند:

در زیر چند نمونه برای کمک به شما در درک هدرهای Ratelimit وجود دارد:

• یک برنامه 90 ٪ از سهمیه واحد منابع خود را (1،080 از 1200) مصرف کرده است ، و مصرف آن در تمام محدودیت هایی است که در مورد آن اعمال می شود. درخواست موفق می شود و هدرهای Ratelimit بازگردانده می شوند.

• یک برنامه 100 ٪ سهمیه واحد منابع خود را مصرف کرده است ، بنابراین به دلیل این خط مشی از بین می رود. این درخواست پرتاب می شود و هدرهای Ratelimit بازگردانده می شوند. آزمایش مجدد با Ratelimit-Reset مطابقت دارد.

• یک برنامه 90 ٪ سهمیه واحد منابع خود را مصرف کرده است اما مصرف آن در حال حاضر به محدودیت های دیگری رسیده است که هدرهای Ratelimit از آنها پشتیبانی نمی کنند. در این حالت ، این درخواست مورد فشار قرار می گیرد و هدرهای Ratelimit برای جلوگیری از سردرگمی بازگردانده نمی شوند ، اگرچه شرط بازگشت عنوان ها رضایت دارد.

چگونه ترافیک HTTP خود را تزئین کنیم؟

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

تعریف ترافیک بدون تزئین چیست؟

• در صورت عدم وجود رشته AppID/Apptitle و کاربر کاربر در API به SharePoint Online ، ترافیک بدون استفاده است. رشته عامل کاربر باید مطابق شکل زیر در قالب خاصی باشد.
• اگر در حال توسعه یک برنامه وب در مرورگر هستید ، بیشتر مرورگرهای مدرن اجازه نمی دهند رشته عامل کاربر را رونویسی کنند ، و نیازی به اجرای آن ندارید.

توصیه ها چیست؟

اگر یک برنامه ایجاد کرده اید ، توصیه این است که ثبت و استفاده از AppID و Apptitle را ثبت کنید - این بهترین تجربه کلی و بهترین مسیر را برای هرگونه وضوح شماره در آینده تضمین می کند. همچنین اطلاعات رشته عامل کاربر را که در مرحله زیر تعریف شده است ، درج کنید.

حتماً رشته عامل کاربر را در تماس API خود به SharePoint با نامگذاری نامگذاری درج کنید

• اگر در حال ساخت کتابخانه های JavaScript خود هستید ، که برای تماس با API های آنلاین SharePoint استفاده می شود ، حتماً اطلاعات عامل کاربر را به درخواست HTTP خود درج کنید و به طور بالقوه برنامه وب خود را نیز به عنوان یک برنامه ، در صورت مناسب ثبت کنید.

انتظار می رود قالب رشته عامل کاربر RFC2616 را دنبال کند ، بنابراین لطفاً راهنمایی های فوق را در مورد جداکننده های مناسب دنبال کنید. همچنین خوب است که رشته عامل کاربر موجود را با اطلاعات درخواست شده اضافه کنید.

سناریوهای پرتلاش مشترک در SharePoint Online

شایع ترین دلایل پرتاب هر کاربر در SharePoint Online ، مدل شیء طرف مشتری (CSOM) یا کد انتقال حالت بازنمایی (REST) است که اقدامات بیش از حد بسیاری را انجام می دهد.

ترافیک پراکنده

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

ترافیک بیش از حد

یک فرآیند واحد به طور چشمگیری از محدودیت های پرتاب ، به طور مداوم ، در یک دوره زمانی طولانی فراتر می رود.

• شما از خدمات وب برای ساختن ابزاری برای همگام سازی ویژگی های پروفایل کاربر استفاده کرده اید. این ابزار ویژگی های پروفایل کاربر را بر اساس اطلاعات سیستم منابع انسانی Line of Business (LOB) (HR) به روز می کند. این ابزار با فرکانس خیلی زیاد تماس می گیرد.
• شما یک اسکریپت تست بار را در SharePoint Online اجرا می کنید و از بین می روید. آزمایش بار در SharePoint آنلاین مجاز نیست.
• به عنوان مثال ، سایت تیم خود را در SharePoint بصورت آنلاین سفارشی کرده اید ، به عنوان مثال ، با اضافه کردن یک نشانگر وضعیت در صفحه اصلی. این نشانگر وضعیت به طور مکرر به روز می شود ، که باعث می شود صفحه تماس های زیادی را به سرویس آنلاین SharePoint انجام دهد - این باعث کاهش فشار می شود.
• اجرای مشتری همگام سازی OneDrive و در عین حال برنامه های مهاجرت یا برنامه هایی که سایت ها را خزنده می کنند و داده های نوشتن را می نویسند ، می توانند منجر به حجم درخواست بالایی شوند که ممکن است باعث کاهش فشار شود.

موارد استفاده نشده استفاده نشده

استفاده پشتیبانی نشده از SharePoint Online ممکن است لرزش را تجربه کند. استفاده از SharePoint و OneDrive به عنوان یک سرویس واسطه بین مایکروسافت 365 و یک مخزن دیگر نمونه ای از یک مورد استفاده پشتیبانی نشده است.

ایجاد چندین آپید برای همان برنامه

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

محدودیت های خاص سناریو

هنگام استفاده از احراز هویت فقط برنامه با سایت. read. all اجازه

هنگامی که شما از API های جستجوی آنلاین SharePoint با تأیید اعتبار فقط برنامه و برنامه دارای سایت استفاده می کنید. read. all. مجوز (یا قوی تر) ، برنامه با مجوزهای کامل ثبت می شود و مجاز به پرس و جو از تمام محتوای آنلاین SharePoint شما است (از جملهمحتوای ODB خصوصی کاربر).

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

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

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

اگر برنامه یا مؤلفه ای دارید که باعث می شود درخواست های جستجوی افراد شما از بین بروند ، ما به شما توصیه می کنیم:

1. در نظر بگیرید که آیا درخواست ها برای درخواست شما ضروری است یا خیر. به عنوان مثال ، اگر از یک سایت جستجوی سفارشی استفاده می کنید ، که بسیاری از نمایش داده های همزمان را ایجاد می کند ، بررسی کنید که آیا برخی از این درخواست ها بدون هیچ گونه تأثیر قابل توجهی در تجربه جستجوی سازمان شما قابل حذف هستند. از طرف دیگر ، با جستجوی صفحه شروع SharePoint ، تجربه جستجوی افراد مدرن ما را در جستجوی مایکروسافت در نظر بگیرید. جستجوی افراد در جستجوی مایکروسافت برای عملکرد بهتر و نتایج مرتبط تر بهینه شده است.
2. از ایجاد درخواست های همزمان خودداری کنید. به عنوان مثال ، به جای صدور 10 درخواست به طور هم زمان ، آنها را به طور متوالی صادر کنید - فقط پس از اتمام نسخه قبلی ، پرس و جو بعدی را صادر کنید. اگر به سرعت به آنها احتیاج دارید ، به عنوان مثال از بار صفحه ، ممکن است لازم باشد این نتایج را ذخیره کنید.
3. سعی کنید درخواست ها را در یک پرس و جو واحد ادغام کنید. به عنوان مثال ، در عوض ، 10 نمایش داده شده همزمان برای WorkEmail: user1@constoso. com ، WorkEmail: user2@constoso. com. WorkEmail: user10@contoso. com ، یک پرس و جو را امتحان کنید ، WorkEmail: user1@constoso. com WorkEmail: user2@constoso. com. WorkEmail: user10@contoso. com.
4. اگر یک سناریوی با حجم بالا (بیش از 25 درخواست در ثانیه) واقعاً لازم است ، از API Microsoft Graph استفاده کنید.

اگر در SharePoint Online مسدود شوید ، چه کاری باید انجام دهید؟

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

اگر اشتراک شما را مسدود کنیم ، در مرکز پیام Office 365 به شما اطلاع می دهیم. این پیام توضیح می دهد که چه عواملی باعث ایجاد بلوک شده است ، راهنمایی در مورد چگونگی حل مسئله متخلف را ارائه می دهد و به شما می گوید که برای حذف بلوک با چه کسی تماس بگیرید.< SPAN> مسدود کردن شدیدترین شکل لرزش است. ما به ندرت مستاجر را مسدود می کنیم ، مگر اینکه ترافیک طولانی مدت و بیش از حد را تشخیص دهیم که ممکن است سلامت کلی سرویس آنلاین SharePoint را تهدید کند. ما برای جلوگیری از ترافیک بیش از حد از عملکرد و قابلیت اطمینان SharePoint به صورت آنلاین ، بلوک هایی را اعمال می کنیم. یک بلوک - که در برنامه یا سطح کاربر قرار می گیرد - مانع از اجرای فرآیند توهین می شود تا اینکه مشکل را برطرف کنید. اگر اشتراک شما را مسدود کنیم ، باید قبل از حذف بلوک ، اقدامات را برای اصلاح فرآیندهای توهین آمیز انجام دهید.