-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CPU spikes when loading large file #112
Comments
Hi @mwanchap We're not doing anything intensive at all with our codebase. We merely call the underlying Azure API's to retrieve the content over the wire. |
I had the same problem last year. Large number of requests to PDF files from the same IP addresses for hours and sometimes days. Based on my research it's an older version of Adobe Reader that is to blame. Adobe reader doesn't understand the response from IIS and keeps rerequesting the same file until the user closes the tab/browser. If you still have the issue, you could call the MediaFilesystemProvider and return the URL to the blob storage. That way the requests bypass your webserver completely. |
Yeah that's similar to what we ended up doing, although in our case
Umbraco's blob storage account was private, so we moved the file to a
public one and linked via the URL as you've suggested. Thanks for the
research about Adobe reader, how did you figure that out? My guess was
email server security scanners, since we have lots of PDFs in Umbraco like
this and have never encountered this behavior, until we emailed links to
one around to all our customers.
…On Mon, Mar 18, 2019, 00:17 Steve ***@***.***> wrote:
I had the same problem last year. Large number of requests to PDF files
from the same IP addresses for hours and sometimes days. Based on my
research it's an older version of Adobe Reader that is to blame. Adobe
reader doesn't understand the response from IIS and keeps rerequesting the
same file until the user closes the tab/browser.
If you still have the issue, you could call the MediaFilesystemProvider
and return the URL to the blob storage. That way the requests bypass your
webserver completely.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACSsTtG8hRZueSkwoXdCaRY1IrSCEZnAks5vXlyagaJpZM4WYSfZ>
.
|
I think I found it by Googling IIS PDF. In the end I found the following links:
I still find it weird that this was only supposed to be an issue on IIS 7.5 while I expect Azure App Services to run a newer version. |
Firstly, thanks for all your hard work on this project - it's been a huge help for us!
We manage a bunch of Umbraco-based sites and we recently had a situation where a large-but-not-ridiculous number of requests for a large-ish PDF (~10mb) was causing the Azure app service plan hosting the sites to have serious CPU usage spikes, > 90% for a period of several hours as long as the requests continued. These were all direct file requests to a /media/... url, so I don't think much other Umbraco-related work was happening aside from retrieving the file. This seems to only occur on large files as load testing on the site hasn't shown the same behaviour when requesting a large number of smaller files (e.g. images on a page). I was wondering what your thoughts were on the potential cause and any ideas on mitigations (aside from just putting the file elsewhere or using a CDN).
The text was updated successfully, but these errors were encountered: