0

Our web front ends are spiking quite often to 99%. I have looked at the worker process in IIS and noticed a pattern of the requests coming in.

We have a user that has been adding web parts for list views on pages and setting them up to be async, with a refresh every 30 seconds. So far, it looks like there are about 35 web parts across multiple pages set up this way, and a handful are probably opened by multiple users and left open for sustained periods of time.

Would this account for CPU spikes on the WFE? Our two WFEs have 16MB RAM and quad 2.8 Ghz Xeon processors, running on VMware.

I did some testing in google chrome debugger with one of these pages, and after the initial load there were 60 post requests from the page @ 14.4mb in a five minute period.

I don't want to suggest to the user to limit the use of the ajax option if that wouldn't normally cause performance issues.

Any thoughts?

EDIT: I found more, now the total is 48 web parts with auto refresh on.

Improve this question

1 Answer 1

Reset to default
1

I had a similar problem a while ago (with SP2010). We had one Web part with Ajax calls every 15 seconds. One WFE and 100s of users who opened the page in the morning and left it open. This resulted every morning to CPU spikes and a server freeze from time to time. The only solution was to redevelop the offending Web part with no Ajax calls anymore. The problem vanished right after the deployment of the new Web part.

If you have 48 of these Web parts placed on active pages, and if you have let's say 1000 users, chances are a lot of these are kept open.
Let's say half of these users keep a "problematic" page open, this is 500 pages with the Ajax Web part, with 2 calls per minute (at least: I don't take into account the 60 request per 5 minutes you saw in the network traces, yet) this makes 1000 requests / per minute, i.e. 16 requests / sec. This can be a lot even for 2 WFE.
If you take in account more users and more requests made by the Web part, you can easily see your WFE can break.

Your options (I don't say "solutions") are:
- Understand why the Web part sends 12 requests per minute while you expect only 2.
- Deactivate the Ajax option on them.
- Don't use these Web parts and try to find an alternative.
- If you have access to the source code, try to improve the behavior (for instance by disabling Ajax requests when the page has not the focus).

IMO, don't go the approach "add more WFE" as this will only postpone the problem for a little while.

Improve this answer
3
  • Thanks. I just wanted to make sure I wasn't going crazy. It is difficult to correlate high cpu on a WFE with specific web pages and be able to use it as evidence to put in place policies restricting behavior but maybe I can do a proof of concept in our QA.
    – steveareeno
    Commented Mar 14, 2017 at 12:23
  • I just looked at the usage reports for the site where the majority of these pages live and there is, on average 13,000, hits per month. Yesterday alone there was 628 hits with 39 unique users. I don't know, though, if each async action is counted as a hit.
    – steveareeno
    Commented Mar 14, 2017 at 12:54
  • async actions are probably not counted as a hit as they target an API, not the page itself.
    – Evariste
    Commented Mar 15, 2017 at 6:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.