How can I make my application behave well while monitoring hundreds of real-time devices?

I need to develop a real-time (i.e., info is requested and received at least once per second) monitoring application in Delphi, which monitors multiple remote devices (can be hundreds). The communication is via TCP/IP.

I am looking for advice to develop this app avoiding 100% CPU consumption and minimizing the amount of RAM used. In other words, I want my application to remain responsive and not block the system or consume all resources.

My main concern is about using threads for monitoring each remote device. Is there a limit to the number of threads my application can create? Can the threads can be started using a low or开发者_JAVA技巧 medium priority to minimize the CPU consumption?

Advice about optimal memory usage is welcome, too.

Your instinct is right, you want to handle the logging in threads outside of the main thread. Create a simple tcp/ip server that creates a new thread for the incoming connection and handles the logging there. Obviously you'll want to do things like track each thread to be able to terminate it when your server application closes, and possibly implement a thread pool/queue if you want to re-use them rather than constantly creating and destroying them. But what you describe is actually a fairly simple server application in concept. There's no hard and fast limit to the # of threads you can create. But unless the connections are constant and kept open, you may be suprised how few actually get created simultaneously.

Good luck doing this yourself. I have invested a couple of years to develop a generic platform to do just this. If you want you can have a look at it here. At the very least you will need to use some comms components that already work very reliably, such as RemObjects.

I would not use a thread for each device, I'd investigate if a thread can serve a pool of devices, or if a thread pool can be used to dispatch incoming data to the first available thread.

You can check this article about process and thread limits in Windows. Threads can have lower priority, but beware then they can be pre-empted by threads with higher priority, and not being able to read/write data in time. Also too many threads could simply "waste" time if they have nothing to do but the scheduler is forced to give them a slice of time (the thread should be very well behaved to avoid just using it to do nothing). How many threads could be run concurrently without issues strictly depends on the available hardware.

A lot depends on how the data is delivered (is pull or push? have all the data equal priority, or not?) and the process effort once data are read, and how fast the system should react to new data. For example one solution could involve reading data and queueing them for processing, but it couldn't work if the response time should be shorter than the queue could allow.

I would question if you really need threads at all. Best code is the code you don't have to write.

Async - non blocking, event based communication (using ICS, Clever, etc) would be much easier to implement.

What you describe is a client application, threads are generally required for servers. Also 'once per second' is not that frequent even with hundreds of connections.