Enabling debug will have a significant impact on the CPU use in that loop.As a general principle, please do not upload images of text, especially out of focus ones
I really can’t see where this is going. Are you saying that you want res_pjsip_… to know that it is really looking for an InTrunkID header value, and you want to look that up in the database, rather than the current code that looks up the configuration data contents in the whole request? If so, I’d agree that it doesn’t match the structure of the current processing at all.
I don’t see why you can’t do it the way that FreePBX does, which is to generate a .conf file, from a custom database, at start up, or after a configuration change is signalled.
Looking at res_config_odbc.c, although I’m not sure that any of this impacts the rate determining step, here, it seems to me that Asterisk is not using Prepare and SQLFetch effectively.
Prepare is potentially expensive, because it involves going through the query optimisation process, so you don’t really want to build the template SQL statement and prepare it every time you run the query. There is probably a layering problem here in that res_obdc… doesn’t know that it is doing a standard lookup.
SQLFetch is designed, quickly transfer a row, from the returned data stream, into a ready made structure, but it is actually being used without a structure, and the structure is being set up again for each row, with SQLGetData then called. I’m not sure if any of this actually involves server interactions, or whether it is all done using information in the data stream.