0

We have a fleet of more than 50,000 vehicles in the country and we are going to track our vehicles using gps devices (not mobile devices) fixed in the vehicles, the location will be received by the tcp server, by specifying ip and port of the server.

One of the main requirements is concurrent connections, every vehicle will update its location every minute, so can somebody experienced in writing a TCP server, based on 50,000 vehicles, tell me how much concurrent connections I can receive (just an idea) at any time. How can I test it , I mean how can I load test my tcp server.

If you are aware of any .net library which can be helpful then please guide, I have seen IPDaemon from www.nsoftware.com, and they are claiming

By default, each instance of IPDaemon can handle up to 1,000 simultaneous incoming connections (this number may be increased up to 100,000 or decreased to a lower value by using the MaxConnections configuration setting).

So I am confused and appreciate experienced fellow advice on this.

Thanks

Allmighty
  • 1,499
  • 12
  • 19
Shax
  • 4,207
  • 10
  • 46
  • 62
  • Do you mean if 50k vehicles will send a data every minute how many avarage connections does that mean at any time? You can take 50000/60 for connections per second considering that receiving data will take 1 sec and they send data every minute which is 833 concurent connections per second. Ofcourse this is the mean number to be save i would say take 5x that. – Vajura Oct 27 '14 at 07:51
  • @Vajura, yes you understood write I am asking about the average concurrant connections. – Shax Oct 27 '14 at 07:54
  • then you can take that reccomendation, if the cars arent synced in any way then that should be the result, i also think that the concurent connections should never be higher then 1500 – Vajura Oct 27 '14 at 08:00
  • @Vajura, you mean in my case concurrent connectins should not be hire than 1500 or are you talking about in general? Also, how can I load test it, any idea ? – Shax Oct 27 '14 at 08:05
  • You could also use my free open source alternative: http://blog.gauffin.org/2014/05/griffin-framework-performant-networking-in-net/ – jgauffin Oct 27 '14 at 08:44
  • 1
    It must be tempting to use a connectionless protocol like UDP for this. Opening and closing TCP connections to transfer a vehicle ID and GPS coords seems to me to be a massive added latency for very little gain. – Martin James Oct 27 '14 at 12:11
  • 1
    Testing: develop a mobile phone app first. Ask one driver to run it on his/her peronal smartphone for a month, (eg. by offering to pay for all their calls). Get that working and check the billing to find out how much is costs. Get that down by fiddling with the protocols etc. When that's done, incentivise more drivers to run it on their phones until sufficient quality has been achieved to roll it out to the dedicated hardware on your entire fleet. – Martin James Oct 27 '14 at 12:25

5 Answers5

0

If the only thing you need to send is a position and some metadata, go with a simple HTTP server. There are plenty of them in the market, and most are really efficient: managing 50 000 clients should not be a problem, it's not such a high number.

I recommend you do not reinvent the wheel or use anything too complicated. A simple ASP.NET MVC application should do the trick.

Falanwe
  • 4,636
  • 22
  • 37
  • these are devices, how they will use HTTP, like if I create REST API, how I will assign to the devices, these are not mobile phones. The other thing is that HTTP response and Request headers create burden on the data, which will eat up the data allowed on the sim card. what you say on this please? – Shax Oct 27 '14 at 08:12
  • My say is that TCP also adds burden on the data, so you should use UDP. No wait, that adds burden too, so you should create your own lightweight protocol! Seriously, these protocols are not as heavy as you think, and there are very few cases where it could be a real problem. You might be in one of these cases, but it's unlikely. – Falanwe Oct 27 '14 at 11:19
  • @Falanwe - the issue is that a TCP connection requires 7 handshakes to open and close the connection. On top of that is the trivial amount of payload data - a vehicle ID and GPS coords. I, too, suspect that a connectionless protocol like UDP would be better. for this requirement. – Martin James Oct 27 '14 at 12:17
  • @MartinJames : I agree. Either the additionnal costs of high-level protocols are really a problem in your case, so you should be as low level as possible (probably using UDP). Or these costs are not so dire for you and you should be as high level as possible (probably using HTTP/HTTPS). I don't see much room for being in between those 2 (HTTP-less TCP) – Falanwe Oct 27 '14 at 14:09
0

Avoid keeping a thread per connection, and instead use the Asynchronous Programming Model. That means using methods like BeginConnect(), BeginRead() andBeginWrite() along with their corresponding EndXXX methods, instead of the blocking alternatives.

This way, only a handful of thread pool threads will be used internally by the application, so it can scale much better. You might have 50,000 calls to BeginRead(), but if only 10 of the connections are actually receiving data at the moment, then you will have up to 10 threads handling them (just giving an example).

I don't know how far up it can scale... an update per minute doesn't sound particularly heavy, but you will have to test it to see whether it can withstand the load.

See this or this for examples of how to write asynchronous socket servers in C#.

Community
  • 1
  • 1
Gigi
  • 28,163
  • 29
  • 106
  • 188
  • If .NET 4.5 is used I would recommend the Async methods instead. i.e. ConnectAsync, WriteAsync etc. They are not based on TPL but the underlying IO completion ports model. Hence less waste of resources compared to the Begin/End type of methods. – jgauffin Oct 27 '14 at 08:40
  • async methods aren't good for concurrency; they are intended for a single asynchronous operation. – Gigi Oct 27 '14 at 08:46
  • Didn't you read what I said? The socket methods are NOT based on TPL. i.e. the do not return a `Task`. They wrap IO Completion Ports which are exposed by WinAPI. – jgauffin Oct 27 '14 at 08:48
  • So? How do you go about waiting for results from 50k connections if you await each one? – Gigi Oct 27 '14 at 08:50
  • Why don't you start by reading the documentation at MSDN instead of basing your comments on assumptions? For the third time: They are not based on TPL. You do NOT `await` them. – jgauffin Oct 27 '14 at 08:52
  • Chill, kid. You might like to point me to the article in question if you're so convinced of this. – Gigi Oct 27 '14 at 09:06
  • Allow me to serve you the link to `Socket.ReceiveAsync` at MSDN: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.receiveasync(v=vs.110).aspx. And here is the documentation for IO Completion Ports: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx. Here is a SO question on the subject: http://stackoverflow.com/questions/7237670/net-async-sockets-any-benefit-of-socketasynceventargs-over-begin-end-in-this-s. Ok now? – jgauffin Oct 27 '14 at 09:23
  • Wow, friends relax, no need to get harsh.....huge respect to both of you because you are more knowledgeable than me...:) – Shax Oct 27 '14 at 11:13
  • 1
    I'm relaxed. It's just a bit frustrating to have to repeat myself when all he could have done was to read MSDN to understand what I'm saying. :) The async methods works better for you in this case, since there are a lot less allocations and resources used. – jgauffin Oct 27 '14 at 11:30
  • @jgauffin, I am reading your suggested links along my research and yes I agree with you – Shax Oct 27 '14 at 11:32
  • I also commented the question with my own alternative to the library you mentioned. My library also uses the async methods and you get a couple of thousand requests per seconds with it. I do offer commercial support if you are interested. – jgauffin Oct 27 '14 at 11:37
0

The concurent connections should never be higher then 1500 (99.99%). There is no real way to load test it other then doing it on the actualy system. Its a math problem and you can solve it as such.

You have 50000 cars that send a signal every 60 seconds that lasts 1 second(probably less, which will result in even less concurent connections). Since the sending of the signal isnt synced (the cars arent sending the signal all at the same time, i assume) so they will be more or less arranged like so that you will get 833 connections per second which is 50k/60. Now lets say you get "unlucky" and 2000 cars get turned on on the same time (or exactly 60 seconds apart) then you will get 2000 concurent connections for the time those cars are turned on which is extremly unlikely. As i said you can take a 1500 concurent connections as your max but to be really save increase it to 3000 or 4000 which should never happen.

This is all considering that the computer will take 1 second to resolve one signal and in reality this time should be closer to 0.1 sec or even lower which would result in 10 times less concurent connections so my real guess of absolute max concurent connections to be around 500.

Vajura
  • 1,112
  • 7
  • 16
  • 2
    How can this be an accepted answer? It's so wrong in so many ways. Why should you never have more than 1500 concurrent connections in the first way? Where do those numbers come from? You can't simply take any numbers, do some magic math and say those are limits. There is no problem with having 50.000 **concurrent** connections in C# with properly designed server code. If each GPS transmission only lasts for example 10 seconds, and every transmission makes it own connection for that period only, you can easily handle something like 250.000+ sources, given some "not so tight" timeout handling. – Num Lock Mar 27 '15 at 10:06
-1

If .Net is not a hard requirement, i suggest you look in to NodeJs It is pretty lightweight and is getting pretty developed.

And as Falanwe said, 50.000 connections per minute is not that much if it is only Location data they are sending. This is basicly limited by your bandwidth. Not much the service on the computer.

Magic-Mouse
  • 603
  • 10
  • 21
-1

I think your biggest challenge is not the TCP connections to the GPS trackers but the database handling. The amount of data you will have when you save all the location data for 1 year is massive. And the performance of the database server will be very important.

Also: how will you manage, and what will you do with al the data you collect? You will need to create smart notifications and data filters to extract the data you need for managing your fleet.

I have a lot of experience with setting up GPS tracking servers & managing fleets. If you have questions feel free to contact me.

Jarno de Vries
  • 1