Exposed Process/SOAP performance

[rj.latherow]

Hello - we have a few processes that are exposed as API (SOAP, we are on the latest 6.10 version).  These processes are very simple and either record a request as a queue item or return a status- in both cases the pages take seconds to run on their own.

When run as an API request, they are SLOOOOOW- sometimes just under a minute, and the fastest I have been able to see is around 20 seconds on the very rare occasion.  Average response time is ~42 seconds, which is not acceptable for what we are doing.

Is there any way to increase the throughput/response time on the gateway?  The machine is dedicated to this simple task, so it isn't a resource issue.  I am on the cusp of scrapping the solution and finding a path forward that isn't limited by BP's performance.

[Denis__Dennehy]

I think you probably have to go down a network latency testing rabbit hole first, a SOAP api call to add a new queue item should be be almost instantaneous.

Have you tested the exact same functionality running local to you in a test sandbox - hosting a test BPServer instance to see how fast that is comparted to your live environment.  What is the spec of the BPServer machine,  maybe compare it to online advice about the specification required for a fast soap service server.   Also ask your IT department to grab some network sniffer tools to test issues in network speed between your robots and the BPServer.

If the SOAP calls are going slow I would also expect other things to be going slow in your live environment when network calls are made.  How long does it take the live robots to load a BP Process before running it etc..

[Martynas]

Hi @rj.latherow ,

have you found solution for that?  I've got exactly same setup: Object, exposed as WS, creates work queue item, returns status and wq ID.

And it's always 15~40 seconds to run, across multiple BP versions (6.2.*; 6.5.*; 6.10.*. Even 7.4.1 in current lab). At this point I didn't even though about it as bug, but "that's how it works" 🙂

[rj.latherow]

No luck making BP faster.  Between the general slowness along with the inability to do any form of request pooling/threading basically makes it kinda useless as an actual endpoint - you ideally would want it to handle multiple connections, websocket connection, etc.  Endpoints have very similar needs as a webserver, and this is more like a dialup BBS.  Great for prototyping, but not in production unless your needs are very very limited.
It is much easier to have something 'normal' handle the web/API endpoint duties and interact with BP in a more formal way - it's easy enough to run a specific process against a machine or pool and get the results using the automatec command line.  Just have your java/php/perl/cgi (haha) handle the calls and the BP conversation and return the results.

I've started making the information available in other ways, be it a small process 

[rj.latherow]

Argh, hit reply to early, but you get the gist.

[MilanPinter]

Can't you just use the built in BP APIs for that?
Blue Prism API 7.3.0

Or if you need a more complex process and have a dedicated resource, you can continuously query the queue and use the built-in API to load new queue items.

[Martynas]

Yup, I played with couple options and made it work.

I'm mostly thinking that "the ideal setup is that I don't need custom xyz where in-built feature exists" 🙂

[Martynas]

API is relatively new feature (and we'll use it, I've no doubt), but I needed to create work queue items via API since ~2018 or so

[MilanPinter]

Oh yeah, no doubt it would be ideal for this to work flawlessly, but this feature has always been sluggish and seems like it hasn’t received much attention from Blue Prism. Also, the fact that you need a dedicated resource just to listen for requests feels like a waste of capacity - there are much better solutions available (outside of BP).