[SR-Users] Re: http_async and tm

On Aug 29, 2024, at 4:18 PM, Ben Kaufman <bkaufman(a)bcmone.com> wrote: I'm not sure I understand how it's not getting more throughput. Every request got its reply in only a little over a second, from the first request to the 18,000 request. Using a blocking http request this config (low number of workers) died quickly. The original post in this thread (i.e. the real-world example) was a 302-redirect server. My example traded that for a 404, because it was easier to implement than returning values from the web server to make a 302 reply, but certainly extracting information from the http reply and putting it into the SIP reply is trivial. Kaufman Senior Voice Engineer E: bkaufman(a)bcmone.com SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org> Sent: Thursday, August 29, 2024 2:41 PM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Cc: Alex Balashov <abalashov(a)evaristesys.com> Subject: [SR-Users] Re: http_async and tm CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Ben, You're absolutely correct that the transaction is resumed upon receipt of an HTTP reply, and that the async workers do not block on this event. This is also true of a variety of other patterns and workflows which shuttle the transactions off to an async process pool, not really specific to the HTTP client modules. `tsilo` comes to mind. My overview was meant to make a more general point: once the transaction is resumed, the processing is otherwise linear and identical in every other respect to how it would unfold in the main SIP worker process. This is what I meant when I said: "This does not cause the processing to enter some generally more asynchronous mode in any other respect, and in that sense, is quite different to what most people have in mind when they think of asynchronous processing in the context of general-purpose programming runtimes." My over-arching point is that throughput is still limited by the (fixed) size of the async worker pool, and that the same considerations about its sizing apply in async land as in regular child process land. For this reason, I don't think you are correct to conclude from this exercise that using asynchronous mode / `http_async_client` increases _throughput_. Your example config has one async worker, and that worker can only handle one resumed transaction at a time. This is not a net increase in throughput. You say in your documentation: "Re-running the load test will result in heavily blocked and dropped SIP requests", which is absolutely true; in this paradigm, you are liberating the SIP workers from the congestion that would cause "blocked and dropped SIP requests", by doing what I described in my original message: "suspending it and shipping it to another set of ancillary worker processes". The real conflation here is between "not dropping SIP requests" and "increased throughput". There is no increased throughput, only a deep queue of suspended transactions lined up at the async worker pool. This goes back to the question I raised in a previous message: what exactly is meant by "handle"? Are you "not dropping" 300 CPS, or are you relaying 300 CPS worth of requests? I fully believe that one async worker can churn through hundreds of resumed transactions per second, driven by near-simultaneous HTTP replies, when the effect is simply to send a '404 Not Found', as in your config. Real-world workloads don't particularly resemble that in most cases. You're not getting more _throughput_. You're changing where the blocking occurs so as to not obstruct receipt of further SIP messages, which is precisely what I meant when I said: "suspending it and shipping it to another set of ancillary worker processes". From the perspective of not dropping SIP messages, sweeping these transactions out of the main worker pool is indeed quite effective, and if it is in that narrow sense of "not dropping" that you meant "keeping up with the requests", then you are quite right. I was thinking about bottom-line throughput capacity. I think there is a misconception out there that other config script operations also acquire an asynchronous character, beyond the initial "shipping", as it were, and this is the idea I meant to single out. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes… Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: