How many symbols/timeframes can be supported, practically?

[heech]

Hi,

I asked a variant of this question before, but am back to gather a little more info/opinion now that I understand better what I'm doing.

I'm curious what kind of *computer* performance other traders are getting... any volunteers out there, and/or, NinjaTrader folks have any feedback?

Basically: what's the most number of symbols that are being traded/analyzed simultaneously? I'm not doing tick, but I do have some code in OnMarketUpdate().

1) I'm okay right now at 50 symbols (in one strategy), system seems to be running fine; will I be okay at 100 symbols? 200? 500? Does anyone out there actually run with 100+ symbols? (And this applies to IB, by the way.)

2) Dierk, can you comment on how NT is implemented from a threading point of view? Is there a bottleneck/cap on threads? I'd like to understand how I should handle growth as I scale up the number of symbols... would you recommend adding:

- more "strategy" instances. (I can split it up so strategy instance 1 handles 50 symbols, strategy instance 2, etc...) If strategy has its own thread pool w/ hard-coded thread limit, this might make sense.

- more NinjaTrader/PCs. If each NinjaTrader only has a fixed number of threads running through the strategies, maybe I should just invest in another computer + NT license. Each instance of NinjaTrader can run with 50 symbols, for example.

Thanks, any advice would be useful.

[NinjaTrader_Dierk]

1) Sorry, but you would need to try on your own. The actual load would depend your actual setup. We just could not provide recommendations there.
2) The NT threading model is irrelevant here, since all realtime handling for all NinjaScript objects is done in the same (main) thread.

[heech]

1) Sorry, but you would need to try on your own. The actual load would depend your actual setup. We just could not provide recommendations there.

Just having a rough idea would be helpful... I'm using a pretty juiced up system. I'm just curious if you know of *anyone* who's using a strategy in the hundreds.

2) The NT threading model is irrelevant here, since all realtime handling for all NinjaScript objects is done in the same (main) thread.

I had noooo idea. So, that more or less means I'm wasting my time with my lock statements. I thought I had read mentions in the past about being careful with "race conditions", and I assumed that meant things were multi-threaded.

Just to be clear: ALL REAL TIME HANDLING across ALL strategies/charts are done in the same thread?

I guess that suggests I really will have to launch multiple copies of NinjaTrader, if performance slows down substantially. Will you guys make me a deal if I buy more licenses?

Can anyone out there recommend profiling tools/libraries for stuff code running in NT...? I'd like to see what's taking up time.

[NinjaTrader_Dierk]

1) I suspect you could hit the wall with hundreds of instruments
2) Yes, all real time NinjaScript logic is in the same (main) thread. Note: that has nothing to do with lots of other logic/code performed on separate threads in the background.

[heech]

1) I suspect you could hit the wall with hundreds of instruments
2) Yes, all real time NinjaScript logic is in the same (main) thread. Note: that has nothing to do with lots of other logic/code performed on separate threads in the background.

Any hope this architecture will get better with NT 7?

I would even consider setting up my own thread pool... but I'm guessing your back-end isn't thread safe. Ie, if I start making calls to EnterLong() from different threads in parallel, your code breaks down.

[NinjaTrader_Dierk]

This has nothing to do with "good" or "bad" architecture. It's just an easy-so-use model for the majority of our users (you e.g. could not drive any UI related code in a non-main thread). But this now really goes beyond what we could cover on this support forum. However, MS docs would have details available on the Windows architectural limitations.

Again, this has nothing to do with the multi-thread model which NT is built on which of course if thread safe.