OrientDB Performance Tuning - OrientDB

What is OrientDB Performance Tuning?

In this chapter, you may get a few general suggestions on a way to optimize your application that uses OrientDB. There are three methods to increase the performance for special types of database.

  • Document Database performance Tuning − It uses a way that allows avoid file creation for each new file.
  • Object Database performance Tuning − It uses the common techniques to improve performance.
  • Distributed Configuration Tuning − It uses special methodologies to improve performance in allotted configuration.

You can achieve common performance tuning through changing the memory, JVM, and remote connection settings.

Memory Settings

There are special techniques in memory placing to improve performance.

Server and Embedded Settings

Those settings are valid for each Server aspect and the JVM in which the Java application is run using OrientDB in Embedded mode, through directly the use of plocal.

The most important thing on tuning is assuring the memory settings are correct. What can make a actual difference is the right balancing between the heap and the digital memory used by memory Mapping, particularly on huge datasets (GBs, TBs and more) in which the inmemory cache systems count less than raw IO.

For example, if you may assign most 8GB to the Java method, it's generally better assigning small heap and huge disk cache buffer (off-heap memory).

Try the following command to increase the heap memory.

The storage.diskCache.bufferSize placing (with old "local" storage it turned into file.mmap.maxMemory) is in MB and tells how much memory to use for Disk Cache aspect. through default it is 4GB.

Note − If the sum of maximum heap and disk cache buffer is just too high, it could cause the OS to swap with huge slowdown.

JVM Settings

JVM settings are encoded in server.sh (and server.bat) batch files. you may change them to tune the JVM in step with your usage and hw/sw settings. add the following line in server.bat file.

This setting will disable writing debug data about the JVM. in case you need to profile the JVM, simply get rid of this setting.

Remote Connections

There are many methods to improve performance when you access the database the usage of a remote connection.

Fetching strategy

When you work with a remote database you need to take note of the fetching method used. by using default, OrientDB consumer loads best the file contained in the resultset. for example, if a question returns 100 elements, but if you cross those factors from the client, then OrientDB consumer lazily masses the factors with one extra network name to the server for each missed file.

Network Connection Pool

Every client, by default, makes use of only one network connection to talk with the server. multiple threads on the equal client share the equal network connection pool.

When you have multiple threads, there can be a bottleneck because a lot of time is spent waiting for a free network connection. that is the motive why it is crucial to configure the network connection pool.

The configuration is very simple, just 2 parameters −

  • MinPool − it is the initial length of the connection pool. The default value is configured as global parameters "customer.channel.minPool".
  • MaxPool − it is the most length the connection pool can reach. The default value is configured as global parameters "client.channel.maxPool".

If all of the pool connections are busy, then the purchaser thread will await the first free connection.

Example command of configuration by using using database properties.

Distributed Configuration Tuning

There are many methods to improve performance on allotted configuration.

Use Transactions

Even when you update graphs, you need to usually work in transactions. OrientDB permits you to work outside of them. common instances are examine-best queries or huge and nonconcurrent operations may be restored in case of failure. when you run on allotted configuration, the use of transactions allows to reduce latency. that is because the allotted operation happens best at commit time. distributing one huge operation is plenty efficient than transferring small multiple operations, because of the latency.

Replication vs Sharding

OrientDB allotted configuration is about to full replication. Having multiple nodes with the equal copy of database is crucial for scale reads. In reality, each server is independent on executing reads and queries. if you have 10 server nodes, the study throughput is 10x.

With writes, it is the other: having multiple nodes with full replication slows down the operations, if the replication is synchronous. In this example, sharding the database across multiple nodes permits you to scale up writes, because only a subset of nodes are concerned on write. furthermore, you may have a database bigger than one server node HD.

Scale up on Writes

If you have a sluggish network and you have a synchronous (default) replication, you may pay the price of latency. In reality when OrientDB runs synchronously, it waits at least for the writeQuorum. this means that if the writeQuorum is three, and you have 5 nodes, the coordinator server node (in which the allotted operation is started) has to wait for the solution from as a minimum 3 nodes so that you can offer the solution to the client.

In order to preserve the consistency, the writeQuorum need to be set to the majority. if you have 5 nodes the majority is 3. With 4 nodes, it is still 3. setting the writeQuorum to 3 instead of 4 or 5 permits to reduce the latency price and still hold the consistency.

Asynchronous Replication

To speed things up, you may set up Asynchronous Replication to remove the latency bottleneck. In this example, the coordinator server node executes the operation regionally and gives the answer to the client. The complete replication could be inside the background. In case the quorum is not reached, the adjustments could be rolled back transparently.

Scale up on Reads

If you already set the writeQuorum to the majority of nodes, you can go away the readQuorum to 1 (the default). This speeds up all the reads.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

OrientDB Topics