I've made some adjustments to VRS 2.4.2 Global Radar View. All 30 servers will accept only 10 concurrent connections each. I've been experimenting with 50, 20, and finally trying 10. There may or may not be some slowness during peak times - though I think they should be able to serve responses 'faster' with less concurrency smashing CPU cycles. This doesn't mean that only 300 people can view the map, it means the VRS web server will only have to deal with a constant 10 requests at a time and will queue the rest. Giving VRS additional CPU cores or more GHz did not help, so trying to restrict requests is the next step. This may or may not fix issues with map showing delayed planes. I have not been able to replicate that specific issue and data is near real-time before it gets to servers that publish the Web UI. I suspect it is user related, due to the large file size of the JSON. Detailed reports with screenshots of Chrome developer / Firefox developer window open will be the only users reports I investigate. I can't spend hours chasing my tail to find out someone is trying to use a 10 year old phone to display 3000 aircraft. FYI, that will never work on VRS unless developer makes significant changes to how his map is built and updated. There is a memory leak in VRS 2.4.2 that effects all public endpoints except for TCP. After 24 hours or less - VRS uses 3GB-6GB of memory and zombie crashes. My hope is that until the VRS developer publishes a new update - that reducing the load on the web server will let Mono garbage collection work. This memory issue also exists in 2.4.0. It only affects VRS when serving many clients on the web ui, so it's related to the basic HTTP server in Mono / NET. Post an issues in this thread. ------------- TCP stream is not affected. TCP uses a Go program to handle connections and send JSON data.
Sounds fair to reduce the requests per user to help overall performance for all. RE: the memory leak, I know its not an ideal suggestion but could you schedule an automatic restart of the servers/services perhaps once a day. Either schedule a reboot via cron etc... or perhaps more gracefully drain and disable them from the loadbalancer via the clouds API if applicable. Just a thought.
VRS was not designed to do what ADSBx does with it. It works for a small enthusiast to look at a map of planes but that is about it, and it can't be very many planes. 30 servers, that's enough hardware to service million of requests a second. VRS gets to 500 and buckles. :/ Just for the Web UI, Each plane is rendered as a DOM element using JavaScript and it uses jQuery UI, which has lots of performance issues. I suggested new versions of VRS use a canvas instead of dom elelments, since he is now using Leaflet (https://leafletjs.com/). VRS server wise it uses .NET/Mono basic http library, thus it is a turd in a dumpster that is on fire. What I would like to do is front it with Apache or NGINX and in-memory cache the json. Serve all the flat files and images with a proven webs server with concurrency and implement the filters people use with the map with go/php/nodejs. The problem will be unless I fully recreate the filters, there will be a shit storm of nasty emails and capital letters will be abused. I think we might have to settle for a subset of the overlapping, basically unused features and implement it. If someone doesn't like the web map then they can install their own VRS and connect to the TCP stream.
I have my own VRS, where can I find the connection parameters (URL/port/format) and will this work with custom feeds?
VRS feed is not the best way, if you really want to feed from VRS follow link posted by Steven Gaj. New range of free VRS ports was published by James on this forum.
Well, I'm already feeding ADSBx from PiAware so feeding from VRS is useless, I just want to feed ADSBx to VRS and this seems to be explained in the 'Feed Live Data to your own VRS Installation' section. I do wonder if VRS will request JSON data continuously or will it stop doing this while there are no connections to the web server?
VRS feed is expecting VRS compressed data format. If you select any other format your IP probably will be blocked.
Oh you want to connect to ADSBx TCP feed? Our sever will continually send data to your VRS even if you are not looking at it but VRS is running. It's a stream of data, always on, all the time. Setup a reciever in VRS that connects to pub-vrs.adsbexchange.com and on of the ports. Port 32001 – 1 second updates (realtime) Port 32005 – 5 second updates Port 32010 – 10 second updates Port 32015 – 15 second updates Port 32030 – 30 second updates BE AWARE: The server will ban your IP if your connection can't handle the bandwidth and it fills the TCP buffer multiple times. Start with 5 second or 10 second updates. The 1 second update is a lot of data. It will swamp a 100Mbps connection. Also be sure you are not merging the ADSBx TCP feed into the rest of your feeds and sending it back to ADSBx. That will get your IP instantly banned at the proxy server. Since you aren't feeding with VRS, then probably not an issue.
I have my VRS set up with a 10 second feed, the map displays ok but there is often quiet a few call signs missing on the list, the call signs show ok on the standard web feed.Screenshots attached Is that something I have set up incorrectly?
It's the main reason why i haven't used the TCP feed on a regular basis, I'll just have to keep to the web feed
It seems if you leave VRS running long enough (more than 1 hour) the callsigns fill in. I now keep it running all though the day, I hope that won't cause a problem to ADSBx - but it saves me accessing the web server
