The following are the common symptoms of a non-performing SharePoint code.
1. Frequent IIS Application Pool Recycling during the peak usage of the portal
The general practice is to allocate the IIS Application Pool Memory between 800MB – 1.5GB, assuming that at least 4GB RAM is available on the machine. The IIS App Pool recycle setting limit plays an important part in the recycling of app pool memory. The idea is that app pool re-cycle settings should not be too high or too low. The recommended app pool reset limit is 1 GB. Even after all this, the IIS App Pool resets frequently, then it has to be with SharePoint code. Make sure that the native SharePoint objects are disposed explicitly.
2. Poor Application Performance
Another symptom of a non-performing SharePoint code is the Poor Application performance. Meaning, during the peak load (when the memory usage increases), system would struggle to do paging and memory fragmentation, to compensate the load.
3. High Memory Usage for IIS Worker Process Memory
When the memory usage increases, the application would struggle to handle memory allocation. In many cases, this leads to “Out of Memory” exception, which leads to application crash, when unhandled in the code.
4. High Memory Usage for SQL
The common symptom of a non-performing SharePoint application is the high memory usage for SQL Process, when the system usage is not high. If the above symptoms persist, even after proper memory management in the code, then the Capacity Planning needs & sizing needs to be re-visited again.
Musings on Cloud, Machine Learning, Kubernetes, MLOps and Distributed Systems 