http://support.microsoft.com/default.aspx?scid=kb;EN-US;974348 - great stuff ms.
Note: This article discusses a scenario that may be addressed by Microsoft Advisory Services.
Microsoft Advisory Services is an hourly fee-based, consultative support option that provides proactive support beyond your break-fix product maintenance needs. This is a remote, phone-based support option that includes working with the same technician for assistance with issues like product migration, code review, or new program development. This service is typically used for shorter engagements, and is designed for developers and IT professionals who do not require the traditional onsite consulting or sustained account management services that are available from other Microsoft support options. This article also provides some self-help resources for this scenario.
For additional information on Microsoft Advisory Services, including on how to engage, refer to this Microsoft web page:
http://support.microsoft.com/default.aspx?pr=AdvisoryService
Microsoft can provide Performance Tuning services for your software solutions, Microsoft development technologies and platforms such as Common Language Runtime (CLR) framework, Internet Information Server (IIS), developer tools like Visual Studio.NET, and other Microsoft Software Development related tools and solutions. Example includes:
IIS/ASP performance diagnostics and tuning, such as CPU spikes and slow user experience.
CLR performance debugging, profiling, detailed analysis, and architectural best practices.
Team Foundation Server performance issues, such as Work Item Tracking, Source Control, Reporting, and Server Responsiveness.
Below is a list of self-help resources for this scenario. These resources may also be used by Microsoft Support Engineers during an Advisory Services engagement.
IIS 6 Performance Forum
A forum aimed at sharing ideas, techniques for optimizing IIS performance.
http://forums.iis.net/1037.aspx (http://forums.iis.net/1037.aspx)
IIS 7 Performance Forum
Discussion on how to effectively tweak IIS 7 to resolve issues related to performance.
http://forums.iis.net/1050.aspx (http://forums.iis.net/1050.aspx)
PAG Performance Testing Guide
This guide shows you an end-to-end approach for implementing performance testing. Whether you are new to performance testing, or looking for ways to improve your current performance testing approach, you will find insights that you can tailor for your specific scenarios.
http://msdn.microsoft.com/en-us/library/bb924375.aspx
PAG Improving .NET Application Performance and Scalability
This guide provides end-to-end guidance for managing performance and scalability throughout your application life cycle to reduce risk and lower total cost of ownership. It provides a framework that organizes performance into a handful of prioritized categories where your choices heavily impact performance and scalability success.
http://msdn.microsoft.com/en-us/library/ms998530.aspx
Optimizing Performance of Database Access in IIS
This document provides some "best practices" for optimizing database access.
http://msdn.microsoft.com/en-us/library/ms525484.aspx
ASP.NET Performance Monitoring and When to Alert Administrators
Discusses which performance counters are most helpful in diagnosing stress and performance issues in Microsoft ASP.NET applications, what thresholds should be set in order to alert administrators to problems, and other resources that can be used to monitor the health of an ASP.NET application.
http://msdn.microsoft.com/en-us/library/ms972959.aspx
Designing Scalable IIS Applications
This guide provides design considerations for performance and scalability.
http://msdn.microsoft.com/en-us/library/ms525522.aspx
Scaling Strategies for ASP.NET Applications
This MSDN article discusses scaling requirements for ASP.NET applications.
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx?pr=blog
Tools for Optimizing Performance
This document lists brief descriptions of performance-optimizing tools and how to access them.
http://msdn.microsoft.com/en-us/library/dd328379.aspx
Design and Configuration for Performance (ASP.NET)
This topic discusses design, configuration, compilation, and memory options available to improve the performance of a Web application.
http://msdn.microsoft.com/en-us/library/ms227998.aspx
ASP.NET Performance Articles
This document provides a listing of articles that can be used to improve and montior the performance of your applications.
http://msdn.microsoft.com/en-us/library/44e5wy6k(VS.85).aspx
Troubleshooting a Performance Issue with Failed Request Tracing and appcmd in IIS 7
This blog post discusses how to troubleshoot a performance issue in IIS 7.
http://blogs.msdn.com/tess/archive/2008/08/19/troubleshooting-a-performance-issue-with-failed-request-tracing-and-appcmd-in-iis7.aspx
BTess's "Performance Issues and Hangs"
List of blog postings regarding performance issues.
http://blogs.msdn.com/tess/archive/tags/Performance+issues+and+hangs/default.aspx
How to View What ASP.NET Requests Are Doing at Runtime
This blog post discusses a tool with a User Interface that allows you to choose a process and thread and see the managed call stack at that point in time that can be run on IIS 6.0.
http://blogs.msdn.com/webtopics/archive/2009/05/05/how-to-view-what-asp-net-requests-are-doing-at-runtime-on-iis-6-0.aspx
Troubleshooting System.OutOfMemoryExceptions in ASP.NET
This blog post discusses how to troubleshoot OutOfMemoryExceptions in ASP.NET.
http://blogs.msdn.com/webtopics/archive/2009/05/22/Troubleshooting-System.OutOfMemoryExceptions-in-ASP.NET.aspx
Javascript Resources
Profiling Script with the Developer Tools
This page provides an introduction to script profiling, which can be used to identify and resolve performance-related issues.
http://msdn.microsoft.com/en-us/library/dd565629(VS.85).aspx
JScript Debugger in Internet Explorer 8
This blog post provides information on how to use the JScript debugger
http://blogs.msdn.com/jscript/archive/2008/03/13/jscript-debugger-in-internet-explorer-8.aspx
Improved Productivity Through Internet Explorer 8 Developer Tools
This blog post focuses on the developer tools available for Internet Explorer 8.
http://blogs.msdn.com/ie/archive/2008/03/07/improved-productivity-through-internet-explorer-8-developer-tools.aspx
IE + JavaScript Performance Recommendations - Part 1
This blog post discusses ways to improvie performance of JavaScript.
http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx
IE + JavaScript Performance Recommendations - Part 2: JavaScript Code Inefficiencies
This blog post discusses how to avoid JavaScript code inefficiencies.
http://blogs.msdn.com/ie/archive/2006/11/16/ie-javascript-performance-recommendations-part-2-javascript-code-inefficiencies.aspx
IE + JavaScript Performance Recommendations - Part 3: JavaScript Code Inefficiencies
This blog post focuses on specific inefficiencies related to closures and object-oriented programming.
http://blogs.msdn.com/ie/archive/2007/01/04/ie-jscript-performance-recommendations-part-3-javascript-code-inefficiencies.aspx
Performance Optimization of Arrays - Part 1
This blog post discusses how to improve performance of Array operations
http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx
Performance Optimization of Arrays - Part II
This blog post continues the discussion on how to improve performance of Array operations.
http://blogs.msdn.com/jscript/archive/2008/04/08/performance-optimization-of-arrays-part-ii.aspx
Performance issues with "String Concatenation" in JScript
This blog post focuses on how to improve the performance of string concatenations in JScript.
http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx
Eval is Evil - Part 1
This blog post provides alternative solutions to the use of the Eval method.
http://blogs.msdn.com/ericlippert/archive/2003/11/01/53329.aspx (http://blogs.msdn.com/ericlippert/archive/2003/11/01/53329.aspx)
Eval is Evil - Part two
This blog post continues the discussion of alternate solutions to the Eval method.
http://blogs.msdn.com/ericlippert/archive/2003/11/04/53335.aspx (http://blogs.msdn.com/ericlippert/archive/2003/11/04/53335.aspx)
Networking Resources
How to capture network traffic with Network Monitor
The purpose of this article is to provide you with the information needed to capture network traffic from a local area network using Microsoft's Network Monitor.
http://support.microsoft.com/kb/148942
Fiddler PowerToy - Part 1: HTTP Debugging
Learn how to use the Microsoft Fiddler HTTP debugger when developing and testing Web applications and clients.
http://msdn.microsoft.com/en-us/library/bb250446(VS.85).aspx
Fiddler PowerToy - Part 2: HTTP Performance
Learn how to build a faster Web site using the Microsoft Fiddler HTTP Debugger.
http://msdn.microsoft.com/en-us/library/bb250442(VS.85).aspx (http://msdn.microsoft.com/en-us/library/bb250442(VS.85).aspx)
Part 2: TCP Performance Expert and General Trouble Shooting
This blog discusses TCP Performance Expert and General Troubleshooting skills.
http://blogs.technet.com/netmon/archive/2007/01/26/part-2-tcp-performance-expert-and-general-trouble-shooting.aspx (http://blogs.technet.com/netmon/archive/2007/01/26/part-2-tcp-performance-expert-and-general-trouble-shooting.aspx)
TCP Analyzer Expert: Make Your Network Run Faster
This blog post focuses on how to use the TCP Analyzer Expert.
http://blogs.technet.com/netmon/archive/2009/06/30/tcp-analyzer-expert-make-your-network-run-faster.aspx (http://blogs.technet.com/netmon/archive/2009/06/30/tcp-analyzer-expert-make-your-network-run-faster.aspx)
Tools Resources
Fiddler Web Debugging Proxy
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. This document discusses use of the tool.
http://www.fiddlertool.com/fiddler/
AjaxScope
Ajax View enables developer to see and control the behaviors of their web applications on user's desktops. This page discucess how tu use this tool.
http://research.microsoft.com/en-us/projects/ajaxview/
Microsoft Network Monitor
Tool to allow capturing and protocol analysis of network traffic.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f)
Debugging tools for Windows
You can use Debugging Tools for Windows to debug drivers, applications, and services on systems that are running Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
DebugDiag
The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or fragmentation, and crashes in any Win32 user-mode process.
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en)
neXpert Performance Tool
Discussion On Using Fiddler and neXpert To Identify and Fix Web Performance Issues.
http://blogs.msdn.com/nexpert/ (http://blogs.msdn.com/nexpert/)
Strace
STRACE is a socket/SSL tracer designed to generate LOG for Internet Explorer.
http://www.microsoft.com/downloads/details.aspx?familyid=F5EC767F-27F2-4FB3-90A5-4BF0D5F4810A&displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=F5EC767F-27F2-4FB3-90A5-4BF0D5F4810A&displaylang=en)
HTTPReplay
HTTPREPLAY is a SOCKTRC plugin allowing to analyze and replay HTTP traffic.
http://www.microsoft.com/downloads/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en&tm
Design Resources
Designing for Add-on Performance
Blog post describing how to improve add-on performance with Internet Explorer.
http://blogs.msdn.com/ie/archive/2008/04/04/designing-for-add-on-performance.aspx
Performance Considerations in Internet Explorer
This page provides links and tips for getting extra performance from DHTML, Script, Web Servers, ActiveX Controls, Java Applets, and Plugins.
http://msdn.microsoft.com/en-us/library/ms533021(VS.85).aspx
Faster DHTML in 12 Steps
This article describes how using some DHTML features can affect performance more than others, and it presents tips that will help your pages perform faster.
http://msdn.microsoft.com/en-us/library/ms533019(VS.85).aspx (http://msdn.microsoft.com/en-us/library/ms533019(VS.85).aspx)
Building High Performance HTML Pages
This article presents some tips on how you can get the most performance out of your pages.
http://msdn.microsoft.com/en-us/library/ms533020(VS.85).aspx
Frequent Flyers: Boosting Performance on DHTML Pages
This blog post discusses how to get better performance from your Dynamic HTML pages.
http://msdn.microsoft.com/en-us/library/bb264005(VS.85).aspx
Asynchrony: Loved Your Performance
This article discusses how to improve performance with asynchrony.
http://msdn.microsoft.com/en-us/library/bb263994(VS.85).aspx
Building ActiveX Controls for Internet Explorer
This article covers features of Windows Internet Explorer that a developer writing Microsoft ActiveX Controls should take into account when targeting Internet Explorer as a container.
http://msdn.microsoft.com/en-us/library/aa751970(VS.85).aspx
Memory Leak Resources
Understanding and Solving Internet Explorer Leak Patterns
This article discusses how to troubleshoot and resolve memory leaks.
http://msdn.microsoft.com/en-us/library/bb250448(VS.85).aspx
General Resources
Learn Internet Explorer
A series of topics designed to teach Internet Explorer programming.
http://msdn.microsoft.com/en-us/ie/aa740473.aspx
Measuring Browser Performance: Understanding issues in benchmarking and performance analysis
This document explains the various browser and network components and how each piece can impact performance when benchmarking
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cd8932f3-b4be-4e0e-a73b-4a373d85146d
IE8 Performance
Blog post discussing the performance changes in Internet Explorer 8.
http://blogs.msdn.com/ie/archive/2008/08/26/ie8-performance.aspx
Common Issues in Assessing Browser Performance
This blog post focuses on performance with a discussion around some of the issues impacting browser performance testing and the techniques that you can use to effectively measure browser performance.
http://blogs.msdn.com/ie/archive/2009/01/23/common-issues-in-assessing-browser-performance.aspx
How to improve browsing performance in Internet Explorer
This article describes how to improve browsing performance in Internet Explorer.
http://support.microsoft.com/kb/153790
How to optimize Internet Explorer
This article describes how to reset or optimize Internet Explorer 7.
http://support.microsoft.com/kb/936213
How to troubleshoot Internet Explorer issues in Windows Vista and in Windows XP
This article discusses how to troubleshoot possible issues that you may experience when you use Windows Internet Explorer 7 or Windows Internet Explorer 8 on a computer that is running Windows Vista.
http://support.microsoft.com/kb/936215
Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.
Tuesday, November 23, 2010
Developer Tools & Platforms Performance [from support.microsoft.com]
at
12:57 PM
0
comments
Posted by
roni schuetz
Labels: .net, performance
Thursday, August 14, 2008
Check if server is available before you make requests
I had to implement a fallback system in case one of my primary servers is not available anymore because of any reason. There were no option to access servers over a loadbalancer or something else then a direct routing to each server.
After some compassion's how much time I gone waste for each request between usage of sockets or HttpWebRequest / WebRequest I decided to work directly with Sockets.
The implementation I decided to go for were quite easy (remember: keep it simple as possible) and its fast like hell - 9ms I'm loosing each check if the server is available or not. We use 2 servers - so I have to remember that there is a total of 18ms I'm loosing each time we have a running cycle to analyse data. In general my tests gave showed me that 5 of the 9 ms are used for DNS.GetHostEntry(ServerName) - if you can use IP-Addresses then I suggest to do it that way. Check out one of my previous post about this DNS.GetHostEntry(ServerName) - IPAddress.Parse("127.0.0.1") vs. Dns.GetHostEntry("127.0.0.1")
With those ~20ms we can leave very good because a cycle needs right now something around 2.5min and it can be a max. of 15min. So how to solve this is the question, here the codesample from MSDN which I adapted and using to validate if my servers are online: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx
Formatted Code is available here: http://www.ronischuetz.com/code/CheckIfServerIsAvailable.htm
1: private static bool ConnectSocket(string server, int port)
2: {3: Stopwatch sp = new Stopwatch();
4: IPHostEntry hostEntry = null;
5: bool result = false;
6: sp.Start();7: // Get host related information.
8: hostEntry = Dns.GetHostEntry(server); 9: sp.Stop();10: Log.Info(string.Format("ConnectSocket->Dns.GetHostEntry({0}) needed: {1}ms ",server, sp.ElapsedMilliseconds));
11: sp.Reset(); 12: 13: // Loop through the AddressList to obtain the supported AddressFamily. This is to avoid
14: // an exception that occurs when the host IP Address is not compatible with the address family
15: // (typical in the IPv6 case).
16: foreach (IPAddress address in hostEntry.AddressList)
17: { 18: sp.Start();19: IPEndPoint ipe = new IPEndPoint(address, port);
20: Socket tempSocket = new Socket(ipe.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
21: tempSocket.ReceiveTimeout = 1000; 22: tempSocket.SendTimeout = 1000;23: // this is very important!!! Do not delete this.
24: tempSocket.NoDelay = true;
25: 26: try
27: { 28: tempSocket.Connect(ipe);29: #region Status Check
30: if (tempSocket.Connected)
31: {32: #region Connnected Section
33: result = true;
34: if (tempSocket != null)
35: {36: try
37: { 38: tempSocket.Shutdown(SocketShutdown.Both); 39: tempSocket.Close(); 40: }41: catch (Exception ex)
42: {43: // do nothing - only release resources and don't let the system fuck up
44: }45: finally
46: {47: tempSocket = null;
48: } 49: }50: #endregion Connnected Section
51: break;
52: }53: else
54: {55: continue;
56: }57: #endregion End Status Check
58: }59: catch (Exception ex)
60: {61: string title = string.Format("Could not connect to server:{0}:{1} - " + Environment.NewLine + ex.Message + Environment.NewLine + ex.StackTrace, server, port);
62: Log.Info(title); 63: Log.Fatal(title);64: result = false;
65: } 66: 67: sp.Stop();68: Log.Info(string.Format("ConnectSocket->hostEntry.AddressList({0}) needed: {1}ms to connect to server ", ipe.Address.ToString(), sp.ElapsedMilliseconds));
69: sp.Reset(); 70: }71: return result;
72: }
at
8:51 PM
0
comments
Posted by
roni schuetz
Labels: C#, Database, development, Helper Code, performance, Testing
Friday, July 18, 2008
Improve Web Application Performance
Introduction
In the IT world, software applications are being rapidly developed. Clients, and so employers, are just looking for those teams/individuals who can build up applications rapidly, just bothering to make their application live; but what often happens after an application goes live is that users start to use the application and it doesn’t respond well. At this point, clients start to lose users and business.To code an application is not a big deal; I believe it can be done by virtually anyone, meaning it is not necessary to have great knowledge or experience. Improving performance of an existing application (especially an one put together rapidly) could be quite risky and could cause many ripple effects. Things must be planned first to avoid horrible results.The following are a few points that can make a site scalable and reliable; but which may initially slow down development. I believe that overall, when maintenance and future changes are taken into account, total development time would be reduced.
1. Minimize HTTP based Requests
2. HTTP Compression:
3. Correct Formatted Images at the Right Place:
4. Compress CSS, JavaScript and Images
5. CSS at Top
6. Javascript at Bottom
7. Content Delivery Network: (CDN)
8. Ajax
9. Ajax vs. Callback
10. Reduce Cookie size
11. Use Cache appropriately
12. Upload compiled code rather than source code
Following are few good practices to gain better performance:
- For HTTP compression, GZip is considered the most effective and most popular by means of browsers and HTTP server. It can reduce file size up to 70% in size.
- Always keep JavaScript and CSS in external files.
- Avoid redirects until needed. Server.Transfer is also provided so consider that as well since it performs better in some conditions.
- Minimize use of Iframes as it's costly.
- Avoid try-catch blocks for control-flow as they perform poorly. Exceptions should be used only in truly exceptional situations.
- Minimize Cookie/CSS sizes.
- Minimize DOM objects on page as they are heavy weight.
- Use link tags rather than @import to use/link up CSS.
- Favicon, being a static image displayed in the browser’s address bar, should be cacheable and compressed.
- Always prefer a cache-friendly folder structure. For example, create specific folders for static contents, like /static for static images/static pages.
- SSL can never be cached so minimize its usage. Keep it for those pages which need to be secure, rather than using it for all the pages.
- HTTP Post requests can’t be cached, so choose the HTTP method appropriately.
- Prevent Denial of Service (Dos) attacks.
- Prevent SQL Injection.
- Prevent Cross Site Scripting (XSS).
Read the full article by dr.honey (IT SURGEON) at the following link: http://developerscon.blogspot.com/2008/06/improve-web-application-performance.html
at
9:16 PM
0
comments
Posted by
roni schuetz
Labels: .net, cache, Database, java script, links, network, performance
Sunday, June 22, 2008
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.
at
1:44 PM
2
comments
Posted by
roni schuetz
Labels: cache, memory, Nhibernet, performance, SharedCache, SharedCache thought
Thursday, February 28, 2008
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.
- 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.
- 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. - Configurable maximum cache size and the load factor when the system starts to purge cached items.
- With the upcoming release we gone provide Key Cache Dependency (it can be that in future we will also support SQL and File Dependency)
- With the upcoming release we gone provide bulk operations
- We use a binary format which has an overload payload of 36 bytes per Message.
- Simple server and client configuration with custom provider sections
- We use internally a custom thread pool which is configurable.
- We provide a small management console with some basic information about cache nodes.
- 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 - Last but not least: it’s absolutely free and open source!
at
7:58 PM
0
comments
Posted by
roni schuetz
Labels: .net, cache, indeXus.Net, performance, SharedCache, SharedCache thought
Friday, February 22, 2008
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.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.
at
1:59 AM
0
comments
Posted by
roni schuetz
Labels: memory, performance, SharedCache, SharedCache thought, surprised, sync vs async
Tuesday, February 12, 2008
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)”
at
10:36 PM
0
comments
Posted by
roni schuetz
Labels: cache, indeXus.Net, performance, SharedCache
Monday, February 11, 2008
Shared Cache - compare results between version 1.0.2.134 and 2.0.0.140 and upper
- 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.
240 - Add 10 objects with the size approx. of 100kb.
280 - Add 10 objects with the size approx. of 1MB.
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.
at
12:00 AM
0
comments
Posted by
roni schuetz
Labels: cache, memory, network, performance, SharedCache, sync vs async, Threading
Sunday, February 10, 2008
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
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:
- The Socket has not been used for a certain amount of time
- 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
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:
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
at
1:34 PM
4
comments
Posted by
roni schuetz
Labels: .net, C#, cache, code sample, debug, development, Helper Code, memory, network, performance, SharedCache, SharedCache thought, Threading
Monday, February 04, 2008
IPAddress.Parse("127.0.0.1") vs. Dns.GetHostEntry("127.0.0.1")
Did you ever come to the point where you had to get several times an System.Net.IPEndPoint? The constructor takes an IPAddress and a specific Port which you select... Now guess what... if you handle with known IPAddresses within your Network you should not use Dns.GetHostEntry just because its very very very slow, as long you know the IP Address ;-). In almoast every online example I have seen so far online I always have seen usage of Dns.GetHostEntry.... people thats so wrong in my point of view and after my measurment - correct me if I'm wrong but I love to measure :-) !
Once you deal with other issues maybe there is no other way but since a while I grab the WWW around tcp and udp socket issues and one of this issues is to give a solution with object pooling while a unexpected load arrives on a web-server and it needs to open more then the expected amount of sockets to its server. So here we can have e.g. instead of the normal 20 open connections fast 120 - 150 additional sockets. This additional instances are there for a certain time amount and afterwards they get closed again but even then. If you need to be fast, then every millisecond counts since we are talking about scalability.
In general I gone compare about the following code lines:
IPEndPoint ep = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 48888);
and
IPEndPoint ep = new IPEndPoint(Dns.GetHostEntry("127.0.0.1").AddressList[0], 48888);
I have done a small test to measure if this two options are really have such a hugh difference:
Run no. 1 with: 127.0.0.1
IP-Address Parse average: 6 milliseconds
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 8
DNS GetHostEntry average: 125 milliseconds
56, 57, 66, 67, 68, 70, 70, 71, 71, 72, 78, 78, 79, 80, 81, 81, 82, 82, 83, 85, 86, 87, 88, 88, 91, 95, 96, 96, 97, 97, 98, 99, 99, 101, 102, 103, 104, 106, 110, 111, 113, 114, 116, 117, 118, 119, 122, 127, 128, 129, 130, 130, 131, 133, 143, 144, 144, 145, 145, 146, 146, 147, 148, 148, 149, 150, 155, 155, 156, 157, 158, 158, 159, 159, 160, 161, 161, 162, 162, 163, 164, 165, 166, 167, 169, 169, 170, 171, 172, 173, 173, 174, 175, 175, 176, 177, 177, 178, 178, 179,
Run no. 2 with: 192.168.xxx.21
IP-Address Parse average: 11 milliseconds
10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12
DNS GetHostEntry average: 168 milliseconds
95, 99, 100, 101, 105, 106, 106, 109, 110, 112, 121, 121, 122, 123, 124, 125, 126, 132, 133, 134, 136, 137, 139, 141, 141, 143, 144, 146, 148, 153, 153, 155, 155, 156, 157, 157, 160, 163, 163, 164, 165, 166, 168, 168, 169, 170, 170, 173, 177, 177, 178, 179, 180, 180, 181, 181, 182, 182, 183, 184, 184, 185, 186, 186, 187, 187, 188, 191, 192, 193, 193, 194, 195, 195, 196, 197, 197, 198, 199, 200, 201, 202, 203, 203, 204, 205, 206, 206, 207, 207, 208, 208, 209, 210, 211, 211, 215, 217, 218, 218,
incredible how much the difference is.
The formatted code is available over here: http://www.ronischuetz.com/code/IpParseVsDnsGetHostEntry.html
and the c# version you can get from here:
http://www.ronischuetz.com/code/IpParseVsDnsGetHostEntry.cs.txt
at
11:53 PM
1 comments
Posted by
roni schuetz
Labels: .net, C#, code sample, development, performance, Testing
Saturday, January 26, 2008
.Net CLR Memory Performance Monitoring
If you need to monitor you memory the usage of Perfmon is needed to start. There are also some shareware and MS CLR Profiler available but lets explain the basic's for the usage of Perfmon.
to start perfmon: start -> run: type: perfmon and the Performance SnapIn window appears.
the window starts with some default counters, usually you those are not the counters you will have to look on. Therefor you need to choose the right selection, which you do with right click -> add counters. Then you can select your requested counters as shown below:
Lets describe the different counters we have:
- # Bytes in all Heaps: This counter is the sum of four other counters; Gen 0 Heap Size; Gen 1 Heap Size; Gen 2 Heap Size and the Large Object Heap Size. This counter indicates the current memory allocated in bytes on the GC Heaps.
- # GC Handles: This counter displays the current number of GC Handles in use. GCHandles are handles to resources external to the CLR and the managed environment. Handles occupy small amounts of memory in the GCHeap but potentially expensive unmanaged resources.
- # Gen 0 Collections: This counter displays the number of times the generation 0 objects (youngest; most recently allocated) are garbage collected (Gen 0 GC) since the start of the application. Gen 0 GC occurs when the available memory in generation 0 is not sufficient to satisfy an allocation request. This counter is incremented at the end of a Gen 0 GC. Higher generation GCs include all lower generation GCs. This counter is explicitly incremented when a higher generation (Gen 1 or Gen 2) GC occurs. _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value.
- # Gen 1 Collections: This counter displays the number of times the generation 1 objects are garbage collected since the start of the application. The counter is incremented at the end of a Gen 1 GC. Higher generation GCs include all lower generation GCs. This counter is explicitly incremented when a higher generation (Gen 2) GC occurs. _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value.
- # Gen 2 Collections: This counter displays the number of times the generation 2 objects (older) are garbage collected since the start of the application. The counter is incremented at the end of a Gen 2 GC (also called full GC). _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value.
- # Induced GC: This counter displays the peak number of times a garbage collection was performed because of an explicit call to GC.Collect. Its a good practice to let the GC tune the frequency of its collections.
- # of Pinned Objects: This counter displays the number of pinned objects encountered in the last GC. This counter tracks the pinned objects only in the heaps that were garbage collected e.g. a Gen 0 GC would cause enumeration of pinned objects in the generation 0 heap only. A pinned object is one that the Garbage Collector cannot move in memory.
- # of Sink Blocks in use: This counter displays the current number of sync blocks in use. Sync blocks are per-object data structures allocated for storing synchronization information. Sync blocks hold weak references to managed objects and need to be scanned by the Garbage Collector. Sync blocks are not limited to storing synchronization information and can also store COM interop metadata. This counter was designed to indicate performance problems with heavy use of synchronization primitives.
- # Total committed Bytes: This counter displays the amount of virtual memory (in bytes) currently committed by the Garbage Collector. (Committed memory is the physical memory for which space has been reserved on the disk paging file).
- # Total reserved Bytes: This counter displays the amount of virtual memory (in bytes) currently reserved by the Garbage Collector. (Reserved memory is the virtual memory space reserved for the application but no disk or main memory pages have been used.)
- % Time in GC: % Time in GC is the percentage of elapsed time that was spent in performing a garbage collection (GC) since the last GC cycle. This counter is usually an indicator of the work done by the Garbage Collector on behalf of the application to collect and compact memory. This counter is updated only at the end of every GC and the counter value reflects the last observed value; its not an average.
- Allocated Bytes/sec: This counter displays the rate of bytes per second allocated on the GC Heap. This counter is updated at the end of every GC; not at each allocation. This counter is not an average over time; it displays the difference between the values observed in the last two samples divided by the duration of the sample interval.
- Finalization Survivors: This counter displays the number of garbage collected objects that survive a collection because they are waiting to be finalized. If these objects hold references to other objects then those objects also survive but are not counted by this counter; the "Promoted Finalization-Memory from Gen 0" and "Promoted Finalization-Memory from Gen 1" counters represent all the memory that survived due to finalization. This counter is not a cumulative counter; its updated at the end of every GC with count of the survivors during that particular GC only. This counter was designed to indicate the extra overhead that the application might incur because of finalization.
- Gen 0 Heap Size: This counter displays the maximum bytes that can be allocated in generation 0 (Gen 0): its does not indicate the current number of bytes allocated in Gen 0. A Gen 0 GC is triggered when the allocations since the last GC exceed this size. The Gen 0 size is tuned by the Garbage Collector and can change during the execution of the application. At the end of a Gen 0 collection the size of the Gen 0 heap is infact 0 bytes; this counter displays the size (in bytes) of allocations that would trigger the next Gen 0 GC. This counter is updated at the end of a GC; its not updated on every allocation.
- Gen 0 Promted Bytes/Sec: This counter displays the bytes per second that are promoted from generation 0 (youngest) to generation 1; objects that are promoted just because they are waiting to be finalized are not included in this counter. Memory is promoted when it survives a garbage collection. This counter was designed as an indicator of relatively long-lived objects being created per sec. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval.
- Gen 1 heap size: This counter displays the current number of bytes in generation 1 (Gen 1); this counter does not display the maximum size of Gen 1. Objects are not directly allocated in this generation; they are promoted from previous Gen 0 GCs. This counter is updated at the end of a GC; its not updated on every allocation.
- Gen 1 Promted Bytes/Sec: This counter displays the bytes per second that are promoted from generation 1 to generation 2 (oldest); objects that are promoted just because they are waiting to be finalized are not included in this counter. Memory is promoted when it survives a garbage collection. Nothing is promoted from generation 2 since it is the oldest. This counter was designed as an indicator of very long-lived objects being created per sec. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval.
- Gen 2 heap size: This counter displays the current number of bytes in generation 2 (Gen 2). Objects are not directly allocated in this generation; they are promoted from Gen 1 during previous Gen 1 GCs. This counter is updated at the end of a GC; its not updated on every allocation.
- Large Object Heap Size: This counter displays the current size of the Large Object Heap in bytes. Objects greater than 20 KBytes are treated as large objects by the Garbage Collector and are directly allocated in a special heap; they are not promoted through the generations. This counter is updated at the end of a GC; its not updated on every allocation.
- Process ID: This counter displays the process ID of the CLR process instance being monitored.
- Promted Finalization-Memory from Gen 0: This counter displays the bytes of memory that are promoted from generation 0 to generation 1 just because they are waiting to be finalized. This counter displays the value observed at the end of the last GC; its not a cumulative counter.
- Promted Memory from Gen 0: This counter displays the bytes of memory that survive garbage collection (GC) and are promoted from generation 0 to generation 1; objects that are promoted just because they are waiting to be finalized are not included in this counter. This counter displays the value observed at the end of the last GC; its not a cumulative counter.
- Promted Memory from Gen 1: This counter displays the bytes of memory that survive garbage collection (GC) and are promoted from generation 1 to generation 2; objects that are promoted just because they are waiting to be finalized are not included in this counter. This counter displays the value observed at the end of the last GC; its not a cumulative counter. This counter is reset to 0 if the last GC was a Gen 0 GC only.
at
3:20 PM
0
comments
Posted by
roni schuetz
Labels: .net, C#, cache, development, memory, performance, Windows XP
GC.Collect - how it really works - .net Garbage Collection
The GC (Garbage Collection) in .Net is a Win32 process within HEAP which is initially created by the OS (Operation System) based on CLR request. This request add 2 segments of 16 MB each (16kb committed). One of them is allocated for the Gen0, Gen1 & Gen2 and the second segment is used for LOH (Large Object Heap). Objects greater than 20 KBytes are treated as large objects by the Garbage Collector and are directly allocated in a special heap
While we start to create small objects the first segment starts to grow. If we suppose that we keep all instantiated objects without ever releasing any instance until the segment gets full, the CLR ask OS for another segment of 16MB (16kb committed) and continues to allocate object space from that new segment which has been received by the operating system.
If we free up memory, lets suppose all allocated 32 MB, CLR leaves you still with a HEAP size of 32 MB even that nothing is committed. The GC still held all free space and will not return it to the OS until we use a memory pressure.
With the memory pressure the operating system sending a signal to the CLR to trim the working set and the CLR will return additional segments to OS.
The conclusion of it is simple, there is plenty of free memory and the operating system does not claim anything from running processes.
at
2:55 PM
0
comments
Posted by
roni schuetz
Labels: .net, C#, cache, development, memory, performance, Windows XP
Friday, January 25, 2008
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
at
1:00 AM
0
comments
Posted by
roni schuetz
Labels: .net, C#, cache, development, indeXus.Net, memory, network, performance, SharedCache, SharedCache thought, Testing
Wednesday, January 02, 2008
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 7
SharedCache thought no. 7: scope's and expectations
lets start to talk about expectations, do not assume and verify that it works exactly as expected. Take advantage of perfmon and the notify application to monitor the cache, what it contains and how it works.
Keep things in the right scope, which means do not use Cache functionality for session information. HTTP Session objects can be used for caching user- and / or session specific information but don't use them as a cache for global information - and the opposite.
------------------
Download your copy of SharedCache: http://www.sharedcache.com
SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions. Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:34 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 6
SharedCache thought no. 6: Identities and Keys
Like everywhere you can make yourself an easier life while you have a clear idea on how you will proceed with your identities / keys. If you create an identity class ensure equal() will be the same. A tip to all those people to all the people they don't like to override the ToSting() method of their objects. Its might be very helpful for debugging to have a good override method. From my perspective a native .Net structure match all my needs, e.g. string , long, int, etc.
------------------
Download your copy of SharedCache: http://www.sharedcache.comSharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions. Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:32 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 5
SharedCache thought no. 5: Optimize Serialization
Serialization - easy - just add an attribute on top of the class and we are done, right? Objects that are stored in cache need to be serialized and the default CLR (.net) standard / default serialization is inefficient and has poor performance. beside the fact that the object output size is huge which has another impact: Memory usage can be reduced by 50% by implementing the ISerializable() attribute.
Another very interesting point is that depend on your object data structure, consider to serialize using data streams instead of object streams this can make a phenomenal impact in the positive way. Serialization performance improvements are up to an order of magnitude, the reduction in size can be up to 80%!!!
Which is actually not less this is a huge difference!
------------------
Download your copy of SharedCache: http://www.sharedcache.comSharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.
Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:31 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 4
SharedCache thought no. 4: Granularity!
its a great keyword but we need to consider about it. Every application contains a natural granularity for all data. RDBMS* have a normalized granularity which are exposed over the table. Lets take ODBC / JDBC - based applications which provide normally an statement execution granularity and a result set granularity. ORM based applications and cache intensive applications often have an object oriented granularity that mirrors the data model from your RDBMS*.
The conclusion is the following: Normally each business object class provides a cache relation. Lets take the country and region, both will pick up data from the cache and not from the RDBMS after the first initial load. Each object intends to have a natural key. Lets say we can take the countryId or regionId or even make a combination with some other data like this: countryId + Iso2Code ;
Application Objects are ususally very complex with a lot other options, lets say that you enable your country class to contain a list with all its regions. If the regions already in the cache you dont need to access your RDBMS* system for nothing ;-)
Create yourself a caching strategy, this will make you life easier to manage large object graphs and enables efficient lazy loading functionality.
------------------
Download your copy of SharedCache: http://www.sharedcache.com
SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.
Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:26 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 3
SharedCache thought no. 3: Modeling is religion - no its a tool!
Design Mode its not new at all, then any object oriented developer have using domain modeling for years. Application developers they act as Database Administrators have used modeling to to break down their ideas into a Database design that could provide both sides: optimal application implementation and optimal database organisation.
Now what is this Domain Model? It is a combination between Data Model and Behavioral Model. The data model describes actually nothing else then the state the application maintains in terms of persistence and run-time data (e.g.: session data / request data / response data / etc. ). The Domain Model is not so far away from the SOA (Service Oriented Architecture). The Data model is actually analog to the information which is encapsulated and managed behind a set of services. While the behavioural model is the same like a set of services which are exposed by brokers. The value behind it is simple: Data Model exist independently of the behavioural model, supporting the separation of a controller from the model in an MVC architecture.
------------------
Download your copy of SharedCache: http://www.sharedcache.com
SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.
Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:26 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 2
SharedCache thought no. 2: How do I gone access my data?
there are almost endless way's how to retrieve data from your RDBMS* system.
Here a small list of options:
- ORM (Object Relational Mappers) [my favorite: MyGeneration thanks to Mike Griffin for this amazing tool]
- ODBC / JDBC (or other direct API's)
- own implementation [ your are gone to work very hard :-) ]
in almost every application there is a "best way" to access your data. A large-scale set oriented application will usually be ODBC / JDBC oriented. While a mix of set- and identiyoriented approaches are indications for ORM's. Its very important to understand and to know your application to make the decision, most applications have a best way depends on their scalability requirements and development time.
Consider: Databases don't hate anything more then to retrieve data of one single row! To choose the wrong approach is disastrous!!
Lets try to say it in this way: RDBMS (ODBC / JDBC) systems are optimized for set based queries and operations including joins and data aggregation. They will crumble with heavy row-level access applications (1+N access patterns).
Its always a good approach to discuss an architecture open, then you have to consider many things and you should be careful while you're taking your decision about it. Not always the obvious way is the "best choice".
Most applications have a mix of intensive row-level and large set-level operations, which lend themselves poorly to any noted approach. I haven't seen till today any architecture which the issue doesn't come up: "exceptions to the rule"! Even if you have a well-architecture and carefully designed application there can be always exceptions that require to break the rule for a specific approach how to access data.
Normally, or at least in 90% of the cases I have seen till today, its possible to cache ODBC result sets. I have also seen ORM systems which are able to make SQL query set-based optimization that performs the entire operation within the RDBMS. You should always consider how your application is consuming data.
------------------
Download your copy of SharedCache: http://www.sharedcache.com
SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.
Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:26 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql
architecture and distributed caching thoughts in combination with indeXus.Net SharedCache - Part 2
SharedCache thought no 1: Define a clear delineation for the cache responsibility
You could e.g. define to use caching in your model within your DAO**, where the cache holds the object value. The goal is to ensure that all accesses are served from SharedCache instead of your RDBMS*. The access latency to SharedCache will be some 0.001 sec. while your call to the RDBMS* can take up to 0.050 sec. - it does not seems to make much difference but while we are talking about scalable systems - here the changes starting.
------------------
Download your copy of SharedCache: http://www.sharedcache.com
SharedCache will soon release session provider, which will assist you to work with SharedCache and ASP.Net Sessions.
Soon i will add some additional thought about how to provide optimistic transactional handling with SharedCache.
SharedCache is free and open source the only way you can see exactly what happens within your application.
* - RDBMS - relational database management system
** - DAO - Data Access Objects
at
7:26 PM
0
comments
Posted by
roni schuetz
Labels: .net, asp.net, C#, cache, Database, performance, SharedCache, SharedCache thought, sql

