Hi everyone, my name is Michelle and
today we're going to quickly discuss
the Azure app Service file system,
specifically temporary storage.
So there's three different types
of files within Azure App Services,
the same as with any other computer:
Persisted temporary and
machine level readonly.
We're focusing on these
temporary files over here.
Which are those files that
are recycled or deleted
whenever you go to restart
or recycle your process.
These files are going to be stored
within the local directory of
your file structure in either
the app data or temp folders.
Now I'm sure you're wondering,
why does this matter to me at all?
Well, if we go ahead and move
over to the portal over here,
you'll see that I'm on a normal app service.
Say that your site is suffering
from some poor performance and
you want to troubleshoot what
exactly could be causing that.
We can go ahead and move over to
the quotas blade within the web
app and here you'll see a report
of all of the file system storage
within your app service plan.
Say that this is at 80% or above,
your performance is going to suffer.
However, temporary storage has a
different limit than your overall app
Service plan file system storage.
As such, you will not be able to
see those from the quota blade.
So what if your quotas blade is reporting
a low amount of file consumption,
but your site still has poor performance?
This can still be related to file quota,
but we need to check on that somewhere else.
To confirm that this is temporary storage,
we can go ahead and navigate
back to the overview.
And just restart the site.
Because what did we say?
We said that the temporary storage
folders will empty whenever you go to
recycle your process or restart it.
Then what you would be able to
do is navigate to your site and
see the performance improve.
Another way to further verify that
this is temporary storage would be to
navigate to the portal again and go to
your diagnose and solve problems blade.
Here we can enter into the best practices
for availability and performance detector.
Now we see away once it loads to go ahead
and monitor our temporary storage usage.
Specifically right over here.
So once confirmed to be an issue,
what can we do about it?
How can we determine, oh,
this is what I need to fix in my
code in order to solve that problem.
What we can do is we can go ahead
and navigate to the kudu of our site.
If you're unfamiliar with Kudu,
it is the normal URL of your site with
the SCM in between the web app name and
the Azure websites component of the URL.
Here you will instantly see it
defines your temporary storage
folder location within the local
directory within the temp folder.
We can even see the exact amount being
taken up by temporary storage if we
navigate into the environment tab.
But how can you browse to that
folder and see what's inside of it?
Well, we can go ahead and navigate
to the debug console,
which will take you to your file directory.
However, you'll notice that you
instantly enter the home directory
and you can't go back anymore
to enter the local directory.
This is because the Kudu for your app
service is actually running on a
separate process than the web app itself.
So you cannot see the temporary
file storage from this view.
However, there is a way to fix that.
What we can do is we can go ahead and add...
this setting
to our app settings in the portal.
In order to do that, we would go
back to the web app in Portal.
Go over to configuration.
Once it loads.
There we go and then right
here we have our app settings.
So now we can add the setting that
combines the file system for KUDU and the
website. So we can see that...
(adding it right here)
within the diagnostic console over here.
I do want to point out, however,
that this is a legacy or unsupported setting,
but for troubleshooting purposes we will
be adding it. After this issue is solved,
we would want to go ahead and remove
the setting. Now what can we do
once we have that information showing in
Kudu? We can go into the local directory
and see the files there by using this
information to figure out where in
our code may be writing to this space.
And one last item that I want to point
out is that there is a site extension for
disk usage that can be installed from KUDU.
We can go to the Gallery.
And Scroll down until we see Azure
Web apps Disk Usage site extension.
Once installed, this will actually
list the size of each of your
folders in that diagnostics console.
Or debug console, however,
you would like to phrase it.
So instead of just seeing
the individual file sizes,
you'll have folder sizes.
This is activated by just
restarting your application,
and if we just go on back
over to site extensions,
you'll notice that's already installed,
so it's pretty fast.
The reason why I wanted to tell
you about this extension is that
while it is great for pinpointing
and understanding which components of
your site are consuming disk space,
it does have a limitation of listing the
information for only the home directory.
Due to this,
it would not be used when
troubleshooting temporary storage issues.
However, I still wanted to mention it as
it is useful for other disk space issues
your application may be facing.
But to conclude,
that's how you can go about
troubleshooting temporary storage issues,
and I hope that this information
helps some of you understand this
section of the file structure
a little bit more. Bye everyone!