memcached

Added by Shay Banon, last edited by Shay Hassidim on Jul 15, 2010  (view change)
Search XAP 7.1
Searching XAP 7.1 Documentation
Browse XAP 7.1
Quick Start Guide
Product Overview
Programmer's Guide
Administrator's Guide
Offline Documentation

Download latest offline documentation in HTML format:
xap-7.1-documentation.zip (19.4MB)

                                                              
Summary: memcached support on top of the space.

Overview


memcached is a popular caching protocol and server. The integration provided allows to use GigaSpaces as a memcached server (talking the memcached protocol) enhancing the memcached to provide high availability, write behind, and all the other features that come built in with the space.

The memcached support is provided as a template deployment (similar to how basic data grid deployment works), allowing to easily issue commands to deploy a memcached cluster using the CLI, Admin API, or the UI.

Deploying memcached

Deploying memcached requires a single parameter, which is the space to use for the memcached data. The parameter is the space url, and can either be an embedded space, or a remote connection url to an already deployed url. Here are some examples to deploy memcached using the CLI:

# deploy a single instance memcached with an embedded space
$ gs.sh deploy-memcached /./mySpace

# deploy a clustered memcached
$ gs.sh deploy-memcached -cluster total_members=2,1 /./mySpace

# deploy a memcached with 5 instances connecting to a remote space
$ gs.sh deploy-memcached -cluster total_members=5 jini://*/*/mySpace

# deploy a memcached instance as local cache connecting to a remote space
$ gs.sh deploy-memcached -cluster jini://*/*/mySpace

Deploying using the Admin API is similar:

Admin admin = new AdminFactory().addGroup("kimchy").createAdmin();

admin.getGridServiceManagers().waitFor(1);
admin.getGridServiceContainers().waitFor(2);

ProcessingUnit unit = admin.getGridServiceManagers().deploy(new MemcachedDeployment("/./test").partitioned(1, 1));
unit.waitFor(unit.getTotalNumberOfInstances());

for (ProcessingUnitInstance instance : unit) {
    System.out.println(instance.getClusterInfo().getUniqueName() + 
              ": Memcached started on port [" + instance.getMemcachedDetails().getPort() + "]");
}

while (true) {
    Thread.sleep(3000);
    System.out.println("---------------------------------");
    for (ProcessingUnitInstance instance : unit) {
        System.out.println(instance.getClusterInfo().getUniqueName() + 
             ": Gets [" + instance.getStatistics().getMemcached().getGetCmds() + "]");
    }
}

Anatomy of memcached

The memcached deployment descriptor looks as follows:

<!--
    Spring property configurer which allows us to use system properties (such as user.name).
-->
<bean id="propertiesConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="properties">
        <props>
            <prop key="url">/./memcached</prop>
            <prop key="port">11211</prop>
            <prop key="portRetries">10</prop>
            <prop key="threaded">true</prop>
        </props>
    </property>
</bean>

<!--
    A bean representing an embedded space (an IJSpace implementation).
-->
<os-core:space id="space" url="${url}" versioned="true">
</os-core:space>

<os-core:local-cache id="localCache" space="space">
    
</os-core:local-cache>

<os-core:giga-space id="gigaSpace" space="localCache" />

<bean id="memcached" class="org.openspaces.memcached.MemCacheDaemon">
    <property name="space" ref="gigaSpace" />
    <property name="port" value="${port}"/>
    <property name="portRetries" value="${portRetries}" />
    <property name="threaded" value="${threaded}" />
</bean>

The deployment defined a space, with the provided deployment url (so it can be embedded or remote). It defines a local cache on top of the space, and that local cache is passed to the MemCacheDaemon.

The MemCacheDaemon start listening on the provided port, and if that port is busy, the next port will be used. The daemon accepts different memcached protocol commands, and translates them into operations on the space.

Why Use Local Cache

The local cache is started on each instance, and works against the whole cluster. Since memcached clients have no concept of routing and how routing is done by the space, a request can hit a certain instance, and be routed to a different space instance. The idea of the local cache is to improve the performance of "get" requests.

Most memcached clients allow to provide a list of memcached servers to connect to. Another improvement that most of them provides us the ability to have consistent hashing of keys to the same server instance. This can result in both high hit rate on the local cache, and less eviction happening.

Performance

The results below compares native memcached with GigaSpaces memcached:

The command used to generate the results is:

memslap --concurrency=$i --test=get --servers=$SERVER:$PORT

Test Setup

  • Client: CentOS 5 , 4 x AMD Opteron Dual-core 8220 2.8Ghz , Sun Fire X4600
  • memcached Server:CentOS 5 , Intel(R) Xeon(R) CPU X5570 @ 2.93GHz , CISCO USC
  • Space Configuration: one instance. No backup. Deploy command: 
    gs.sh deploy-memcached /./mySpace
This documentation refers to product version 7.1

Additional resources: XAP Application Server | XAP Data Grid | XAP for Cloud Computing | XAP J2EE Support

Labels

 
(None)