Compact Serialization Vs .Net Serialization

August 1, 2011

Serialization is the process of converting the state of an object into a form that can be transferred on the wire. The opposite of serialization is deserialization, which converts a stream into an object. In distributed applications the serialization takes place whenever the data has to go out of the process or machine. Serialization in general is a slow process because of the IO and can become a performance bottleneck for distributed applications.

The .NET framework provides multiple serialization techniques such as binary, SOAP and XML serialization. Binary Serialization is commonly used and is much faster than the other serialization techniques. It preserves type consistency, which is useful for preserving the state of an object between different invocations of an application.

Although, .NET binary serialization is fast but it has some serious limitations. When it comes to network, speed of transfer of data is dependent on the data size. When a data is shared process to process while traveling on network, it should be serialized. Whenever an object is serialized, it contains so much Meta data of the object that it becomes very difficult to transfer it on the network. Bigger the object, more time it takes to travel on the network. Serialization uses reflection. Reflection is an I/O process which affects performance badly in case of the applications that uses distributed caching as the size of the serialized objects gets almost double.

Draw backs of binary serialization are:

• Slow reflection

• As the object size gets bigger, it affects the performance and slower network trips.

•People who use distributed caching experience a lot of data transferring which gets slower.

NCache is a distributed caching solution which provides you a feature called compact serialization which can help you fix problem occurring in binary serialization.

Compact Serialization is a process which produces a compact form of serialized object for performance improvement which results in faster network trips. It works by serializing the object in compact in form of data and process. The concept behind the compact serialization is that every keyword/data type is assigned a unique 2-byte type handle by the framework, which lets the deserializer uniquely identify them.
For example, suppose the framework assign a handle 0 to System.Int32. Then the serializer writes the 2-byte handle followed by 4 bytes of object value to the stream. Deserializer reads the handle, finds out the object type, and then creates and gives the object its value.

On other hand the binary serialization writes the complete type information with object data.

How Compact serialization is better than .Net serialization?

• In compact serialization, the serialized object does not contain the complete type information and assemblies. It only contains an object value and a unique 2-byte handle is used as a reference to uniquely identify the type’s details while deserializing an object which reduces the object size.

• Compact serialization also avoids the reflection which also reduces the overhead.

• You don’t need to code.

• It reduces the number of IO operations (minimum or no reflection) which increases performance of the application.

• Faster network trips reduce the cost and improves the performance as the size of the object is reduced.

SOME HELPFUL LINKS:

NCache Home Page

Download NCache

Advertisements

Dynamic Clustering in Distributed Caching

July 8, 2011

Distributed caching is the ultimate source of high performance, scalability and reliability for your application. Cache cluster is one of the notable features of distributed caching. A cache cluster is a collection of one or more cache servers with every server connected to every other server in the cluster. Runtime adjustment of clusters like increase or decrease in size of the cluster without stopping it is called dynamic clustering. It gives your application 100% up time all the time

Business needs vary throughout the year. Heavy load is experienced on special occasions like Christmas, New Year, and during holiday seasons. On such events, runtime demand increases (In situations like these, you’ve to make frequent runtime adjustments in your application  which demands high performance, reliability and scalability. So, use distributed caching which provides you dynamic clustering.

If any of the cache server goes offline for maintenance reasons, the whole application will go down which is not acceptable in any situation so use distributed caching as it is the best available choice. NCache is a distributed caching solution which provides you dynamic clustering. NCache uses peer-to-peer architecture in which each node is interconnected. If one node goes down then the other takes its responsibility and you don’t experience any down times.

Dynamic clustering helps you get 100% uptime. It also improves reliability, performance and scalability of your application. You can even maintain your cache server, by keeping your application live. Your application won’t go offline during the whole process.

When you make any change on the cluster like addition or removal of cache server, it should be intelligent enough to know the changes made on cluster. Similarly client should be up to date about cache changes too. Otherwise your application will perform oddly.

NCache does not use any OS-based clustering (like Windows Clustering) but instead it creates its own TCP based dynamic cluster of cache servers which helps NCache to provide you 100% uptime without going offline at any stage.

Failover Support by NCache:

When a cache cluster is created, it appoints a cluster coordinator that manages all members of the cluster. The coordinator is the senior-most server in the cluster. If the coordinator ever goes down, this duty passes on to the next senior-most server in the cluster. This auto recovery dynamic cluster of NCache provides your application full failover support.

There are two types of failovers that NCache supports:

  • Failover support within cluster: When a cache server is added or removed from the cluster, the cluster members are updated about the change within cluster so each cache server adjusts its connections to all other cache servers.
  • Failover support for cache clients: This means that all the cache clients also automatically adjust themselves if a cache server is added or removed.

Benefits are:

  • 100% application uptime
  • Reliability
  • Self healing
  • Load balancing
  • Satisfied/happy customer

Use SharePoint Storage Wisely: Externalize Blobs

May 26, 2011

SQL Server is a high-performing resource manager for structured data. It provides an exceptional data management environment and an efficient SQL query engine. However, when it comes to large binary data streams, such as the ones that flow from SharePoint, it no longer remains a viable option to act as SharePoint BLOB Storage. A large proportion of content in a typical enterprise deployment of SharePoint is stored as binary data streams or BLOBs. However, SQL Server having not been designed to handle a heavy payload of unstructured data, a number of problems occur consequently.

So how to manage SharePoint Storage if SQL Server is not the right place to keep SharePoint’s unstructured data? The answer is StorageEdge. It takes care of the SharePoint storage by handling all BLOB management issues from within SharePoint; primarily it lets you use your storage options wisely, by externalizing the BLOB content out of SQL Server’s content database.


SharePoint Storage Problems and StorageEdge Solutions:

1: Large Database is unmanageable

As the database size grows, SQL Server performance degrades considerably which results in a poorly-responsive SharePoint environment. As a best practice, it is absolutely not recommended for a single SQL data file size to exceed 200 GB. Whereas your SharePoint infrastructure may have content in hundreds of GBs and it might eventually run into TBs, the content database of SharePoint no longer remains a viable option as multiple data files shall have to be created.

StorageEdge dramatically reduces database size (up to 90%) and the transaction load by externalizing the SharePoint BLOB content on SAN/NAS Storage. This frees up the database resources and as a result the SharePoint application performance improves. There are many other additional benefits that StorageEdge gives along with BLOB externalization see this .

2: Save Cost on expensive Storage

Externalizing BLOBs to an external media is the best option to consider for an optimized SharePoint storage environment. StorageEdge provides you with enterprise-grade providers for EBS and RBS to shift your BLOB content to an inexpensive storage media such as SAN, NAS, or Cloud.

Manage SharePoint Storage using StorageEdge Storage Providers

Figure 1 : Manage SharePoint Storage using StorageEdge Storage Providers

3: SQL Server Performance:

: Further, the BLOBs cannot make the best use of the indexing and querying capabilities of SQL Server because unstructured binary data does not expose itself to the rich SQL query environment. Store and retrieve operations for BLOBs are more than simple get and put. Therefore, its value as a BLOB store is limited. StorageEdge lets you manage BLOBs outside of SQL Server hence no performance bottlenecks for your SharePoint applications. Moreover, StorageEdge keeps your externalized content and content metadata in a completely synchronized state.

4: SharePoint Archiving:

In the presence of large amounts of binary data in SQL Server, backup and restore operations become tedious and too time consuming. Ideally, the primary storage should only be use for transactional content and historically large binary content should be stored in inexpensive storage media. StorageEdge lets you archive SharePoint content, based on various policies, to cheaper storage tiers and allows you to save storage costs. You can even choose Cloud as a cheapest medium for storing SharePoint archived content.

In a nutshell, externalizing BLOBs from SharePoint is not an option; rather it is a necessity for the best use of your SharePoint storage and for SharePoint deployment to perform. StorageEdge lets you achieve that with an absolute ease.


When to use Client Cache with distributed caching

May 12, 2011

A Client Cache is local to your application and lets you cache recurrently used data much closer to your application than even the clustered cache. This blog will tell you that when you should use client cache with distributed caching.

Distributed Cache provides boost to the application performance and also allows you to scale it to certain levels. Distributed cache is usually hosted in an out of process situation and in many cases it is across the network on a dedicated caching server. This means that whenever you have to get any data from cache, you have to go across the process and also across the network which travels still much faster than any other data store (but it could be still faster).

Distributed caching provides boost to the application performance and also allows you to scale it to certain levels. Distributed cache is usually hosted in an out of process situation and in many cases it is across the network on a dedicated caching server. This means that whenever you have to get any data from cache, you have to go across the process and also across the network which travels still much faster than any other data store (but it could be still faster).

Even in this situation, the client cache becomes very wide but the main issue which any client cache has to address is that whatever data is being kept in cache cannot be disconnected from distributed cache. But if the client cache becomes nothing but a standalone local cache, then you face same data integrity issues that you would have had with distributed cache.

The reason of moving the distributed cache was that you wanted data changes to be synchronized. Here client cache will maintain that consistency at the same time giving you a very fast access to your application process. NCache provides you a client caching solution where you can actually keep the client cache as “in-process cache” for your application. The data being captured in client cache is actually part of the application process. The client cache maintains the connection to distributed cache and this connection is maintained to ensure that whatever data is being kept in client cache that same data is in distributed cache.

But if another client modifies the data in the distributed cache, a notification will be sent to the client cache and the client cache will update itself. This thing with the client cache will guarantee that it is always consistent with the distributed cache. NCache hides the client cache from the application code. So your application doesn’t even know that client cache exists and you write the code as there is no client cache.

Behind the scene, NCache knows about the client cache. It looks in the client cache first for whatever item the application is requesting and if it is not there, NCache will check in the distributed cache and put it into the client cache so that it gets to the application. Technically, there can be possibility that distributed cache doesn’t have data when it is requested but it keeps on upgrading data from the disk.

During up gradation, there is a small window of time when client cache has old copy of data and the application can get the older data. But it is in very rare cases. The data in the client cache is occasionally older version of the data. But in some cases you cannot actually afford that.

NCache provides you two synchronization mechanisms. In pessimistic synchronization, every time a client checks an item, it checks in the distributed cache for the newest version. If it’s a fresher version, it takes it from distributed cache otherwise it goes to client cache and fetches it.
In optimistic synchronization, if item is found in client cache, it is fetched from there. It is much faster as it already picked from the distributed cache. In return you have a guarantee that you will never have an old copy of the data.

This is how client cache works. We use the client cache when there is a separate dedicated caching layer. Application has access to the cache across the network and application wants to fully optimize the performance. Even though distributed cache is already giving you performance boost over not having any caching but it will give you even more performance than in-proc client cache.


SharePoint Archiving with multi-tier storage can reduce cost

May 4, 2011

SharePoint Archiving is an attraction for SharePoint users. SharePoint is a document centric product and the number of documents grows very rapidly in medium to large size company. Even after externalizing all the documents or BLOBs, the amount of storage needed is very large and keeping all those documents in one storage location often increases the storage cost because that storage is typically very expensive high end storage.

In reality, most of these documents are not commonly accessed, especially those that become older versions of a document. Keeping such large and unnecessary content on this expensive storage is not a wise idea so you should consider moving it to cheaper storage. Regarding this problem, StorageEdge provides a SharePoint archiving solution “multi-tier storage” that allows you to keep your most recent or the latest documents in the most expensive storage and archives older content out to less expensive storage. This will help reduce your organizational cost as the most expensive storage is not overwhelmed with millions of documents.

StorageEdge does SharePoint archiving of these documents based on two criteria:
• Age
• Versioning

You can specify content age that allows your content to stay in a tier before it gets migrated to the next tier. This age can be specified separately for each storage tier and you can have as many tiers as you want.
The other criterion is based on document versioning. Whenever you update a document, SharePoint does not update the original document but instead creates a new version and save that. It preserves the older versions and when you update a document multiple times, you will end up creating many versions of it. Usually, everybody works on the latest copy of the documents so it is practical to archive the older versions to the cheaper storage tier and keep the latest version on your expensive storage tier. The subsequent tiers could be simply cheaper storage either locally in your LAN or Cloud storage. For Cloud Storage, you may want to control your bandwidth and for that StorageEdge provides bandwidth throttling feature that handles this automatically.

SharePoint archiving using StorageEdge

So by having multi-tier storage, you are able to reduce your storage cost. And, surprisingly, it also improves SharePoint performance because the most active storage (meaning your Tier-1) no longer contains all those huge amount of documents that would have overwhelmed it.


Domain Object Caching Pattern for .NET

April 27, 2011

NOTE: This read is the abstract of the main article.Here is the main article

Domain Object Caching


Caching greatly improves application performance because it reduces expensive trips to the database. But, if you want to use caching in your application, you must decide what to cache and where to put your caching code. The answer is simple. Cache your domain objects and put caching code inside your persistence classes. Domain objects are central to any application and represent its core data and business validation rules. And, while domain objects may keep some read-only data, most of the data is transactional and changes frequently. Therefore, you cannot simply keep domain objects as “global variables” for the entirety of your application because the data will change in the database and your domain objects will become stale, thereby causing data integrity problems. You’ll have to use a proper caching solution for this. And, your options are ASP.NET Cache, Caching Application Block in Microsoft Enterprise Library, or some commercial solution like NCache from Alachisoft. Personally, I would advise against using ASP.NET Cache since it forces you to cache from presentation layer (ASP.NET pages) which is bad. The best place to embed caching in your application is your domain objects persistence classes.

Problem Definition

Domain objects form the backbone of any application. They capture data model from the database and also the business rules that apply to this data. It is very typical for most subsystems of an application to rely on these common domain objects. And, usually applications spend most of their time in either loading or saving these domain objects to the database. The actual “processing time” of these objects is very small specially for N-Tier applications where each “user request” is very short.

Solution

The solution is an extension of an existing design pattern called Domain Objects Persistence Pattern for .NET. That pattern already achieves the goal of separating domain objects from persistence code and from the rest of the application as well. This double-decoupling provides a great deal of flexibility in the design. The domain objects and the rest of the application is totally unaffected whether the data is coming from a relational database or any other source (e.g. XML, flat files, or Active Directory/LDAP).
Therefore, the best place to embed caching code is in the persistence classes. This ensures that no matter which part of the application issues the load or save call to domain objects, caching is appropriately referenced first. This also hides all the caching code from rest of the application and lets you replace it with something else should you choose to do so.

Creating Cache Keys

Most cache systems provide you with a string-based key. At the same time, the data that you cache consists of various different classes (“Customers”, “Employees”, “Orders”, etc.). In this situation, an EmployeeId of 1000 may conflict with an OrderId of 1000 if you keys do not contain any type information. Therefore, you need to store some type information as part of the key as well. Below are some suggested key structures. You can make up your own based on the same principles.

1. Keys for individual objects: If you’re only storing individual objects, you can make up your keys as following:

a. “Customers:PK:1000”. This means Customers object with primary key of 1000.
2. Keys for related objects:For each individual object, you may also want to keep related objects so you can easily find them. Here are keys for that:
3. Keys for query results:Sometime, you run queries that return a collection of objects. And, these queries may also take different run-time parameters each time. You want to store these query results so the next time you don’t have to run the query. Here are the keys for that. Please note that these keys also include run-time parameter values:
. “Employees:QRY:FindByTitleAndAge:Manager:40”.This represents a query in “Employees” class called “FindByTitleAndAge” which takes two run-time parameters. The first parameter is “Title” and second is “Age”. And, their runtime parameter values are specified.

Conclusion

Using the Domain Objects Caching Pattern, we have demonstrated how you should embed caching code into your persistence classes. And, we’ve covered the most commonly used situations of Load, Queries, and Relationships with respect to caching. This should give you a good starting point to determine how you should use caching in your application


Reduce ASP.NET Payload with View State Caching

April 21, 2011

Dramatically improve ASP.NET response times by reducing the payload returned to web clients. ASP.NET applications have to deal with View State becoming a performance overhead. And, NCache helps you cache View State on the web servers and send a much smaller payload to the user’s browser containing only a unique token for this ViewState.

Why Cache View State?

View State is an encrypted text string containing the state of web form controls and widgets and is sent to the user’s browser to preserve this state across post-backs. For forms with lot of controls, DataGrid control, or some other complex controls, the View State can become quite large. Here are some reasons why you should consider caching the View State.

View State is large (tens of kb) on large forms & DataGrid
• Large View State slows down page download time
• Large View State slows down post-back request time
• Can cache View State on WFE servers & send only a token to user
• View State cache is distributed to all WFE servers in the farm

How NCache Caches View State?

View State is included in the response of a web request as a hidden form field called __VIEWSTATE. On all page visits during the save view state stage, the Page class gathers the collective view state for all of the controls in its control hierarchy and serializes the state to a base-64 encoded string. Below is an example of a View State.And, since the in-memory cache is distributed and synchronized across all WFE servers, even if the post-back request goes to a different WFE server in the farm than the original server where the View State was created, NCache is able to find the View State value in the cache.


%d bloggers like this: