uCMDB REST-API should limit the number of requests per session not globally

[ThomasLanz]

Dear Micro Focus

As an industry standard every tools want to consume REST-APIs. We are planning to extensively make use of the uCMDB REST-API but recently detect the API limitation of 15 requests / second.

With the current implementation of the uCMDB REST-API we are unable to scale for multiple data consumers.

Especially with chunked data retrieval you have very soon more than 15 requests/second. As a global limitation you can never know when this limitation gets hit.

We suggest the following enhancement:

The number of API requests should not be limited globally but per Session. Let’s say 15 requests/s and per session.
With this approach the client can handle the number of parallel requests/second itself and control waiting times accordingly.
Otherwise you never know when the limitation was crossed and this leads to HTTP 5XX errors.

uCMDB REST API Limitation was found here:

https://docs.microfocus.com/itom/Universal_CMDB:2019.05/RESTAPIDeploy

Best regards,

Thomas

[Bill_Dyck]

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

[Bill_Dyck]

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

[Ralf Schulz]

There is a parameter max_requests_per_sec defined in RestApiUtils which can be set through rest_api.properties. Maybe that helps already. 

Another option is to check in the web.xml (/deploy/rest-api/WEB-INF/web.xml) for DoSFilter (https://www.eclipse.org/jetty/documentation/current/dos-filter.html). It should be present by default.

 <filter>
        <filter-name>DoSFilter</filter-name>
        <filter-class>org.eclipse.jetty.servlets.DoSFilter</filter-class>
        <async-supported>false</async-supported>
        <init-param>
            <param-name>maxRequestsPerSec</param-name>
            <param-value>30</param-value>
        </init-param>
        <init-param>
            <param-name>throttledRequests</param-name>
            <param-value>15</param-value>
        </init-param>
        <init-param>
            <param-name>delayMs</param-name>
            <param-value>1000</param-value>
        </init-param>
        <init-param>
            <param-name>maxRequestMs</param-name>
            <param-value>180000</param-value>
        </init-param>
        <init-param>
            <param-name>maxIdleTrackerMs</param-name>
            <param-value>300000</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>DoSFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

I haven`t tried it yet, but maybe that helps.

[Ralf Schulz]

I tested the DoSFilter parameters with REST API running on UCMDB Server. I needed to modify <UCMDBServer>/deploy/rest-api/WEB-INF/web.xml and <UCMDBServer>/deploy/rest-api/WEB-INF/quickstart-web.xml

The following parameters were working when testing the URL https://<UCMDBSERVER>/rest-api/ping/ with 25 users, 50 iterations and 100msec delay between iterations.

        <init-param>
            <param-name>maxRequestsPerSec</param-name>
            <param-value>300</param-value>
        </init-param>
        <init-param>
            <param-name>throttledRequests</param-name>
            <param-value>150</param-value>
        </init-param>
        <init-param>
            <param-name>delayMs</param-name>
            <param-value>10</param-value>
        </init-param>

[Bill_Dyck]

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

[Bill_Dyck]

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team