Restriction on the number of Transactions in a Virtual Service.

[Joao Ramos]

Hello,

 

I have a need that involves restricting the number of transactions that a virtual service can handle.

 

Example: A service for functional testing can handle any number of requests in a given time (for example, 20 transactions per second).

However, in a performance test this value can increase considerably (example, +20 transactions per second).

 

Is there any way to define this number of transactions so that, in my example, when receiving more than 20 transactions during one second, the SV "blocks" more requests and "stop" responding?

My VSE in questions is for Performance.

Regards, 

João Paulo Ramos

[Danny Saro]

Hi João,

This is not possible Out Of The Box. There might be some possible customized solutions that you could try to simulate the same behaviour.

The first one actually lies outside the DevTest environment, and that would be to configure an API Gateway in fornt of the VSE to "block" all incoming requests when going above a particular tps (eg. +20 tps). It can be configured on the level of ports of a VSE server, so it would block a  specific virtual service going above the limit, but other virtual services would continue to work fine.  

Another possibility is to build in this limit as a customization in the virtual services themselves. So, every virtual service deployed in this VSE will need to have this customization. So, there will need to be some discipline in the process and procedures for the people building and deploying the virtual services, to put it in there every time.
The following aspect of this solution would have to be investigated further. This solution does not block the requests from coming in, the requests are still entering the virtual service. The customization in the VSM will prevent that the request reaches the "Http/Https Respond"-step. Normally an incoming request will be deleted as soon as the corresponding response is returned to the client, so this solution will have to make sure that this also happens for the incoming requests above the configured tps, otherwise these internal request-structures will build up and take up memory and eventually your VSE might run out of memory. If you decide to go for this solution let us know so we can look further into this.

If the requirement is to prevent teams to do performance testing on a VSE that is supposed to be used only for functional testing (even if it is a Performance VSE) then to solution could be to automate the actions a system administrator would take. You could build a script or build a DevTest TestCase that would use the lisa invoke APIs to scan the deployed virtual services on a specific VSE and for each virtual service that goes above the configured tps the script uses the API to "Stop" that virtual service. You can then use a scheduler to run that script on a regular basis or if you did it in a DevTest TestCase you can use Continuous Validation Services to run that test case every minute or so.

Hope this helps.

that it is I have a There is right now a technical unknown there needs to be a procedure that that is deployed on this VSE. So this is It would be have to be donedone for am notis probably the least intrusive, and that would be to 

, but (at least for me) some of them they lead but  

------------------------------
Cheers,

Danny Saro
Client Services Consultant
Broadcom Software
------------------------------

[Danny Saro]

Hi João,

you can ignore the gibberish after the end of my answer 😀

Danny Saro

Client Services Consultant

Broadcom Software


-------------------------------------------------

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Rafael Cintra]

Hello João,

Based on our previous discussion it seems to me what you are trying to do is trying to simulate what an API gateway would be doing through Rate limiting. This would basically mean that once a number or sequential transactions hit your API (in this case a Virtual Service) over a number of seconds we would block additional incoming transactions and display some type of message to your requester, such as "429 - Too Many Requests" or something similar.

This would be something that could be applied on an eaiser manner since it can be setup at your VSE level without having to ensure there is customization done at each Virtual Service, existing or otherwise to accomplish rate limiting. This solution would also be more efficient on identifying individual requests and controlling the rate they still have available or not over time.

If needed, API gateways can also have quotas defined in conjunction with Rate limits which can bring even more control and governance over how many transactions your virtual services are servicing.

In any case is not possible to have an API gateway working with your VSEs we could as Danny said look into some type of script customization at the virtual service level but that leads to a more detailed investigation and additional considerations to ensure this will properly manage transaction count and not end up consuming all your memory in the process.

As mentioned before we can continue working together to determine the best path forward.

Thanks,