Hi, Any ideas why most calls to bgapi take 20ms (on avg) on my idle quad core FC10 box doing a single transaction at a time ? Can do 300 call per second on that box using SIPP but when a single process tries to control my FS instance using a single ESL socket than 95% of the bgapi calls return job-id in 20ms. The rest takes under a millisecond as it should. Is it possible that thread creation takes 20ms or that the job thread itself gets it's CPU timeslice before the job-id gets sent out (hardly possible with 4 CPU threads) ? I have not done any benchmarking yet to see where the real delay is - but it is visible on the loopback interface and limits the performance of my inbound socket app. a fast one: bgapi uuid_displace fca427df-a8b0-4aff-8041-e328691dea3d start tone_stream://v=-10;%(150,100,400,450);loops=2 ### T +0.001165 127.0.0.1:18022 -> 127.0.0.1:44944 [AP] Content-Type: command/reply Reply-Text: +OK Job-UUID: 73f5ac5f-f3b5-44f0-a839-1b5c785b3ae7 Job-UUID: 73f5ac5f-f3b5-44f0-a839-1b5c785b3ae7 a 20ms delay for similar calls bgapi uuid_displace 380e9f71-f6f2-3b94-3ae0-bc6437bed887 start tone_stream://v=-10;%(150,100,400,450);loops=2 ### T +0.020224 127.0.0.1:18022 -> 127.0.0.1:44944 [AP] Content-Type: command/reply Reply-Text: +OK Job-UUID: a7bc6bc9-b7ed-4c8b-a55d-61a48427ceb9 Job-UUID: a7bc6bc9-b7ed-4c8b-a55d-61a48427ceb9 Pawel,
On 2009-08-11, at 10:04, Paweł Pierścionek wrote:
Is it possible that thread creation takes 20ms or that the job thread itself gets it's CPU timeslice before the job-id gets sent out (hardly possible with 4 CPU threads) ?
Ok, found it. FS waits for the bgapi thread to get it's timeslice in a sanity loop before returning the job-id. Why parse_command waits for it to happen. Even if the thread does not make it in time nothing changes in the reply. This makes most of bgapi commands execute before the requester even gets the job-id back. Synchronous API is in that case opportunistically faster than BGAPI or Async EXEC which are deterministically slow. Pawel,
I checked the commit log and it was added by anthm to fix a race condition, I am not sure on the details though. However, the bgapi api command doesn't have anything like that, you might want to try sending api bgapi .... and see if you get the same problem, it should return right away. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 11-Aug-09, at 5:55 AM, Paweł Pierścionek wrote:
On 2009-08-11, at 10:04, Paweł Pierścionek wrote:
Is it possible that thread creation takes 20ms or that the job thread itself gets it's CPU timeslice before the job-id gets sent out (hardly possible with 4 CPU threads) ?
Ok, found it. FS waits for the bgapi thread to get it's timeslice in a sanity loop before returning the job-id. Why parse_command waits for it to happen. Even if the thread does not make it in time nothing changes in the reply. This makes most of bgapi commands execute before the requester even gets the job-id back. Synchronous API is in that case opportunistically faster than BGAPI or Async EXEC which are deterministically slow. Pawel, _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (2)
-
Mathieu Rene
-
Paweł Pierścionek