This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description
Amazon ElastiCache backend for Django
=====================================

Simple Django cache backend for Amazon ElastiCache (memcached based). It uses
`pylibmc <http: github.com="" lericson="" pylibmc="">`_ and sets up a connection to each
node in the cluster using
`auto discovery <http: docs.aws.amazon.com="" amazonelasticache="" latest="" userguide="" autodiscovery.html="">`_.


Requirements
------------

* pylibmc
* Django 1.5+.

It was written and tested on Python 2.7 and 3.4.

Installation
------------

Get it from `pypi <http: pypi.python.org="" pypi="" django-elasticache="">`_::

pip install django-elasticache

or `github <http: github.com="" gusdan="" django-elasticache="">`_::

pip install -e git://github.com/gusdan/django-elasticache.git#egg=django-elasticache


Usage
-----

Your cache backend should look something like this::

CACHES = {
'default': {
'BACKEND': 'django_elasticache.memcached.ElastiCache',
'LOCATION': 'cache-c.draaaf.cfg.use1.cache.amazonaws.com:11211',
}
}

By the first call to cache it connects to cluster (using LOCATION param),
gets list of all nodes and setup pylibmc client using full
list of nodes. As result your cache will work with all nodes in cluster and
automatically detect new nodes in cluster. List of nodes are stored in class-level
cached, so any changes in cluster take affect only after restart of working process.
But if you're using gunicorn or mod_wsgi you usually have max_request settings which
restart process after some count of processed requests, so auto discovery will work
fine.

Django-elasticache changes default pylibmc params to increase performance.

Another solutions
-----------------

ElastiCache provides memcached interface so there are three solution of using it:

1. Memcached configured with location = Configuration Endpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this case your application
will randomly connect to nodes in cluster and cache will be used with not optimal
way. At some moment you will be connected to first node and set item. Minute later
you will be connected to another node and will not able to get this item.

::

CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
'LOCATION': 'cache.gasdbp.cfg.use1.cache.amazonaws.com:11211',
}
}

::


2. Memcached configured with all nodes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It will work fine, memcache client will
separate items between all nodes and will balance loading on client side. You will
have problems only after adding new nodes or delete old nodes. In this case you should
add new nodes manually and don't forget update your app after all changes on AWS.

::

CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
'LOCATION': [
'cache.gqasdbp.0001.use1.cache.amazonaws.com:11211',
'cache.gqasdbp.0002.use1.cache.amazonaws.com:11211',
]
}
}

::


3. Use django-elasticache
~~~~~~~~~~~~~~~~~~~~~~~~~

It will connect to cluster and retrieve ip addresses
of all nodes and configure memcached to use all nodes.

::

CACHES = {
'default': {
'BACKEND': 'django_elasticache.memcached.ElastiCache',
'LOCATION': 'cache-c.draaaf.cfg.use1.cache.amazonaws.com:11211',
}
}

::


Difference between setup with nodes list (django-elasticache) and
connection to only one configuration Endpoint (using dns routing) you can see on
this graph:

.. image:: https://raw.github.com/gusdan/django-elasticache/master/docs/images/get%20operation%20in%20cluster.png

Testing
-------

Run the tests like this::

nosetests
Release History

Release History

0.0.4

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.0.3

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.0.2

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.0.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django-elasticache-0.0.4.tar.gz (4.7 kB) Copy SHA256 Checksum SHA256 Source Jun 13, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting