Publish and Deployment speed
Application Type
Traditional Web
Service Studio Version
11.10.22 (Build 42701)
Platform Version
11.8.0 (Build 12006)

Hi all,

I thought i'd post this to see if anyone can point us in a faster direction. 

Case: We have an outsystems with 4 environments, each has  a controller and a second OS server (two servers behind loadbalanacer) . Production has 3 servers in total. We run something like 260 applications all with at least two or three modules. Some compile (publish in service studio or deploy through lifetime) very fast, some are very slow. 

I'm trying to find out what makes them faster or slower. What i see is that the modules containing frontEnd (screens / webblocks) elements are significantly slower. Just did a deployment from our test environment to our acceptence environment and in the log of the deployment could see all modules on average take about 25 seconds to compile (some 6 some 35), but the frontend module of the application took 7 minutes. Same for compiling in service studio. 

The module has no cyclic dependencies, 4 UI flows and maybe 30 pages. Of which 24 are generated list and detail pages for an admin interface (e.g. generated in service studio, little to nothing changed apart from adding or removing columns) and the 6 other pages contain large screens split up where necessary and or possible in webblocks. 

The rest of the modules in this application are :

1 theme module

1 module with business layer logic (core services module)

1 module with JS webblocks with JS code (JS separated for clarity)

1 module with integration services (connections to external api's)

1 extension for DB connection (external database)

And two other modules containing different outputs (1 with external API and 1 with internal "api" (Service actions)). Both of which are very small. 

As said, only the FrontEnd module raises problems. The only references are towards the core services module, the theme module and the JS module. The only logic in this module is contained in screenactions and consists mostly of calls to logic in the core services modules.

So the big question: What can make compilation so slow? 



Hi Alexander,

I believe that the size of your screens may be what causes the slowdown in publishing your apps. Due to Outsystems generating the front end code when publishing, the size of its screens can make the platform take longer to compile the code in these modules.

Can you create an app with small screens to test this theory?



We do have applications with smaller screens. They compile very fast indeed. But a difference of 30 second or 7 minutes seems a bit over the top for having bigger screen.  I also work on another app which has a few screens growing in size but that one is still fast. Which was also the situation with the slow one. I remember that when i first generated the admin screens they would (i had removed the mainflow ui) generate in their own UI flow folder. That immediately took care of all speed. It would be 10 times as slow easily. Then i moved all of those admin screens in to one UI flow and all was back to normal. Since then not really added UI flows but it has "grown slow". Indeed if i take out a few of the bigger screens it goes faster, but then my question remains: What exactly makes it slow. 

  • Big screens with lots of screen actions
  • Big screens with lots of modal popups
  • Big screens split up in lots of webblocks
  • Big screen without splitting up in webblocks
  • Lots of webblocks
  • Lots of dependencies
  • Lots of local variables
  • etc....

The big screens i call big because they are part of a publishing system. They just have a lot of functionality in them. I do arrange parts of that functionality in separate webblocks. But i would really like to know when and when not, for instance, to split things into separate webblocks (which would kick off events to notify the main screen once in a while). Purely from a performance during compilation perspective. 

We are working with 6 teams with OS developers and waiting for the lifetime to be free is taking up a lot more time than we want sometimes. 


Did you consider to evaluate if the development environment is correctly sized? At least that would help with the publish times in Service Studio:

Well, after a long fight we DID get our development environment sized up from a normal package to a XL package (AWS) some three months ago. That helped a lot for the speed in Service studio indeed. Our test and acceptance environment are significantly smaller which is understandable (cost driven of course). So moving through the dev. pipeline is still a slow thing. That's why i was looking for what WE as developers can do to not let performance be an issue. In the end we can calculate how much time we are now loosing to see if more hardware would be financially attractive, but still; just throwing ram and processor capacity at it may solve the symptoms but i'd rather know what causes it so we can see if we can also do something to prevent it. 

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.