High frequency event handling in VB.NET
I'm working with a market data feed API in VB.NET. API is written is written in C#.
This API calls a method in one of my classes to signal when an event such as a price tick or a trade arrives on a TCP socket. This can happen upwards of 10,000 times per second. After the event comes in, the data is converted from a byte stream into data structures and the data structures are used in a pricing model.
Each event can take a couple ms to process, so multi-threading is probably necessary. If events are not processed in time, they queue up, but this is extremely undesirable, so we want to process events without them backing up.
I wanted to gather your thoughts on the do's and don't of processing this many events. For example, should I use the ThreadPool.QueueWorkItem or should I build my own threadpool?
Has anyone used ThreadPool.QueueWorkItem for so many small work items?
If I build my own threadpool, the approach that makes sense is to create a wrapper for the thread, and suspend the thread. When an event arrives, put the data into the wrapper and call resume() to make the thread process the event. Once the processing is complete, do another suspend() because once a thread dies, it cannot be restarted.
If I build my own threadpool, what is the overhead of doing suspend/resume so frequently? What have been your experiences with having many threads going on and off at the same time?
Thanks in advance
This API calls a method in one of my classes to signal when an event such as a price tick or a trade arrives on a TCP socket. This can happen upwards of 10,000 times per second. After the event comes in, the data is converted from a byte stream into data structures and the data structures are used in a pricing model.
Each event can take a couple ms to process, so multi-threading is probably necessary. If events are not processed in time, they queue up, but this is extremely undesirable, so we want to process events without them backing up.
I wanted to gather your thoughts on the do's and don't of processing this many events. For example, should I use the ThreadPool.QueueWorkItem or should I build my own threadpool?
Has anyone used ThreadPool.QueueWorkItem for so many small work items?
If I build my own threadpool, the approach that makes sense is to create a wrapper for the thread, and suspend the thread. When an event arrives, put the data into the wrapper and call resume() to make the thread process the event. Once the processing is complete, do another suspend() because once a thread dies, it cannot be restarted.
If I build my own threadpool, what is the overhead of doing suspend/resume so frequently? What have been your experiences with having many threads going on and off at the same time?
Thanks in advance
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I can probably deploy an array of these queues to process the events.
I'm still curious whether it would be just as effective to throw all of these events into the ThreadGroup that the CLR makes available to me. Does anyone have experience with ThreadGroup ?