Backtesting
Deployment
Introduction
Deploy a backtest to simulate your trading algorithm on our cloud servers. Since the same Lean engine is used to run backtests and live trading algorithms, it's easy to transition from backtesting to live trading once you are satisfied with the historical performance of your algorithm. If you find any issues with Lean, the historical data, or the website when running backtests, we'll resolve the issue.
Nodes
Backtesting nodes enable you to run backtests. The more backtesting nodes your organization has, the more concurrent backtests that you can run. Several models of backtesting nodes are available. Backtesting nodes that are more powerful can run faster backtests and backtest nodes with more RAM can handle more memory-intensive operations like training machine learning models, processing Options data, and managing large universes. The following table shows the specifications of the backtesting node models:
Name | Number of Cores | Processing Speed (GHz) | RAM (GB) | GPU |
---|---|---|---|---|
B-MICRO | 2 | 3 | 8 | 0 |
B2-8 | 2 | 4.9 | 8 | 0 |
B4-12 | 4 | 4.9 | 12 | 0 |
B4-16-GPU | 4 | 3 | 16 | 1/3 |
B8-16 | 8 | 4.9 | 16 | 0 |
Refer to the Pricing page to see the price of each backtesting node model. You get one free B-MICRO backtesting node in your first organization. This node incurs a 20-second delay when you launch backtests, but the delay is removed and the node is replaced when upgrade your organization to a paid tier and add a new backtesting node.
To view the status of all of your organization's nodes, see the Resources panel of the IDE. When you run a backtest, it uses the best-performing resource by default, but you can select a specific resource to use.
The CPU nodes are available on a fair usage basis while the GPU nodes can be shared with a maximum of three members. Depending on the server load, you may use all of the GPU's processing power. GPU nodes perform best on repetitive and highly-parallel tasks like training machine learning models. It takes time to transfer the data to the GPU for computation, so if your algorithm doesn't train machine learning models, the extra time it takes to transfer the data can make it appear that GPU nodes run slower than CPU nodes.
Concurrent Backtesting
Concurrent backtesting is the process of running multiple backtests at the same time within a single organization. Concurrent backtesting speeds up your strategy development because you don't have to wait while a single backtest finishes executing. You need multiple backtesting nodes in your organization to run concurrent backtests. The more backtesting nodes that your organization has, the more concurrent backtests you can execute. If you are trying to fine-tune your parameters, consider running a parameter optimization. If you run a parameter optimization job, you can run multiple backtests concurrently without having multiple backtest nodes.
The number of backtesting nodes that you can have in your organization depends on the tier of your organization. The following table shows the backtesting node quotas:
Tier | Node Quota |
---|---|
Free | 1 |
Quant Researcher | 2 |
Team | 10 |
Trading Firm | Unlimited |
Institution | Unlimited |
Logs
The amount of logs you can generate per backtest and per day depends on the tier of your organization. The following table shows the amount of logs you can generate on each tier:
Tier | Logs Per Backtest | Logs Per Day |
---|---|---|
Free | 10KB | 3MB |
Quant Researcher | 100KB | 3MB |
Team | 1MB | 10MB |
Trading Firm | 5MB | 50MB |
Institution | Inf. | Inf. |
To check the log storage space you have remaining, log in to the Algorithm Lab and then, in the left navigation bar, click Organization > Resources.
Security
Your code is stored in a database, isolated from the internet. When the code leaves the database, it is compiled and obfuscated before being deployed to the cloud. If the cloud servers were compromised, this process makes it difficult to read your strategy.
As we've seen over recent years, there can never be any guarantee of security with online websites. However, we deploy all modern and common security procedures. We deploy nightly software updates to keep the server up to date with the latest security patches. We also use SSH key login to avoid reliance on passwords. Internally, we use processes to ensure only a handful of people have access to the database and we always restrict logins to never use root credentials.
See our Security and IP documentation for more information.
Build Projects
If the compiler finds errors during the build process, the IDE highlights the lines of code that caused the errors in red. Your projects will automatically build after each keystroke. To manually build a project, open the project and then click the icon. If the build process is unresponsive, try refreshing the page and building again. If the build process continues to be unresponsive, check our Status page or contact us.
Run Backtests
To run a backtest, open a project and then click the Backtest icon. If the project successfully builds, "Received backtest backtestName request" displays. If the backtest successfully launches, the IDE displays the backtest results page in a new tab. If the backtest fails to launch due to coding errors, the new tab displays the error. As the backtest executes, you can refresh or close the IDE without interfering with the backtest because it runs on our cloud servers. The backtest runs up to the start of the out-of-sample hold out period.
Stop Backtests
To stop a running backtest, open the Resources panel, and then click the stop icon next to the backtest node. You can stop nodes that you are using, but you need stop node permissions to stop nodes other members are using.
Runtime Quota
The maximum amount of time a backtest can run for is 12 hours. The runtime depends on the amount of data, the algorithm features and computations, and the backtest node type.