shared cache ver. 5.0 samples are "Hilited"

a cool thing - shared cache ver. 5.0 sample's are "Hilited"



http://www.raboof.com/Projects/Hilite/

RAM

Well I'm pretty sure I have now enough free RAM available for testing my upcoming new shared cache version properly with 64-bit:

takeover of Shared Cache?

please read the following thread: http://sharedcache.codeplex.com/Thread/View.aspx?ThreadId=53282

Poker and Shared Cache

do you like poker ? I do, checkout how a custom version of shared cache helps to run a poker game: read ivan's post why he decided to use shared cache instead of velocity: http://www.ivanbondy.com/Blog/archive/2009/03/16/microsoft-velocity-out-shared-cache-in-.aspx

SharedCache Version: 3.0.5.1 - Release Notes

Abstract
SharedCache is a high-performance, distributed caching system. Although application-neutral, it's commonly used to speed up dynamic applications by alleviating database load. SharedCache runs as a distributed windows service on every web and / or application server farm to cache data objects in memory out of process. Your stored objects can be accessed from any of your servers in your farm.
Download: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SharedCache
Release Date: March, 9th 2009
Release Number: 3.0.5.1
Release Documentation: http://doc.sharedcache.com/ (is not updated now - coming soon)

3.0.5.1 contains:

• DataContract serialization implementation (WCF)
• Workitem: Socket closure on shutdown
• Major bug in fallback logic (special thanks to Christian Weyer from thinktecture - http://www.thinktecture.com/staff/christian)
• Replicated caching and distributed caching versions contains now a flag with an online / offline status.
• Extended logging - trace socket pool bahaviour when shared cache runs as debug installation. Use SysteInternals DbgView to view how the socket pool act.
• Client and server socket pool configurations (SocketPoolValidation, SocketPoolTimeout, SocketPoolMinAvailaleSize)

Information about how to configure client and replicated server socket pools can be found here:

• Replicated server socket pool configuration: http://www.sharedcache.com/cms/default.aspx?pg=e9acfe54-2da7-4515-924a-e46723921764#Release%203.0.5.1
• Client socket pool configuration: http://www.sharedcache.com/cms/default.aspx?pg=adc4b470-11a5-4e87-8d06-8ff0e4fd3b05#release%203.0.5.1
  

tips & tricks:

if you install the server on the same server we suggest to use different locations for the log files. eg:

Server: h:\app_logs\server\

Client: j:\app_logs\client\

Consider about firewall configurations: if you have communication problems check your firewall file: C:\WINDOWS\pfirewall.log

Comparsion between NCache Express & Shared Cache 3.0.5.1 (beta)

Shared Cache is a high performance distributed and replicated caching system. The project is hosted and maintained on http://sharedcache.codeplex.com/. Some day's ago a user of sharedcache introduced comparsion data between NCache Express and Shared Cache (3.0.5.1).

Basically it showed us that our new version with DataContract methods extension speed up serlialization and the whole system.



Checkout the post behind this entry: http://sharedcache.codeplex.com/Thread/View.aspx?ThreadId=48739

SharedCache released version: 3.0.5.0

I released today version: 3.0.5.0 which contains a lot of improved features for your distributed and replicated caching requirements.

Two most important changes you should know about in this release is that I changed the main namespace from MergeSystem.Indexus to SharedCache and the full solution is based now on .net framework 3.5. SharedCache is still 100% managed .net code. SharedCache does not contain any further relation anymore to other project namespaces and it is fully stand alone now. Therefore this namepace changes were needed.

Today I can count 4873 SharedCache installations (development, staging, live environment) were I know about and I hope you keep me updated were you are using SharedCache. SharedCache has been registered from 48 countries whole over the world. Thank you!

You can start your journey directly at http://www.sharedcache.com/cms/release_notes.aspx or you can go use http://www.codeplex.com/sharedcache to receive all news. We also updated our object model documentation at: http://doc.sharedcache.com/

I like to take this opportunity to thank you for using SharedCache and I highly delighted to see that SharedCache gets a real alternative to any commercial product which is available on the market.

Microsoft Project Code Named “Velocity” CTP2

“Velocity” is a distributed in-memory application cache platform for developing scalable, high-performance applications. “Velocity” can be used to cache any common language runtime (CLR) object and provides access through simple APIs. The key aspects of “Velocity” are distributed cache performance, scalabily, and availability.

Microsoft Download Link

Related Resources
“Velocity” Team Blog
“Velocity” Code Samples
Microsoft project code named “Velocity” Homepage
“Velocity” Documentation on MSDN

soon I try to make some comparsions between velocity and shared cache.

dictonary serializable

after some researches how to serialize dictonary in .net I found the following solutions:

only XML serialization: http://weblogs.asp.net/pwelter34/archive/2006/05/03/444961.aspx

inclusive Binary serialization: http://blogs.microsoft.co.il/blogs/applisec/archive/2008/02/23/serializable-dictionary.aspx

GetHashCode() have been changed

As its written in MSDN (http://msdn.microsoft.com/en-us/library/system.string.gethashcode.aspx):
Remarks:
The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language run-time to another. A reason why this might happen is to improve the performance of GetHashCode.

In the following versions exactly this happens:

• 2.0.50727.3053


• 2.0.50727.1433

Let's say you like to do something for load-balancing based on the following code:

return Math.Abs((key.GetHashCode() % serverAmount));

it will return a different server node in case of shared cache. To handle this issue we have added 2 things, first of all is an alternative hashing algorithm and second we check the run-time between clients and server and inform clients about it in case this happens.

If you are using a version of shared cache which is below 2.0.3.276 you need to keep all your systems up-to-date with the same CLR version or you decide to use a different hashing algorithm for your system. Within our notifier program you can check this quite easily.

To use following options you will firstly need to register, the registration can be done during installation or afterwards within a new option within menu context of SharedCache.com Notify application.

• Check if all environments are using same CLR

• A Test to check if you able to use all Hashing Algorithms
  

• Get Informed if your environment is using same version of shared cache, this is mostly important to grant all communication options between clients and caching nodes on your servers.

for more information about hashing algorithms which are supported by shared cache visit my website: http://www.sharedcache.com/ - or go directly to http://www.sharedcache.com/cms/shared_cache_notify.aspx

Measure HTTP Request with a HTTP Module

while I was working for a demo I needed to demonstrate differences between requests which are hitting Database and those requests which were hitting Shared Cache.

I found an article from Phil Hacked which solved all my needs. You can find the article over here.

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

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.

indeXus.Net Shared Cache pre-release 2.0.0.140 is available

indeXus.Net SharedCache is a high-performance, distributed caching system. Although application-neutral, it's commonly used to speed up dynamic Web applications by alleviating database load.

This release includes many new features and enhancements like server connection pooling, more efficient network usage, and much smaller protocol overload. We could increase performance in almost every test-case.

Most of the new developments have been based on community feedback; enhancements which have been requested over the last few weeks have all been logged and incorporated in the new release.

The use of 100% managed code provides performance and ensuring optimal reliability in the most demanding environments. The full Visual Studio.Net solution is available for download.

Latest release is available and ready to download at the following link: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=SharedCache&ReleaseId=10166

Shared Cache is an open source project hosted on http://www.codeplex.com/SharedCache and it’s licensed under “GNU Library General Public License (LGPL)”

Shared Cache - compare results between version 1.0.2.134 and 2.0.0.140 and upper

As already mention in some previous posts in my Blog I have re-written the whole client / server logic which runs under the hood. Checkout the following post for more information: http://netrsc.blogspot.com/2008/02/threaded-asynchronous-tcp-server-with.html

The client application which is delivered with indeXus.Net Shared Cache contains some Speed test options were I'm able to compare between them now. All in all i have to mention the server is getting quite faster then it was before and for sure more robust. Never thought such a async approach would make that much difference. All in all there are some key changes:

• Server is running as async TCP Server with a custom Threadpool
• Network traffic decreased dramatically between, especially upon server echos
• We take now full advantage of object pooling, so each action from the client in the test application gone use only 1 single "new Socket()" instead of several thousands.

People who have not seen the menu here is a stripdown of the different options.

Speed Tests [200 / 300 range]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

200 - Add 10 objects with the size approx. of 1kb.

210 - Add 100 objects with the size approx. of 1kb.

220 - Add 1000 objects with the size approx. of 1kb.

230 - Add 10000 objects with the size approx. of 1kb.
240 - Add 10 objects with the size approx. of 100kb.

250 - Add 100 objects with the size approx. of 100kb.

260 - Add 1000 objects with the size approx. of 100kb.

270 - Add 10000 objects with the size approx. of 100kb.
280 - Add 10 objects with the size approx. of 1MB.

290 - Add 100 objects with the size approx. of 1MB.

300 - Add 1000 objects with the size approx. of 1MB.

310 - Add 1500 objects with the size approx. of 1MB.

Just different options which makes it easy to compare with different approaches.

Below we see a table were in almoast every case we could increase the performance. Why we have the 3 marked Get operations which are slower I haven't figured out yet but I promiss I will do so. In generall we can say we have a performance increasment and system & network resource decreasment. With the upcoming version I have implemented some performance counters which will make life easier to compare results between installations.

As we can see we have for the case 100 client calls with 1 kb only better results then before.

As bigger the message (payload) which has to be transferred to the server, as better the results are getting. I was wondering if I have done a calculation mistake but I re-run the whole test 3 times.

It would be very intersting if people would post theire results to compare.

Threaded Asynchronous Tcp Server with a blocking Client

I don't know now how many prototypes I have written in the past few weeks to verify which approach would fit best to scale and be most performance for indeXus.Net Shared Cache. To write a Client / Server Architecture which mostly will be N:M connectivity was not that easy as I thought in beginning.

Honestly I believe I have study every single C# sample I found on the common search engines and arrived to the point where I started to adapt the samples. Unfortunately 99% of founded samples are showing how to pass a string from the client to the server beside one blog which has written down a lot of theory and some very nice diagrams without to come up with code. I only can recommend you to read this blog up and down before you write even one single line of code: http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx. There are some very smart people around they have done great work.

After a while of research, I get to koders.com where I found a strip-down version of their product.

Another very useful page with a lot of sample code around .net is Mike Woodrings's .net Sample Page which contains a bunch of great examples for different domains.

I think I have tried any way to use Sockets now:

• Blocked Sockets
• Unblocked Sockets
• Poll Sockets
• Select

Every prototype I have done so far had his advantages and disadvantages. In the end of this post I will provide 2 downloads:

• prototype with poll sockets on client and server
• protptype with block sockets on client side and async server handling

Once I get comfortable with all the different Issues which come across the write the server part I decided to use Asad Aziz - Asynchronous Server Socket using C# Sample as my base for the server. Its very easy written but my knowledge on this issue was limited until I started to work on it quite intensive and I think I learned every day at least 10 new things :-)

Lets dive into different key parts of the client and the server. An additional issue I would like to mention here is that the whole code is 100% managed.

We gone start first with the server. As already mention the server is working Asynchronous which means we have to handle with IAsyncResult. Upon Server start we begin run the server within a different thread and the client cleanup will be handled by a TimerCallback to purge disconnected clients in case they not removed before upon disconnection.

ThreadStart serverListener = new ThreadStart(this.StartListening);
serverThread[0] = new Thread(serverListener);
serverThread[0].IsBackground = true;
serverThread[0].Start();
TimerCallback timerDelegate = new TimerCallback(this.CheckSockets);
this.lostTimer = new Timer(timerDelegate, null, SharedCacheTcpServer.timerTimeout, SharedCacheTcpServer.timeoutMinutes);

Since we have started now the serverListener we Bind the server IPEndPoint to the requested ip and port and start to listen for connections from clients. Once a connection is received it only will be destroyed in one of the following 2 cases:

1. The Socket has not been used for a certain amount of time
2. Client Socket get disconnected.

With this we avoid to much Server resources. As started we will use a ManualResetEvent to accept only one by one client. I have commented this part for testing purposes and the server started to throw memory exceptions. So keep it simple in the meaning, only start a new BeginAccept once you finished to move the client into AccecptCallback.

private void AccecptCallback(IAsyncResult ar)
{
// signal main thread to continue
this.allDone.Set();
Socket clientListener = ar.AsyncState as Socket;
if (clientListener != null)
{
Socket handler = clientListener.EndAccept(ar);
Console.WriteLine(@"Connected by client: {0}", handler.RemoteEndPoint);
StateObject state = new StateObject();
state.WorkSocket = handler;
state.AliveTimeStamp = DateTime.Now;

... and some more code ..

once you have done all setup for you StateObject (this is the object which contains all different data between the calls) we able to call BeginReceive. SharedCache Protocol between client and server keep simple: [messageLength][message] so if we are not able to get the whole message at once we have to call several times BeginReceive until we have received everything from the client and we able to run the custom stuff on the server.

Once we done with our reading we can start to process received package and process with it. To keep server resources (amount of threads) under control I decided to use Mike's Threadpool.


I think the 2 most important parts are within this message is to know that we need to read the header which indicates to message length and if we need to read more data for this message or do we can proceed it arrived data.

// check for header
if (state.ReadHeader) { .....


// check for message length -> TODO: how to check longer values as int count in list????
if (state.DataBuffer.ToArray().LongLength == state.MessageLength) { ...


as you can see there is even one open point since I use in my state object a List. I had some discussions with people on asp.net forums but I believe i can life right now with this
int.MaxValue as maximal message length ;-)


the next key position in above code print screen is that we use at this place again handler.BeginReceive() since we want to client connection keep opened as long as possible. Some previous tests had shown me while i open and close 1000 Sockets the time reduction to use always the same is more then 50%. Before we can post the request into ThreadPool we need to remove the Range of our message size [8 bytes] that's why we do: state.DataBuffer.RemoveRange(0,8); once we have posted it to the threadpool to pool handles the message sending the Echo to the waiting client.
HandleClientMessage is the place which is called after you get the free Thread from the ThreadPool - here you can manage your Server side stuff and once you done you can send it back to the Client. If you work within Winform environment a more event driven design would be correct but for sharedcache this would not be correct since the client is waiting for the server response.



in the above example we do nothing else then to set an Attribute of the object IndexusMessage to Successful.
The response from the server needs to be prepared, then also the client waits for the same struct [message length][message data]. Therefore we call UtilByte.CreateMessageHeader(with the msg.GetBytes() which returns a byte array) and we combine both values to 1 single byte array. since this is done we can free up resources and set the actual messageLength on the state so we know how much data we need to send to the client which is not less important.



Within the Send() method we start the async call: socket.BeginSend() or if we do not have anything to send back (this case does not happen here) we reset all state data and start to receive again without to destroy the state and the socket which is included in the state. The
same idea happens within the SendCallback() we call BeginSend() as long we have data to send and once we sent everything to the client we reset the state and start to receive again with socket.BeginReceive().

These are all important parts on the server side, I will wrap up the client in a different post within the next few days.

The 2 best code-solution I have found on the web are the following 2 links:

http://www.codeproject.com/KB/IP/Generic_TCP_IP_server.aspx
http://www.codeproject.com/KB/IP/AsyncSocketServerandClien.aspx

Both of them could not handle the case I needed so I hope people can use the Prototypes in this or another way. It would be great if you let me know if you are using them. So here are the downloads:

• Polling (Client and Server)
• Async Server and Block client with manager to connect to several servers

I really would like to say "thank you very much" to all contributors of the following articles and coding samples:

• Atif Aziz for all his good suggestions about how to handle the different issues
• Gil Y. - Generic TCP/IP Client / Server
• Andre Azevedo - An Asynchronous Socket Server and Client
• Mike Woodring - Custom Thread Pool
• Chris Mullins - Windows Sockets and Threading: How well does it scale?
• Mark Strawmyer - Communication over Sockets: Blocking vs Unblocking

Performance average comparsion between State Server and indeXus.Net Shared Cache

Performance Environment and preconditions:
Client: MS Windows XP Prof, Intel Pentium D, 2.8GHz, 3.24 GB RAM
Server: MS Windows Server 2003, Enterprise Edition SP2, Intel Pentium D, 2.8GHz, 3.24 GB RAM
Iterations: 1000
Object Size: ~1kb
Debug Mode: True

Session State on same server:
In-Process: 225 requests / second
Out-Of-Process: 165 requests / second

Session State on remote server:
Out-Of-Process, 55 requests/second (-68%)

indeXus.Net Shared Cache same server:
add: 3s 128ms -> 319.6 req/sec
get: 3s 096ms -> 322.3 req/sec
remove: 2s 868ms -> 348.6 req/sec

indeXus.Net Shared Cache remote server:
add: 3s 425ms -> 291.9 req/sec
get: 3s 620ms -> 276.2 req/sec
remove: 3s 556ms -> 297.9 req/sec



original page:
http://www.codeplex.com/SharedCache/Wiki/View.aspx?title=Speed%20Test%20Results

additional comparsions will be added soon, also with sql server

make more test does not mean you gain code coverage

Today's conclusion is based on the the following number flow: 2.6 % my coverage gained. Sure it's better then nothing but the conclusion is quite simple.

After the first bunch of Unit Test I have written i reached a coverage of 49.86% with a total of 70 unit test. Maybe the proper name of Unit Tests is wrong the some of them are also testing communication between the client and server module, but even then, lets make it easy and now we call them Unit Test which are starting indeXus.Net Shared Cache Server upon start up to test all different transport options over the wire.

Yesterday's Print screen with a total of 70 Unit Test:

And today's print screen with an additional 30 Unit Test:

more detailed view:

In nature of coverage the change is small but in sense of testing purposes my whole protocol is tested now. This is not less important then the coverage but I still held on the number to reach a coverage of 90%