Roadmap
This roadmap aims to be a sort of "memorandum" of things that are likely to be implemented and/or fixed in the near future or for which it has been determined a specific release date.
At any time the dev team could change one of many of those dates due to unforeseens of techincal or personal nature.
The object_pool_allocator branch will introduce a new allocation policy for gbItem structures, reusing previously freed ones ( such as manually deleted or expired objects ) instead of allocating new ones.
It also allocates contiguous blocks of such structures to reduce memory fragmentation issues.
The main performance gains will be:
- Faster item allocation ( NOTE: make a specific benchmark for this, such as a lot of different SETs )
- Less memory fragmentation due to contiguous blocks.
- Improved data locality, even if the gbItem structure is not "L1 cache centric".
Tasks:
- Implement specific benchmarks to prove the performance improvements.
- Implement specific tests for this, such as internal object count, STATS command verification before and after an allocation, etc.
- Migrate tests from php to ruby for a better checking of the protocol internals.
- Test the branch in the stage environment for at least a couple of weeks.
Currently those operators support only a delta of 1 ( i.e. to increment key "foo" by 5 you need to call "INC foo" five times ), we should introduce a new optional ( to guarantee back compatibility of the protocol ) "incr by" parameter that will determine of how many units increment the value.
Tasks:
- Implement "delta" optional parameter for INC, DEC, MINC, and MDEC operators.
- Make specific tests.
- Benchmark those operators to check for any regression on performances.
There's the need of new arithmetic operators for multiple numeric keysets such as SUM, AVG, etc. The technical details are still to be discussed.
Implement (optional?) data persistance. The best approach for this would be to log every query of the user that would create/modify a specific key or key set to a (binary) file periodically and then "execute" that file ( if present ) while booting. Together with the previous two entries in the roadmap this will make Gibson a great tool for realtime hierarchical web analytics. Again, technical details are yet to be discussed.
Options:
- Make the data persistance configurable but global ( valid for every key instance in the server ).
- Create a set of operators to enable or disable data persistance for multiple keysets.
- ???