Skip to main content

Known limitations

The Grexx Platform has some limitations. Sometimes this is because functionality has not yet been implemented. In other cases this is due to limitations of the underlying technology.

Below you will find an (incomplete) list of limitations.

What can we handle?​

The strength of Grexx Platform is that it is low code, changes are easy to make, and it is flexible. For performance intensive processes, it is possible to customize your application's behavior:

Note that these customizations take place outside the low code environment and require a good level of programming knowledge.

How fast is Grexx Platform?​

The performance of your application depends not only on the platform, but also on your configuration and amount of data your application contains..

For more information about analyzing and improving performance, see Debug performance issues and related guides.

You can also test what happens to the performance when your application contains more data using our load testing product.

Tip:

Use either your Testing or Acceptance environment for load testing. Avoid load testing on your Development environment, as this will impact your ability to test your changes as you work. Avoid load testing in your Production environment as this could impact your users.

How many users can the Grexx Platform handle at the same time?​

The number of concurrent users that the platform can handle depends on a number of factors, including what those users are doing, the pages they are requesting, and how long they spend on each page.

What you can do is investigate the calculation time for one user. Using log data you can find out the requests that were made and how long they took. For a given period of time, you can then determine how long it took to process the requests. Divide the total process time by the time period to get the calculation time fraction for one thread. Depending on the precise circumstances, a maximum of eight threads are available.

For example, suppose one user made 50 requests in a minute, of which the 3 longest took 2600 milliseconds, 900 milliseconds and 150 milliseconds, and the remaining 47 took an average of 50 milliseconds. The total calculation time for that user was 2600 + 900 + 150 + 47 * 50 = 6000 milliseconds. So for this user in this minute (60 seconds), 6 seconds of calculation time was needed. This means that on average, 10 users can be handled sequentially by one thread. With 8 threads the number will be 8x higher: 80 users at the same time.

However, in practice you do not want to look for the maximum based on average use. In part this is because the average does not take into account that users may be more active in one second than another. Furthermore, things can become slower when running in parallel because they have to wait for each other. If users are independent of each other (and therefore do not all need their computing time at the same time, and also do not need the same resources), then 40 users would be a practical limit in this example. However, if the amount of data subsequently increases and all requests take twice as long, the calculation time would double and the number of concurrent users that is possible would halve.

Frontend​

Show dates of a completed task​

It is possible to show data of a task that has completed, but form logic is not fully executed, for example the switch picklist does not work properly.

Backend​

Data size​

The following limitations apply:

  • Maximum size of one request (one dataset, template, etc): 100 MB
  • Maximum size of one attribute: 25 MB (recommended, implemented in GP-7519)

Long running requests​

We have sometimes experienced database problems with long-running requests. This is related to the size or duration of database transactions. Therefore, we automatically commit all to database transactions that take longer than 15 minutes. This means that the transaction can no longer be rolled back if an error occurs, although this impact is minimal.

A database transaction is automatically committed in the following circumstances:

  • At the end of a request.
  • With a configured commitAll process block activity.
  • At the beginning of a try catch.
  • When taking actions that cannot be undone, such as sending an email or a web service request.
  • Every 15 minutes since the last commit.

Marketplace​

Import of available products​

Sometimes after importing products from Grexx Marketplace, the case IDs are incorrect. This results in miscellaneous display errors in the Studio. To fix this, from your Studio go to Products > Available products and run the activity Correct CaseIDs.