search

radiantmediaplayer / rmp-vast

A client-side JavaScript solution to load, parse and display VAST 2, 3 & 4 resources with HTML5 video
https://www.radiantmediaplayer.com/rmp-vast/app/
Other
95 stars 37 forks source link

How to properly retry failed fill #19

Closed invalidtask closed 5 years ago

invalidtask commented 5 years ago

What is the proper way to retry if failed to fill/impression due to no available ad inventory? If I call loadAds when adError event is triggered it causes a memory increase (leak?) with each call of loadAds.

radiantmediaplayer commented 5 years ago

Listening to adError event and then calling loadAds again is the proper way to waterfall through different VAST tags. I am not aware of any memory usage issue when doing so but we will run benchmark when time permits. Can you share your player code configuration so we can try to replicate the issue you are seeing?

invalidtask commented 5 years ago

I used the autoplay example provided: https://gist.github.com/invalidtask/78efd73f330d9e00427013fe76337b83

radiantmediaplayer commented 5 years ago

So I managed to find some time to look into it further. I used Task Manager from Chrome dev tools for a quick analysis. I ran the exact code you provided (e.g. make a new ad request every 3s). I used https://www.radiantmediaplayer.com/vast/tags/empty.xml as a VAST tag since your request pertains to repeated ad request made in the instance where no ad inventory is available. I ran test ~ 5 minutes and made a total of 108 ad requets with loadAds API method, taking logs every 30s. Memory footprint (KB) - JavaScript Memory (Live KB) 73144 - 4879 77128 - 4956 76200 - 5067 74936 - 5200 74036 - 5300 71352 - 5411 73676 - 5554 74916 - 5677 77524 - 5787 79012 - 4971 <--- Chrome automatic garbage collection happened around here 71560 - 5110 69080 - 5124 <--- stop making ad requests 70356 - 5138 70516 - 5152 70560 - 5168 70576 - 5181

As you can see there is not much to wistness about a potential memory leak, while there is indeed signs of a small increase in memory over repeated used of loadAds, the fluctuation in time and automatic garbage collection seem to indicate that this is not an issue for the viewer or Chrome.

radiantmediaplayer commented 5 years ago

I ran another test - this time I am calling a valid VAST tags every 3 empty VAST responses. I ran the test for 10 minutes and made 101 ad request with loadAds (every 4s a call to loadAds is made) in total, taking logs every 30 seconds: Memory footprint (KB) - JavaScript Memory (Live KB) 55952 - 4880 53692 - 5019 54340 - 5129 54744 - 5184 55444 - 5239 55896 - 5309 54964 - 5405 56360 - 5473 56488 - 5570 55792 - 5639 57780 - 5742 58288 - 5805 58464 - 5034 <--- Chrome automatic garbage collection happened around here 58756 - 5097 59188 - 5187 58240 - 5208 60028 - 5297 60031 - 5044 <--- Chrome automatic garbage collection happened around here 61704 - 5126 <--- stop making ad requests 61956 - 5138 62128 - 5152 62428 - 5164

So far I am not seeing any indication of any significant memory usage issue while repeating using loadAds API method. Closing now. Feel free to re-open if you have more/different results to provide along with context upon which you obtained those results.