Leveraging the differences that ActiveSpaces has from a database.
Article ID: KB0093659
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveSpaces | - |
| Not Applicable | - |
Description
Resolution:
If you are going to do a read for ‘key= some value’, then you should use
a ‘get’ operation rather than a query. Get operations will always be
noticeably faster than a query.
If you are doing a query for ‘key<some value’, then you want to make sure you have an index to help this query if you want to get the lowest possible latency. Since its a range query, you want to make sure it’s a ‘TREE’ index. So either define a secondary TREE index on the key field or change the default key index type from HASH to TREE.
Default index type would be HASH for the example unless it is modified. Range query will not benefit from
the index unless it is TREE type.
- If the query will return a lot of records, then prefetch and query limit can have an influence on latency.
- Try using a time scope of CURRENT rather than SNAPSHOT for your query. This can also affect latency
Part
of the latency in a query (any operation performed from a leech
application) includes the latency of making a round trip over the
network to the seeder(s) process. If you run your client leech
application on the same machine as the seeder processes, you will get lower latency.
You may also want to run
more than one as-agent (seeder) process to distribute the load more and
use more cores (Example: if you have eight cores on the machine then you may
want to run six or so seeder agents to leverage all of the cores if you
are only going to do queries on a single space.
Issue/Introduction
Leveraging the differences that ActiveSpaces has from a database.
Additional Information
Feedback
Yes
No
Powered by
