What are the causes of slowdowns?
Now that a large majority of businesses have at least some of their systems in the cloud, how does that impact your Office 365 apps with Microsoft Development firm?
To do this, you must first understand how these new workloads are architected. Ultimately, despite the illusion of an intangible “cloud”, data and applications still reside on a physical server. The big difference is that instead of having to manage the upgrades or downgrades of your servers yourself, Microsoft takes care of it with Office 365. The main objective of engineers and systems from Microsoft, totally dedicated to the customers, is to ensure that the end user does not experience any interruptions or performance problems in these higher layer applications.
Another point is that slowdowns should be considered normal and are simply a result of Office 365's goal of ensuring system reliability and processing speed for its users.
Regardless of which entry point into Office 365 we use ( Graph , CSOM, etc.), calls are transformed into SQL queries or calls to lower-level infrastructure, which quickly increases the utilization rate processor on the server.
These calls are unpredictable and difficult for the database to schedule since Office 365 does not necessarily know when a user is going to run, for example, a full backup or a security search, which will affect almost everything in SharePoint . To protect itself, Office 365 is forced to "throttle" traffic, which prohibits users from making these calls. These appear as failed calls (error message 429 or "Server overloaded"). Without this protection mechanism, servers could easily become unresponsive or even crash!
Even if this is the main cause, the slowdowns are not only due to a high volume of calls in your entity. Another cause can be too many entities sharing the same Office 365 infrastructure, which can lead to server overload. For example, what if another entity on the same infrastructure initiates a migration while you are performing a backup? This is the classic “noisy neighbor problem”.
Best practices to avoid slowdowns
As an Independent Software Vendor (ISV), made many changes to its products using best practices wherever possible in new interactions with Office 365. Things like app profile, registration dynamics of objects (DOR), etc. have all been taken into account. Additionally, all of our calls are ISV "tagged" to help Office 365 recognize where our traffic is coming from. (Note, however, that call tagging is only useful after a slowdown and during the log maintenance phase, which, while useful, does little to prevent slowdowns.)
Most of our products also have built-in follow-up logic. This means that if Office 365 tells us to stop, we only retry the call when we have the green light (in accordance with Microsoft's best practice recommendations).
However, a certain number of parameters remain configurable in our tools and can be dynamically optimized to avoid slowdowns!
Good practices are as follows:
Take advantage of off-peak hours! It might seem like a no-brainer, but traffic is noticeably higher during business hours when end users are interacting with the system.
Limiting the scope and parameters (like the maximum number of versions to back up or restore at any given time) can significantly reduce our calls and the risk of slowdowns. Intervene only on strictly necessary areas of the system and reduce the extent of your request.
Work with our cloud operations team! Our cloud operations team can reduce or limit the number of threads your tasks use to avoid overloading Microsoft servers. Get in touch with our team and see how they can help you.
Do not react immediately by increasing the number of active accounts on Office 365; test the app profile instead. If Microsoft is reporting problems, it really means that their servers are heavily loaded; adding more calls will not help the situation. Work with our cloud operations team to reduce the number of threads assigned to this entity and prevent overload, or work with your specialist to define an app profile if you haven't already .
These good practices should always be used before escalating problems or becoming alarmed. Microsoft provides very helpful recommendations for slowdown situations; always consult them before initiating drastic measures.
Be proactive about slowdown issues in large projects
Now that we know what to do in the event of a downturn, what proactive approach can we take?
The key is to have a process to deal with these issues. You know the deadlines for your big projects, why not let Microsoft know Al Rafay Consulting Chicago? This is a useful best practice for planning a migration but also to ensure that you get the best possible performance.
0 Comments