|
Summary: Helpful recommendations for tuning GigaSpaces, boosting its performance, and improving its scalability.
Overview | Check Your Infrastructure First | Benchmark | Design Your Entries | Make proper use of indexes | Determine Cache Size | Determine Database Connection Pools | Blocking Take and Thread Consumption | Use Batch Operations | Use Transactions Cautiously | Query Optimizations | Use an Embedded Space if Possible | Use Notify Delegator to Retrieve the Entry that Triggered the Event | Use Update Instead of Take and Write | Distribute Data and User Requests among Several Spaces | Controlling Serialization | Visibility of Entries Under Transaction (Dirty Read) | Use NIO Protocol | Memory Usage Considerations | Choose Local Transactions Over Distributed Transactions | Remote GC | Using Snapshot to Reduce Object Creation and Entry Data Inspection | Max Processes and File Descriptors Limit | Tuning Java Virtual Machines
OverviewThis section lists helpful recommendations for tuning the GigaSpaces, boosting its performance, and improving its scalability. Check Your Infrastructure FirstNo matter which kind of optimization you perform, you cannot ignore your infrastructure. Therefore, you must verify that you have the following:
Before you move any system into production we recommend you to make sure the relevant team within the organization reviewing the following: The following config should be reviewed: The following tests should be conducted: BenchmarkThe Benchmark View provides a user interface for benchmarking the space.
Design Your EntriesPay attention to the size of your Entries – do you really need all this information in the space? The bigger your Entries, the longer it takes to move them around, store them to disk, and fetch them back. Consider replacing a heavyweight blob field with a simple string URL, and use it later for fetching on demand. Contact GigaSpaces support for an example of this pattern. If you are using user-defined classes for Entry fields, try efficiently implementing java.io.Externalizable with these classes. This will reduce the amount of data transferred over the network and written/read to/from the database, saving both time and space. Make proper use of indexesGigaSpaces includes a sophisticated built-in indexing module (regardless whether the space is persistent or not) that maintains index list data for each indexed entry class attribute. If you keep a large number of Entries of the same class in a space, consider defining one or more indexes for attributes used with template matching. Defining indexes will improve the read/take/clear operations response time significantly, up to ten to fifty times faster. Remember, indexes influence write/update operations response time, so choose your indexed fields carefully - each index has an overhead. GigaSpaces offers implicit indexing and explicit indexing. Determine Cache SizeWhen using persistent space and reusing data, you must take caching into account. The cache manager caches entries for use and performs an LRU (Least Recent Use) based cleanup on the cache. When searching for an entry, the cache is searched first. Set the cache size to the number of Entries that your environment can reasonably contain as resident in virtual memory. This will prevent unnecessary queries on your database. If you want the cache size to be based on the JVM running the space you may use the memory usage options. Determine Database Connection PoolsWhen using persistent space and a large number of users/threads access the space concurrently, each of them requires a database connection. Set enough connections in the connection pool so that users won't be blocked. You should calculate the number of concurrent requests the space needs to handle based on the number of users that will access the space simultaneously. Blocking Take and Thread ConsumptionWhen performing blocking operations – read or take with timeout >0, it is recommended to set the operation timeout for short durations (5-30 seconds), and not to FOREVER. This allows the space's internal thread pool to balance the different requests without exhausting all pending operations thread pool. The relevant setting as part of the space schema controls the space communication connection thread pool, and the pending operations thread pool size: <lrmi-stub-handler> <min-worker-threads>16</min-worker-threads> <max-worker-threads>500</max-worker-threads> </lrmi-stub-handler> <engine> <min_threads>4</min_threads> <!--maximum threads in engine--> <max_threads>64</max_threads> </engine> Use Batch OperationsBatch operations (writeMultiple, readMultiple, takeMultiple, updateMultiple) perform actions on groups of Entries in one call. Instead of paying a penalty for every entry (remote call, database access, ...) you pay it only once. Try to design your hot spots around batch operations - this can drastically improve your application performance, up to ten to fifty times faster. Use Transactions CautiouslyEach transaction has an overhead. Do not use read under a transaction if you do not have a very good reason to do so. Use non-transactional read instead. This reduces database access for persistent spaces and eliminates transaction locks. If you really need to do some operations inside a transaction, use batch operations with transactions. Query OptimizationsWhen using the or logical operation together with and operations as part of your query (JDBC , JavaSpaces with SQLQuery) you can speed up the query execution by having the and conditions added to each or condition. select uid,* from table where (A = 'X' or A = 'Y') and (B > '2000-10-1' and B < '2003-11-1') would be executed much faster when changing it to be: select uid,* from table where (A = 'X' and B > '2000-10-1' and B < '2003-11-1') or (A = 'Y' and B > '2000-10-1' and B < '2003-11-1') Use an Embedded Space if PossibleIf you access the space from a single JVM, or access it a large number of times from one JVM, use the embedded space mode. This eliminates the overhead of remote calls to the space. The slower your network compared to other resources (for example, a disk), the greater will be the noticeable improvement. Use Notify Delegator to Retrieve the Entry that Triggered the EventIf you want to be notified of certain events and receive the entry that caused a specific event, a regular notify with take is more complex and involves at least one extra call on the space. Using Notify Delegator is easy and efficient. The call to get the entry that caused the event is a local call on the Notify Delegator object in the client JVM. Use Update Instead of Take and WriteIf you need to modify entry data, use update instead of take+ write. This saves you an extra call on the space. Distribute Data and User Requests among Several SpacesA single machine is always limited in the amount of data and user requests it can handle. You can use several spaces in a cluster in order to distribute the load and partial replication that partitions the data. See High Availability Combined with Scalability, for a relevant example. Controlling SerializationYou can control the Entry attributes serialization mode when written/read from the space.
Visibility of Entries Under Transaction (Dirty Read)The JavaSpaces specification defines the visibility of Entries for read operations as follows: a read operation performed under a null transaction can only access entries that are not write-locked by non-null transactions. In other words, entries that were written or taken by active transactions (transactions that have not been committed or rolled back) are not visible to the user performing a read operation. Sometimes it is desirable for non-transactional read operations to have full visibility of the Entries in the space. The dirty read property, once set, enables the read/readIfExist under a null transaction and with the JavaSpace.NO_WAIT timeout parameter, to have this complete visibility. In order to set the dirty read property, set the <dirty_read> tag to true in the configuration file. Use NIO ProtocolIf your application is running multiple threads accessing the space, you should use the NIO LRMI-stub-handler protocol-name instead of RMI. For more details, refer to the Setting Communication Protocol section. Memory Usage ConsiderationsHere are several guidelines to reduce the client and space server memory footprint:
Choose Local Transactions Over Distributed TransactionsDistributed Transactions perform a lengthy 2PC process. Local Transactions, in contrast, perform a 1PC process. If you are performing some operations under a transaction on a single space, use local transactions. The slower your network compared to other resources (for example, a disk), the greater will be the noticeable improvement.
Remote GCThe sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval properties are set by default to 60000 milliseconds (60 seconds). In some cases this might cause the JVM process to slow down every 60 seconds. To reduce the performance impact of redundant GC cycles, increase the interval to be an hour (3600000 milliseconds) both for the space JVM and the client JVM.
Using Snapshot to Reduce Object Creation and Entry Data InspectionWhen using the same template for matching, consider using a snapshot template. A snapshot template is the result object of the JavaSpace.snapshot call. The returned result includes GigaSpaces internal representation of the template object that does not need to undergo any inspection before it is sent to the GigaSpaces server.
Max Processes and File Descriptors LimitLinux has a Max Processes per user as well as the limit of file descriptors allowed (which relates to processes, files, sockets and threads). This feature allows you to control the number of processes an existing user on the server may be authorized to have. ulimit -u unlimited
How do I configure the file descriptors?In /etc/system file descriptors hard limit should be set (8192) and file descriptors soft limit should be increased from 1024 to 8192 as shown below: set rlim_fd_max=8192 set rlim_fd_cur=8192 Edit /etc/system with root access and reboot the server. After reboot, please, run the following in the application account: To change the default value, modify the /etc/security/limits.conf file.
Tuning Java Virtual MachinesGigaSpaces, being a Java process, requires a Java virtual machine (JVM) to run. As part of configuring GigaSpaces, you can fine-tune settings that enhance system use of the JVM. A JVM provides the runtime execution environment for Java-based applications. GigaSpaces can run on JVMs from different JVM providers. When GigaSpaces starts it writes information about the JVM, including the JVM provider information, into this log file and the standard output. Even though JVM tuning is dependent on the JVM provider, general tuning concepts apply to all JVMs.
|
Previous release
Add GigaSpaces wiki search to your browser search engines! (works on Firefox 2 and Internet Explorer 7)
