Infinispan memory
by Nguyễn Hồng Nhựt
Hi Infinispan Devs,
I used memcached all time. I am research Infinispan and make a compare with
memcached.
I have just make a memory test between memcached and infinispan to choose
which one better(best memory saved).
I run Infinispan from command line: ./startServer.sh -r memcached -p 4567 (
I am fresh download and run it with no custom any config file)
and also memcached from command line: /usr/bin/memcached -m 1024 -u nobody
-p 11211 -l 127.0.0.1
with testcase 10000 key and every key has value is byte array with
length= 1024
Infinispan : => memory: 58MB
Memcached: => memory: 14MB
with testcase 500000 key and every key has value is byte array with
length= 1024
Infinispan : => memory: 920MB
Memcached: => memory: 565MB
In Infinispan, any config param familiar with memory cost? and how i
can reduce this cost?
thanks and best regards.
13 years, 9 months
Proposing a new extension: Spring Infinispan
by Olaf Bergner
Hello,
this is to propose a new extension, Spring Infinispan, targeted at
implementing Spring 3.1's forthcoming Cache SPI using JBoss INFINISPAN.
Please see the Extension Proposal Pack below for details.
All further enquiries, corrections and so forth pertaining to this
proposal should preferably use INFINISPAN's developer mailing list
infinispan-dev(a)lists.jboss.org as their primary communication channel.
Project lead is Manik Surtani of Red Hat. I, Olaf Bergner
(olaf.bergner(a)gmx.de), am responsible for developing Spring Infinispan,
a preliminary version of which is located at
https://github.com/obergner/spring-infinispan.
Regards,
Olaf Bergner
http://www.jboss.org/infinispan
infinispan-dev(a)lists.jboss.org
olaf.bergner(a)gmx.de
----------------------------------------------------------------------------------------------
Extension Proposal Pack
This document is part of the Proposal pack for requesting a new
extension. Please modify the following sections and submit back to the
current project lead at SpringSource, or alternatively
extensions(a)springsource.com
Naming
Each Extension has several names, a publicly visible name and an SVN
name. This is actually quite an important aspect, as the name has to be
intuitive and distinct from every other Extension.
The naming convention for the internal name is "se-xxx", if it is a .NET
Extension, the naming convention is "se-xxx.net".
Proposed Name: Spring Infinispan
----------------------------------------------------------------------------------------------
Description and Background
What is the purpose of the Extension. What does it do, why is it needed,
how did it evolve etc.
Description:
Spring Infinispan will primarily provide an implementation of Spring
3.1's cache SPI, namely
* org.springframework.cache.Cache und
* org.springframework.cache.CacheManager,
backed by the high-performance distributed cache INFINISPAN:
http://www.jboss.org/infinispan.
In addition, Spring Infinispan will offer implementations of Spring's
FactoryBean interface for producing
* native Infinispan caches,
* native Infinispan cache managers,
* Infinispan configuration instances,
* ...
within a Spring context.
Spring Infinispan's overarching goal is to make Infinispan a good and
well-behaved citizen is Spring land, thus
* offering Infinispan users the option to use Spring's popular
programming model, and
* offering Spring users access to a mature, performant and actively
maintained distributed open source cache.
----------------------------------------------------------------------------------------------
Stakeholders
Who are the main stakeholders in the Extension? It is important for the
stakeholders to be clear to understand potential conflict of interest
issues.
Stakeholders:
At this stage, the only stakeholders in Spring Infinispan is the
Infinispan development community, led by Manik Surtani of Red Hat.
----------------------------------------------------------------------------------------------
Competitors/Related Projects
Who (if any) are competitors for this Extension. If there are
competitors, why would people use this Extension instead of the competitors?
Competitors:
To the best of my and Google's knowledge, there is no other effort
underway to integrate Infinispan into the Spring ecosystem. And even if
there should be, Spring Infinispan has the bonus of being backed by the
Infinispan development community.
----------------------------------------------------------------------------------------------
Benefit to SpringSource
Why do we care about this?
SpringSource Benefit:
* According to
http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/ is Spring
actively encouraging contributors to implement their forthcoming cache
SPI for as many cache providers as possible. Spring Infinispan will be
testament to the community's positive response to this call, and may
thus encourage other cache providers to follow suit, thereby promoting
Spring Cache's popularity.
* Developers invested in Infinispan may find Spring an attractive
programming model and switch to the Spring framework, thereby further
boosting its popularity.
----------------------------------------------------------------------------------------------
Benefit to the Community
What benefit does this Extension bring to the community?
Community Benefit:
* Make a high-performance and rapidly progressing distributed cache
accessible using the familiar Spring programming model.
----------------------------------------------------------------------------------------------
Sponsor
Every Extension must have a SpringSource sponsor. If the SpringSource
sponsor is already known, they should be listed here.
SpringSource Sponsor:
----------------------------------------------------------------------------------------------
Roadmap
What is the expected life time for the Extension. When is the first
release likely to happen? Try and provide a plan for the next 6-12
months. This doesnʼt form part of the formal contract, merely your best
intentions at this time.
Roadmap:
Spring Infinispan has a well circumscribed scope: implement Spring's
Cache SPI and provide some helper classes to make the lifes of
Infinispan users easier in Spring land. Therefore, it is currently
expected that Spring Infinispan will mature rather rapidly. Once it
supports embedded and remote Infinispan caches, its main goals will be
achieved. Beyond that, it will largely depend on community feedback if
and what further enhancements will be needed.
A first version supporting embedded (in-VM) Infinispan caches is likely
to go public within the first two months after this proposal has been
accepted.
A second version additionally supporting remote Infinispan caches should
be available at most two months later.
13 years, 9 months
Eventual consistency
by Manik Surtani
As consistency models go, Infinispan is primarily strongly consistent (with 2-phase commit between data owners), with the exception of during a rehash where because of eventual consistency (inability to get a valid response to a remote GET) forces us to wait for more responses, a quorum if you like. Not dissimilar to PAXOS [1] in some ways.
I'm wondering whether, for the sake of performance, we should also offer a fully eventually consistent model? What I am thinking is that changes *always* occur only on the primary data owner. Single phase, no additional round trips, etc. The primary owner then asynchronously propagates changes to the other data owners. This would mean things run much faster in a stable cluster, and durability is maintained. However, during rehashes when keys are moved, the notion of the primary owner may change. So to deal with this, we could use vector clocks [2] to version each entry. Vector clocks allow us to "merge" state nicely in most cases, and in the case of reads, we'd flip back to a PAXOS style quorum during a rehash to get the most "correct" version.
In terms of implementation, almost all of this would only affect the DistributionInterceptor and the DistributionManager, so we could easily have eventually consistent flavours of these two components.
Thoughts?
Cheers
Manik
[1] http://en.wikipedia.org/wiki/Paxos_algorithm
[2] http://en.wikipedia.org/wiki/Vector_clock
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
13 years, 9 months