Best practices to take care on Environment and process when bot numbers are incresed

[ManojKumar3]

Hi Team, Best practices or approach we need to take care when the process build on application server gets increased in application server dramatically over the years. so more load and maintenance is but on that server..so have take any measure to make sure that all goes smooth even when the Bot count is increased in the application server.  

[AmiBarrett]

1) Set all Processes and Objects to ""Log Errors Only"" 2) Keep your application servers, but have the bots connect direct to the database instead. It's significantly faster and has zero loss of functionality. To be clear: Blue Prism support has told us on the phone that this networking solution will remove encryption - We have proved otherwise. Encryption does in fact remain. 3) See which DB tables are taking up the most space (as displayed on the default Home dashboard in Blue Prism) and trim/truncate as-needed. Less data not only means more disk space, but also a much smaller local index file for it to have to seek through.

[BenKirimlidis]

Hi Manojt, I agree with AmiBarrett on reducing the amount of data being logged to the DB will help tremendously. Plus depending on how the process runs it can actually dramatically improve performance.  We had an old legacy process that used tons of loops and the run time went from hours to minutes to load a work queue. However, its worth having specific notifications to monitor progress on key stages using the 'Work Queues' utility - 'Update Status' action.  That way if you have mirror to the BP DB set you, you can query it and get detailed MI at any time. Also in QA and Testing, logging everything can be useful for debugging.  But agree 100% to limit logging in production. @AmiBarrett You proved the encryption is still in place?  Could you tell me more about that?

[AmiBarrett]

We've removed the BP controller software from our environment entirely in lieu of using a custom-developed piece of software. The encryption key is stored to the DB instead of the Application Server, and the client is able to recognize that. Likewise, you could keep your key on the app server and still see it being used when you analyze the DB, despite the runtime resources connecting direct to the DB instead.

[BenKirimlidis]

I'll have to check that out.  Thanks AmiBarrett :) @manojt Another point worth considering, is that if your deployments grows considerably i.e. hundreds and hundreds of bots and hundreds an hundreds of processes. At a certain point it might be useful to have separate Production servers. E.g. 5 main business customers each with dozens of processes and lots of robots dedicated to each task.  You could have 5 separate control rooms with a number of shared utilities.  Easier to manage and increases the reliability in the event one server went down, you could import tasks into another and run them from there.