Is Performance Engineering related to RPA?
Performance Engineering can be defined more towards finding out usage, volume, response time, SLA, bottleneck analysis, Capacity Planning. etc. RPA as such does not directly relate to that because it’s more about automating a common functionality. However, over a period of time, it has been realized and understood that although RPA is not related to performance engineering there is a sweet relationship between optimization of RPA and Performance Engineering. The best RPA optimization can be achieved by keeping some factors of performance engineering intact. Let’s hop into that.
When there is a will to broaden the RPA’s hand on the Enterprise level, all the various departments wants to come up, make a strategy at their own atomic component level and want to automate through tiny robots. Well, that’s correct too as they know the business functionality very well and to the deep. They decide on learning the robotics process and designing maintenance and monitoring strategy.
So what’s the problem? And why am I pulling performance engineering into this?
Well here we go …with a basic case study
- Initially, every department wants to perform a POC post a self-learning session.
- When the proof of concept becomes successful various departments come up and mention that they need X number of dev, QA, production robots.
- System Admin /Provider moves ahead and sets up an RPA environment.
- After a good bit of RPA development, the robots start functioning on production… super!!!
- One success story showcase brings more departments to adopt the RPA facility
- Slowly it becomes like 100s of lean software robots running left and right
Now, what’s missing?
Assessment of elicitation is missing. System admin guy had no clue what was the number of robots needed. The poor guy uses to set up new robots and by doing so one fine day he finds he has setup say 100-300 VMS.indirectly he actually generated a good job option for a couple of more guys as so many robots cannot be handled by one person. Management had no budget for further recruitment’s a result due to excessive pressure he/she feels to scratch the head for sometimes, the takes a wise decision to take it as the lesson learned and now best thing can be done is OPTIMIZE….. The… RPA…
Optimization means does the robot processes utilize the robotic VMS effectively and efficiently?
Can a Robotic VM perform multiple of robotic processes at different intervals? He/She starts researching on how to move on from one-one mapping to one-many mapping.
Can we bring down a number of robot VM based on One->many mapping.
What to do?
It’s a myth that a System Admin personal is one of the best performance engineer/testers. A true System admin personal always depends on metrics which could be application specific or operating system or network or so on…Anyways, what will he do?
He /She will analyze the Volume. Volume is a very key factor of performance engineering
1. Regular Traffic volume:
This volume is more periodic. As per this type of traffic volume. More the volume more it’s challenging and would depend on other performance engineering metrics.
2. Batch/scheduler based Volume:
This volume is more like periodic volume which gets kicked off by means of scheduled time. More the volume more it’s challenging and would depend on other performance engineering metrics.
End to End Response Time:
He/She will analyze the end to end Response time which is another key factor to consider in Performance Engineering. More the volume, more it becomes important to consider this key factor to decide how many robots will be needed.
Ease of Completion:
Another import factor is can a Robot complete task on the next day or it needs to be completed on the same day.
Based on the above factors A System admin can decide on the optimal capacity of the robot and can optimize/minimize the number of robots through a planned decommission track and can make his/her life easy for near future. And can plan and guide future robotics teams to club process and attain better framework…
Below are some cases which System Admin Guy can do to optimize RPA utilization by churning it through Performance engineering metrics
Case 1- More Volume – Less Response time:
Sys admin observes that an X process has 500 (Regular Traffic)
request to be served robots in which each task completion takes 2 minutes (end to end response time) and the robot operating duration is 900 minutes a day. That means to get all of the work done in a day the SysAdmin would definitely need to assign 1 robot per day.
Case 2- Less Volume – More Response time:
Sys admin Also finds that Y process has 15 (Regular Traffic) request to be served robots in which each task completion takes 40-60 minutes (end to end response time) and the robot operating duration is 900 minutes a day. That means to get all of the work done in a day the SysAdmin would definitely still need to assign 1 robot per day.
Case 3- More Volume-Less Response time-Can Complete on next day or so.
Sys Admin finds out that Y1, Y2 process has more (350,600) volume, less response (2 minutes) time but there is no hurry to complete in the same day. He can decide to plan to discuss with stakeholders to see if a better framework can be adapted in the next release and can thus optimize and attain one one-many
Case 4- Less Volume – More Response time-Can Complete on next day or so:
Sys Admin finds out that Z1, Z2, M1, N1 process has less volume (10-15), more response (40-60 minutes) time but there is no hurry to complete in the same day. He can decide to plan to discuss with stakeholders to see if a better framework can be adapted in the next release and can thus optimize and attain a one-many relationship.
Case 5- Batch Process +More Volume+Less Response time+Can Complete on next day or so:
Sys Admin finds out that X1, X2 batch process runs during off hours and completion time is 2 hours each. he finds X1, X2 uses separate VM for robotics/ (VM-Robot). He finds Z1, Z2, M1, N1 process has less volume (10-15), More response (40-60 minutes) time but there is no hurry to complete in the same day. He can optimize but removing separate robots and making a batch robot as part of Z1, Z2, M1, N1 at off-hours optimize and attain one-many
On the same thought lines, many optimizations can be done by mix and match criteria’s through Performance Engineering metrics
Establishing a set of few Master-On-Demand Backup Robots can also play a key role in optimization and Disaster Recovery areas. Master on Demand Robots as nothing but a Robot which can serve any designed process which needs the robot on demand to fulfill the task
What’s the capacity utilization benchmarks?
Enterprises have their own threshold defined limit. As per a generic benchmark through an optimal CPU and memory utilization
- 10-40% :Under-Utilized (CPU and memory utilization parameters:within 30%)
- 40-60% Moderately Utilized (CPU and memory utilization parameters: within 40%)
- 60%-80% Optimally Utilized(CPU and memory utilization parameters:within 60%)
- 80%-95% Optionally Utilized but needs attention as the backup may be needed(CPU and memory utilization parameters: within 70%)
What is capacity utilization formulae of robotics?
Well, it depends on the dimension of a thought process let by a person, group of people or by Enterprise Standards. As per me below could be a promising formula.
please note that here assumption is that here CPU and memory utilization parameters of VM are is linear and stable and within 70% limit. if a said robot is spiking CPU and memory to more than 80% then all below goes for a toss
AVG /Peak Utilization of Robot= (Avg Transaction Volume/ day* AVG Time spent on completion (Succesfull+Failures))/Robot Operating duration)*(100)/number of current robots)
- RobotX is a robot process which gets 100 transactions avg a day and on peak say 150
- RobotX completes the transaction on an average in 20 minutes
- RobotX Runs for say 16 hours a day=960 minutes
- RobotX has currently 4 robots and process owner asks for more robots lets see if avg or peak factors can determine the capacity and generate the need for the new robot.
- Avg robot utilization =(100(a day)*20 minutes(completion time)/960(robot operating duration)*100/4= 52.1%
- peak robot utilization=(100(a day)*20 minutes(completion time)/960(robot operating duration)*100/4=
- As per benchmark values, avg robotic utilization is trending to moderate utilization and peak is leading towards optimal utilization indicator.
- Its visible that if future transaction traffic of robotics increase to 100% or peak to another 25% there will be high chances of increasing VM(under current circumstances).