// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
= Generic Performance Tips

Ignite as distributed storages and platforms require certain optimization techniques. Before you dive
into the more advanced techniques described in this and other articles, consider the following basic checklist:

* Ignite is designed and optimized for distributed computing scenarios. Deploy and benchmark a multi-node cluster
rather than a single-node one.

* Ignite can scale horizontally and vertically equally well.
Thus, consider allocating all the CPU and RAM resources available on a local machine to an Ignite node.
A single node per physical machine is a recommended configuration.

* In cases when Ignite is deployed in a virtual or cloud environment, it's ideal (but not strictly required) to
pin a Ignite node to a single host. This provides two benefits:

** Avoids the "noisy neighbor" problem where Ignite VM would compete for the host resources with other applications.
This might cause performance spikes on your Ignite cluster.
** Ensures high-availability. If a host goes down and you have two or more Ignite server node VMs pinned to it, then it can lead to data loss.

* If resources allow, store the entire data set in RAM. Even though Ignite can keep and work with on-disk data,
its architecture is memory-first. In other words, _the more data you cache in RAM the faster the performance_.
link:perf-and-troubleshooting/memory-tuning[Configure and tune] memory appropriately.

* It might seem counter to the bullet point above but it's not enough just to put data in RAM and expect an
order of magnitude performance improvements. Be ready to adjust your data model and existing applications if any.
Use the link:data-modeling/affinity-collocation[affinity colocation] concept during the data
modelling phase for proper data distribution. For instance, if your data is properly colocated, you can run SQL
queries with JOINs at massive scale and expect significant performance benefits.

* If Native persistence is used, then follow these link:perf-and-troubleshooting/persistence-tuning[persistence optimization techniques].

* If you are going to run SQL with Ignite, then get to know link:perf-and-troubleshooting/sql-tuning[SQL-related optimizations].

* Adjust link:data-rebalancing[data rebalancing settings] to ensure that rebalancing completes faster when your cluster topology changes.