This article explains how the OutSystems Platform uses the disk in the Platform Server to store objects, and enables our customers to understand, control and manage that disk space usage.
Knowing the commonly largest directories
First, let me clarify on the most commonly growing folder locations under the Platform Server installation directory, in the context of an OutSystems Platform server installed with the .NET stack version of the platform. Each of these folder locations can reach to several tenths of GB, depending on the factory size, and the purpose of the environment and folder.
On the table below, you'll find detailed information about what it's stored on each of the folders that usually take more disk space, along with the purpose of those folders and in which server profiles and environment types we can find them using up disk space. For this table do take into consideration the following server profiles:
- Controller: A controller is the server that is responsible for the 1-Click Publishing process, and we assume here that is it's sole purpose, meaning that is a pure controller, without the Front-End server role.
- Front-End: The Front-End server is the server responsible for the runtime execution of the OutSystems applications, and thus, were the applications are deployed (either in the public or personal areas).
|Type of content||Description||Location||In Controller?||In Front-End?||Environment type|
|Full Compilation Cache||All generated source code (.oml, .cs,.csproj, etc) files and all application release binary files (.dll, .aspx, .asmx ,etc), as well as all application resources files (.js,.css,.png,.gif, etc) in a full compilation.||<platformserver>\share\<espacename>\full||Yes||No||All|
|Release application files package (zip package)||<platformserver>\share\<espacename>||Yes||No||All|
|Partial compilation cache||All generated source code (.oml, .cs,.csproj, etc) files and all application release binary files (.dll, .aspx, .asmx ,etc), as well as all application resources files (.js,.css,.png,.gif, etc) in a partial compilation for each developer that runs/debugs the espace.||<platformserver>\share\<espacename>\partial\<developer>||Yes||No||Non-production only (unless developers do debug on production)|
|Release Application Files||
All release application files, deployed to be loaded by the Front-Ends application server (IIS). These files include all application files for this espace (.dll, .aspx, .asmx, .js, .css, images and other included resources).
All application compiled files (DLLs and JARs) that are shared between applications are hard links to the actual files stored in the \repository folder.
All application compiled files (DLLs and JARs) that are shared between applications are stored in a shared server library, along with other platform libraries.
This replaces the local copy of the DLLs/ JARs of all its producer applications in the \running folder, reducing the required disk space and the number of files that need to be distributed to the front-end servers.
|Personal Test Area Files||All release application files for a specific version that a specific user is running/debugging. These files include all application files for this espace (.dll, .aspx, .asmx, .js, .css, images and other included resources).||<platformserver\test\<espacename>\<developer>||No||Yes||Non-production only (unless developers do debug on production)|
|Temporary Asp.Net Files||This files are automatically generated by the .Net Framework, and not the Agile Platform, but they are a part of every ASP.NET application.||C:\windows\microsoft.net\framework\
v2.0.5.0727\Temporary Asp.Net Files\<espacename>
v2.0.5.0727\Temporary Asp.Net Files\<espacename>
A server can have both roles, which in that case, it would have both server role contents. Usually, the non-production environments use more disk space then production, mainly due to the number of developers, and due to the personal test areas for debugging.
What folder contents can be deleted?
Well, ultimately, base on the architecture of the Agile Platform where the applications are defined by single OML files and extensions, any folder content can be deleted and then recovered through internal processes, like 1-Click Publishing. However, as you might be aware, this takes time, and it's not recommended for the most environments, so let me elaborate on the side-effect of deleting each one of the presented contents:
|Type of content||Side Effect of Deleting it||How to recover it|
|Full Compilation Cache||This compilation cache is used when 1-Click Publishing or Debugging espaces with references. The Platform Server will fetch the producer references from this location. If they aren't here, compilation errors or runtime errors on the consumer espaces due to broken references may occur.||One needs to do 1-Click Publishing of the producer espaces to rebuild the producers compilation cache. The best way is to build an All Content solution in Service Center and publish it.|
|Partial compilation cache||This compilation cache is used during the creation of a personal test area for Debugging purposes. If missing, it shouldn't impact the debugging process.||By attempting to debug the espace again, the partial content will be recreated again.|
|Release Application Files||These are the resulting OutSystems application files, mapped on the IIS application server. If they are missing the applications will became offline. There's an automatic internal thread maintaining the content on this folder, so this should never be deleted.||One need to redeploy all espaces again to restore the application files. This can be done by restarting the OutSystems Deployment Service on the server, or 1-Click Publishing an all content solution in Service Center, or even use the Re-deploy button for every espace on the Service Center espace details page.|
|Personal Test Area Files||These are the actual application files of the personal test areas for each espace and developer. Deleting them will make the developer lose the ability to run/debug the application by accessing it on the web browser.||In order for the developer to restore it's own personal test area for that espace, he needs to perform a run/debug from Service Studio again for that espace.|
|Temporary Asp.Net Files||These are the actual ASP.NET application files loaded in memory by IIS, and if in use, they cannot be deleted until IIS is stopped. Deleting these files will cause a slower first access start to the web application.||Automatically generated by IIS upon the first access to the application.|
So, based on the tables above, and if you're concerned about disk space usage on your servers to the point of attempting to delete some of the content, here's my tip:
- Regularly (daily or weekly) clean up the Temporary ASP.NET Files, using the script that's available on the forum topic How To: Optimizing Disk usage by Temporary ASP .NET Files. This script will eliminate non-used files.
- In development environment, coordinate with your developers to clean up periodicaly (weekly or monthly) the Personal Test Area Files and eventually, the Partial Compilation Cache
- Avoid deleting the Full Compilation Cache or the Release Application Files at all on a regular basis. If necessary on one particular occasion, and an all content solution publication is scheduled, you might want to coordinate with the involved teams, but keep in mind that deleting the Release Application Files will cause application downtime, and should be scheduled accordingly.
Let's talk numbers
Finally, let me try to pass on some highlights about some recommended disk sizes.
Estimating the disk space usage of a factory is not easy, since it depends greatly on the number of Software Units, eSpaces and Developers that work on one environment. Additionally, the type of application (and thus the resources included on that application) can really offset any metrics, but from my experience, and considering the disk fragmentation impact on server performance, I usually recommend the following, based only of the Software Units metric:
- 36 GB for small factories (< 150 000 Software Units)
- 73 GB for medium size factories ( < 300 000 Software Units)
- 146 GB for large size factories (> 300 000 Software Units )
It has been more then enough so far, for both non-production and production environments. Ultimately, a good best practice is to install the Platform Server on a partition other than the system partition, to avoid system drive fragmentation.
Automatic clean-up process for the Release Application Files
The automatic cleanup process of the running directory on the OutSystems Platform is performed periodically by the OutSystems Deployment Service. The service will attempt to delete any folder within <platformserver>\running\ that is currently not being used by any IIS virtual directory, and currently by default:
- On development environments (server mode = Development) it will clear any folder older than 15 minutes
- On production environments (server mode = Production) it will clear any folder older than 24 hours
The same service also deletes any compiled application files within <platformserver>\repository\ that are not being used by any application in that Front-End and that are older than 30 minutes.
If you have the need to tweak these values, you may reach out to OutSystems Technical Support for solutions on how to change the defaults.
Regarding the period of the cleanup thread, you actually can set it on the Platform Monitoring page of Service Center (under Monitoring), and if you access the Deployment Service details, you'll find the Unused Folders Removal thread, and the time since the last execution.
Regarding the logs, you might find some General Logs from the (system) espace, regarding this cleanup thread if anything was deleted. OSTrace (for on-premises environments only) also allow you to monitor this activity.
The original post that gave origin to this Knowledge Base entry can be found at