I use OpenVidu as the WebRTC system for an events platform. At one moment I can trigger up to 500 people via AJAX to change to a new call session at one time. Currently my PHP app can only manage 40 requests per second from OpenVidu API which makes the process slower than I’d hope and I have to add some other logic to PHP to slow the calls down and run it in batches. I’m also looking at reducing the customSessionID calls when not required.
Each call is a POST to /openvidu/api/sessions with a customSession ID followed by a POST to /openvidu/api/sessions/".$session."/connection to get a token.
Is there a way of making the OV API responses run quicker?
Many thanks,
James
1 Like
I’ve done some Redis caching to stop repeated calls to /openvidu/api/sessions when the customSessionID has already been generated which halves the calls.
Requests for a token still feel slower than they should. Using Paw, I’m making some example POSTs against a test API that has 10x SELECT SQL and 3x SQL calls before it responds (Nginx and PHP-FPM). Both servers are on the same physical host as many cores and as much RAM as you could wish for. Both over LAN.
OV API POST times:
SSL Handshake - 51ms
Headers Response - 41ms
Test API with lots of SQL:
SSL Handshake - 9ms
Headers Response - 18ms
Something must be slowing down the OV Nginx SSL and then also behind that.
Sounds like some progress. I can’t comment on benchmarking / improving the OV api performance.
However, I am curious what user experience or feature in your app prompts the need to migrate all users on a call to a new session ID.
Hi Betty.
It saves half the API calls but still doesn’t completely get us there. I also have to be careful about the last person leaving the session while still cached as otherwise the next token hits an invalid session. Cache time is pretty short (5 seconds) to avoid this.
The platform supports up to 500 users per event (based on 1 second AJAX requests). We put everyone into different modes remotely (stream viewers, OpenVidu groups etc). When we put everyone into their groups they get issued a new session ID matching the group.
At the moment I can issue 500 tokens in a few seconds so it’s just about working, but since the curl request is synchronous from the AJAX ping it means our pings get delayed. I use an FSM to combat this but not ideal.
I can’t work out why the SSL handshake takes that extra time and why the response is slower than my API which is doing lots of hashing/SQL work.