Hello! I upgraded our company's website to version 7.15.7 assembly: 1.0.7706.20570 using FTP to upload the files to a development slot in Azure. When I went to publish it, I simply swapped the dev and production slots. I didnt notice until a week or so later that the size of the website increased from 662MB to 1475MB .
Can anyone provide any insight as to what might have caused this? Cached/temp files maybe? I was thinking it could be related to the Azure SQL database as well. Any suggestions are appreciated!
Which version did you upgrade from, how did you upgrade and 'which files' did you copy up?
My thinking is you could have had something in your dev environment eg like a .zip of the original site to work on the upgrade, and then when you copied it back up via FTP, included the zip file... I speak from experience here :-P it's always media.zip for me!
The other consideration would be perhaps where you are storing the cache for processed images, when a request is made to an image with a resize instruction eg width=50, it is processed by the ImageProcessor plugin and this produces a cache of processed images to save having to resize on each request... usually you'd use Azure Blob Storage for media AND configure another container for the cached versions... but when you upgrade, if it's via Nuget, then your original settings may have been updated, and now this cache is being created on disk in the /app_data/temp/cache folder I think...
... worth seeing if that particular folder is huge.
Do you still have the swapped production slot that's now in development? and you could compare folders via kudu?
I appreciate your help. I upgraded from Umbraco version 7.14.0 assembly: 1.0.7009.26199. I downloaded a backup of the site, created a new VS project and copied the website files from the backup into the new repo, and installed Umbraco via Nuget using the package manager console. Then I ran the build and published it to a deployment slot.
I do still have the swapped production slot so I will compare the two. I haven't used Kudu, but found where I can access it under advanced tools in the blade menu.
My first point of call would be to check the files on the slot - pull it down via FTP if need be, if you can't grab the info from within Azure somehow.
When this has happened to me in the past, same as Marc, it's usually been a media-related issue, or in one odd case, I had HUGE log4net logs!
I've had a quick scan over what's changed from your versions and nothing really jumps out to cause your issue.
Unfortunately, I wasn't able to pinpoint any huge jumps in file size just by comparing the folders between the two slots. Media was fairly even, same with the umbraco folder, app data, etc.
I deleted the cache and it didn't do much to decrease the size, maybe 100MB.
I noticed all of my visual studio files were in there, and removing them freed up about 300MB, so my website is still over a gig, but not 1.4GB anymore.
Website Size Doubled After Upgrade in VS Using FTP
Hello! I upgraded our company's website to version 7.15.7 assembly: 1.0.7706.20570 using FTP to upload the files to a development slot in Azure. When I went to publish it, I simply swapped the dev and production slots. I didnt notice until a week or so later that the size of the website increased from 662MB to 1475MB .
Can anyone provide any insight as to what might have caused this? Cached/temp files maybe? I was thinking it could be related to the Azure SQL database as well. Any suggestions are appreciated!
Thanks, Erin
Hi Erin
Which version did you upgrade from, how did you upgrade and 'which files' did you copy up?
My thinking is you could have had something in your dev environment eg like a .zip of the original site to work on the upgrade, and then when you copied it back up via FTP, included the zip file... I speak from experience here :-P it's always media.zip for me!
The other consideration would be perhaps where you are storing the cache for processed images, when a request is made to an image with a resize instruction eg width=50, it is processed by the ImageProcessor plugin and this produces a cache of processed images to save having to resize on each request... usually you'd use Azure Blob Storage for media AND configure another container for the cached versions... but when you upgrade, if it's via Nuget, then your original settings may have been updated, and now this cache is being created on disk in the /app_data/temp/cache folder I think...
... worth seeing if that particular folder is huge.
Do you still have the swapped production slot that's now in development? and you could compare folders via kudu?
regards
Marc
Hi Marc!
I appreciate your help. I upgraded from Umbraco version 7.14.0 assembly: 1.0.7009.26199. I downloaded a backup of the site, created a new VS project and copied the website files from the backup into the new repo, and installed Umbraco via Nuget using the package manager console. Then I ran the build and published it to a deployment slot.
I do still have the swapped production slot so I will compare the two. I haven't used Kudu, but found where I can access it under advanced tools in the blade menu.
Thanks again! Erin
Hi Erin,
My first point of call would be to check the files on the slot - pull it down via FTP if need be, if you can't grab the info from within Azure somehow.
When this has happened to me in the past, same as Marc, it's usually been a media-related issue, or in one odd case, I had HUGE log4net logs!
I've had a quick scan over what's changed from your versions and nothing really jumps out to cause your issue.
Cheers, Richard
Thanks for the tips, Richard!
Unfortunately, I wasn't able to pinpoint any huge jumps in file size just by comparing the folders between the two slots. Media was fairly even, same with the umbraco folder, app data, etc.
I deleted the cache and it didn't do much to decrease the size, maybe 100MB.
I noticed all of my visual studio files were in there, and removing them freed up about 300MB, so my website is still over a gig, but not 1.4GB anymore.
Hi Erin,
have you got the following folder?
\App_Data\NuGetBackup
is working on a reply...