On Tue, 14 Jul 2020 01:00:17 -0700 (PDT)
> Yes, you're right, as I wrote in step 2, our HttpHandler uses Unirest
> to process http requests, not Http client RA.
given that Unirest runs its own event loop in the background I don't
think it is directly usable by a SLEE service. As an HTTP RA already
exists it is probably not worth reimplementing something similar.
> If I will use Http client RA as you suggested, do you know which
> performance can handle such architecture?
I don't have any performance numbers for HTTP client RA. Even if I had,
performance numbers are not really applicable to a different use case
in a different deployment. You will have to conduct your own performance
tests and measurements.
> And can you please share any examples of code?
SLEE HTTP repo has a REST enabler  (an SBB for reuse in a service as
a child SBB), which might be used in some projects under the Restcomm
umbrella, but I don't have a reference offhand. Anyway, it looks
really simple - you should be able to use it even without samples.
> Also do you know how to increase SBB Pool size? Or it doesn't matter
> to handle high load on this service?
I wouldn't worry about the object pool. The first parameters that
you /may/ have to increase to handle high load is the max heap size and
possibly event router threads. But I wouldn't even touch those without
any test results. Twiddling any knob will have side effects. For
example, increasing heap size will likely impact latency due to longer
garbage collections. So there's no magic switch that unlocks
performance, everything has a cost - getting the optimal performance is
a balancing act.
> 1000-2000 calls per second on one node.
That should be doable on a server that's not too old. Unless of course
you hit some implementation detail that effectively linearizes
processing on a single core, which does happen sometimes in practice
but it's fixable. ;)