Joe Freeman

In-Memory databases and caches, either  SQL or no-SQL, are prized for the high performance and high reliability. They scale up by increasing the number of cache nodes to either partition the data for larger data sets or to replicate the data to support more parallel operations.  Systems often grow to be hundreds of nodes with some providing almost linear growth versus CPU count.    Best practices say to keep  duplicate or redundant copies of data in multiple nodes.  Disaster Recover (DR) is often integrated through WAN data replication features in the enterprise class versions of these products where data is pushed to alternative data centers. Cluster node management and other configuration concerns can can have a big impact on reliability and performance.   Teams should strive to make sure replicated copies of data are as far apart as possible, that they have a low affinity  to each other. Teams who are told "you don't care where the servers are" should be skeptical of

Standard App Topology This diagram shows a basic web app with two app servers.  It is a fairly straightforward architecture where the two app servers are used for load balancing and fault tolerance in case one server goes down.  A single data server or cluster is sufficient. Most  folks would probably actually have a web server tier between the clients and the App Instance tier but I'll skip it so some of the MS folks feel at home.   This diagram shows what happens when you start to increase the number of clients.  One of the beauties of the commodity server architecture is that you can continue to add application server instances to handle the additional load. Data servers can be clustered but there is a finite limit to the data tier size and performance.  You end up with an inverted pyramid where you application is teetering on top of a narrow data tier. NoSQL databases accelerate applications in two ways.  They increase the performance of the data tier by leaving th

This video shows a simple test TI Launchpad test bed with an RGB LED tied to three PWM pins and the red LED that comes standard. The color fading and red LED flashing are independently controlled  with the code described below. Source Code Some folks just can't wait to open the source.  Here is the TwoMsTimer source along with the demo program used in this blog. Overview Micro-controller projects often include a mix of parallel tasks.  Handling those tasks with the right priority or interleaving can be a challenge when some of the tasks happen over long  periods of time. Long is relative to the execution speed of the CPU in this case. The simplest way to handle long running activities in a micro-controller is through the use of a loop that contains some type of delay to limit the loop's speed. One of the main problems with this type of code is that the  main loop() or central routines are blocked from doing anything else while in the delay block. The following code,