Velocity vs MemCached vs Shared Cache

more and more people are asking me why gone have an additional distributed object caching system since even Microsoft started now a distributed / replicated caching system. I will try to answer this question in my personal point of view.

There are several reasons available, in comparison to MemCached we have a system which is written 100% in managed .net code and we started our first tries to run shared cache on Mono with a success (this version is currently not available - local development path - I will add more info about this in a different post) . Over the past few years MemCached approved itself over the biggest systems around the world and consider there is a great, active and helpful community behind it as long as people using it within Technologies like PHP, PHYTON and RUBI (and some more). Its quite clear (to me) they will use "only" MemCached and nothing else - nor Microsoft or Oracle will be able to create a solution for this communities.

At the time I started indeXus.Net Shared Cache there were nothing out there which was written 100% in .Net managed code, open source and FREE! There are several companies like Scaleout Software or Alachisoft they addressed a .Net solutions but the fact is as good they are - they cost money! In the meanwhile there are even starter kits available from various companies.

The first goal of Shared Cache was to give a solution for those who decide to use Microsoft .Net technology. The current status showed us that we able to compete in performance matters with MemCached.



Above comparison output I received from somebody else so I can't guarantee for it but on my environments results are quite similar.

What happens now since Microsoft announce it's Velocity project. I have contacted Microsoft Velocity Team with the question:

- Q:What kind of licensing will stay behind Velocity?

- A:The licencing terms have not yet been finalized. We hope to address it by CTP2.

Velocity's schedule based on the June's Tech-Ed 2008:

We hope Microsoft is going to implement the following requirements:

- No additional charge for Velocity
- 100 % managed Code
- They deploy at least pdb files
- Ability to run Velocity under MONO
- It will be at least that fast as Shared Cache and MemCached / Cacheman

I'm pretty sure most of above requirements they meet up until CTP 2 in October 2008.

indeXus.Net Shared Cache goes NHibernate Ver. 1.2.1

NHibernate Ver. 1.2.1

NHibernate is a port of Hibernate Core for Java to the .NET Framework. It handles persisting plain .NET objects to and from an underlying relational database. Given an XML description of your entities and relationships, NHibernate automatically generates SQL for loading and storing the objects. Optionally, you can describe your mapping metadata with attributes in your source code.

NHibernate.Caches.SharedCache provider for indeXus.Net Shared Cache (http://www.sharedcache.com/)

Get your copy at the following location: http://jira.nhibernate.org:8080/jira/browse/NH-1276

read more: http://www.sharedcache.com/cms/default.aspx?pg=74ae4aae-ad0e-4c4c-b2c2-3b3218c1ef20

SQL SERVER update @@LOCK_TIMEOUT

After installation the default value of @@LOCK_TIMEOUT is -1. Even if the Connection properties window shows 15 sec.

So if you have a time consuming SQL statement to update something like I had to do today:

UPDATE WorldCitiesPopulation
SET Population = '-1'WHERE (Population = '')

It updated quite a lot of rows: 2652350 row(s) affected; so the default value of 15 sec. is not enough on my machine. To update Timeout you simply execute the following:

SELECT @@LOCK_TIMEOUT
SET LOCK_TIMEOUT 180000
SELECT @@LOCK_TIMEOUT

indeXus.Net Shared Cache - 11 reasons why you should consider to use it!

indeXus.Net Shared Cache is high performance distributed and replication cache system build for .Net cache and enterprise application running in server farms.

indeXus.Net Shared Cache provides distributed replicated cache to minimize the load factor on deeper layers. It consists the usage of two or more servers in a farm. It's replicated all data within the cluster. The big plus is simple, you have all your cache nodes on all different servers. In case one of your servers get restarted, it will receive all items automatically from its parent. indeXus.Net Shared Cache uses 100% managed code which is written .Net C#.

Why you should consider to use indeXus.Net Shared Cache? There is no more efficient way to increase the scalable performance of applications then the use caching to unload deeper layers and you able to scale linear.

1. We provide a wider range of caching - distributed and replicated caching. The experience we have done so far showed us that a lot of projects have a huge need of data integrity.
2. We provide several cleanup models to purge the cache:
   a. Cache Item Priority
   b. LRU – Least Recent Used Item
   c. LFU – Least Frequently Used Item
   d. Time based
   e. BLF – Biggest Latency First
   f. LLF – Lowest Latency First
   g. Hybrid – Creating an index based on various item attributes such as: time in cache, Amount of requests, Size, Cache Life Time and some more.
3. Configurable maximum cache size and the load factor when the system starts to purge cached items.
4. With the upcoming release we gone provide Key Cache Dependency (it can be that in future we will also support SQL and File Dependency)
5. With the upcoming release we gone provide bulk operations
6. We use a binary format which has an overload payload of 36 bytes per Message.
7. Simple server and client configuration with custom provider sections
8. We use internally a custom thread pool which is configurable.
9. We provide a small management console with some basic information about cache nodes.
10. We provide detailed statistic information for client and server:
    a. Client Side:
    i. Amount of objects which are added / received / removed
    ii. Network usage
    iii. Successful and failed actions
    iv. Item Hit Rate
    b. Server Side per Node (all servers are aggregated)
    i. Amount of items available
    ii. Size of all items
    iii. A list with the top 20 keys based on hits
11. Last but not least: it’s absolutely free and open source!

consider to use local variables in some cases

who said performance == performance?

If you visited this blog already you now that indeXus.Net Shared Cache Server part is developed now as an asynchronous server and not a thread per client model. One of the very central server methods is to receive data. For this we have the following one:
private void ReadCallback(IAsyncResult ar)
{
// some code int read = handler.EndReceive(ar);
if (read > 0)
{
Monitor.Enter(state);
for (int i = 0; i <>
{
state.DataBuffer.Add(state.Buffer[i]);
}
Monitor.Exit(state);
// .
// .
// .
// .
// some more code
}

The above loop is developed straightforward, take the received buffer and concatenate it to the actual List until you received all needed data from the client. Well done - works great - but its slow like hell !!!!

Lets do some re-factoring and save up to 2.5 sec. which is actually for the tested use case 27,2% of end-to-end time:
adding 1000 objects with approx. 100kb toke 10,251 sec. in average (100 runs) - after this change we ended up with 7,456 sec for the same case in average for also 100 runs.

private void ReadCallback(IAsyncResult ar)
{
// some code
int read = handler.EndReceive(ar);
if (read > 0)
{
Monitor.Enter(state);
// save 2.5 seconds while i copy data to local variables and i do not access the property
byte[] localBuffer = new byte[state.DataBuffer.Count];
localBuffer = state.Buffer;
List localList = new List();
localList.AddRange(state.DataBuffer);
// copy all buffer data into DataBuffer which is list and contains all data until we get the whole message.
for (int i = 0; i < read; i++)
{
localList.Add(localBuffer[i]);
}
state.DataBuffer = localList;
Monitor.Exit(state);
// .
// .
// .
// .
// some more code
}

My conclusion is simple, keep attention were do you access object properties. I'm pretty sure that in 99% of all use cases it would not matter but here, its an amazing result for today's session.