开云体育

What type of speed improvements are you looking for? When most people talk about speed and trading they are trying to achieve a specific latency outcome, ie completion of a given operation within a bounded amount of time. That's different from say the 99th percentile completion time, where outliers are of minimal consequence (eg batch applications, web applications etc).

IB Gateway, TWS and IB Controller are JVM hosted applications that cannot be embedded within your own application (ie you can't run them in the same process). In addition, IB Gateway and TWS are closed source applications where you cannot look at (let alone improve) their threading, network use, object allocations/deallocations, retry/timeout mechanisms and so on. You're limited to using the provided wire level APIs (ie IB API or FIX). Assuming you need to use IB Gateway, the most you can do is (a) adjust JVM properties and (b) consider non-JVM issues.

First, the good news. In general the easiest way to obtain the best performance for almost any Java application is to upgrade to the latest released JVM. As an aside the new Install4J-based distribution of TWS 954 bundles Java 1.8.0_65, which is pretty close to the latest (1.8.0_66 is ).

Actual JVM configuration is also quite easy, although unlikely to help. That's because most JVM configuration latency wins come from adjusting memory management and JIT compilation settings. IB Gateway does not use a large amount of heap relative to normal Java applications. If you needed an 8+ GB of heap to run IB Gateway, tuning the garbage collector may prove useful. However for a few hundred megabytes (like IB Gateway uses) it isn't going to make much difference (and in many cases it's likely to actually be worse than using the defaults that Oracle have selected based on CPU class, memory size and operating system). The hotspot options can also control exactly when the JVM inlines certain methods. Like a (PGO) build for languages like C++, there's a requirement to wait for enough workload to complete so the routine code paths can be profiled (ie "warm up" the JVM). Doing it too soon (and there are JVM arguments that force it to happen immediately etc) and you will actually end up with worse performance than the default bytecode execution. But given IB Gateway is mostly a converter between local wire formats (IB API / FIX) and a proprietary wire format (to the IB backend), you are almost certainly going to be blocking on network IO as opposed to CPU or memory use.

If you are wanting to play around with JVM options anyway, I assume your IBController install is based off the batch file. In that batch file is the JAVAOPTS setting. There's room for improvement, for example -XX:MaxPermSize option is now deprecated in Java 8, as the permanent generation has been removed (see in Java 8). What's an appropriate value? Well as of TWS 954 the officially-provided Install4J launch doesn't set any memory options for Java. So if you do anything to your JAVAOPTS, I'd be removing them unless benchmarking shows they're useful. A nice introductory book if you want to dig into JVM performance tuning is Scott Oak's . It covers you to use included JVM tools (eg visualvm, jcmd, jinfo, jstack etc) to get a better idea what's happening in your JVM and start tuning away. But again, you're extremely unlikely to gain very much improvement for IB Gateway.

The biggest opportunity for meaningful latency improvement is likely to come from other techniques that have been mentioned on this list at various times. They basically boil down to order tuning, connection tuning and machine tuning:

* Place orders away from the market price so that risk management checks have already been completed, then modify the order when ready to invoke.

* Profile and control order routing (SMART vs directed orders). Note the execution price, liquidity rebate/charge and commissions though.

* Colocate nearer IB. Commercial data centre hosting will have lower average latencies than SOHO connections.

* Buy a commercial-grade, dedicated network connection to IB. Check out .

* Reduce load on IB Gateway by not using it for market data. Specialist data vendors offer hyper-compressed, UDP-delivered feeds (eg Nanex).

* Typical OS-level issues: latest versions, patches, malware/virus/privacy scanner settings, unnecessary services, network settings, swap config etc.

The above isn't a complete list by any stretch. I've personally found minimal latency issues during realtime trading. To be using IB in the first place effectively rules out most low latency strategies.

If you can expand on the specific speed improvements you're looking for, others might be able to chime in with more suggestions.