Results tagged “essay” from manAmplified

For years I've used or relied upon virtualization technologies such as User Mode Linux, FreeBSD Jail, VMWare, Parallels, and Xen (by virtue of EC2). All of these represent a kind of vertical or narrow virtualization, where you have a single box and are sliding into it as many virtual systems as possible. The converse to this is a kind of wide virtualization that spanning many machines.

How can you measure how far a given complex System is from the simplest System it can be? Here's a hint: distance = sqrt( Tp^2 + Tm^2 + Tv^2 + Tl^2 )

Admittedly, I've created a fair number of Singletons in my day. But I've moved on in recent years, and see the error of my ways.

You don't architect a sculpture, you sculpt it, and you don't sculpt a building, you architect it.

One value, for me, of an ESB framework is to improve the reliability and robustness of a given set of integrated applications. If a message/event producer can communicate with one or more consumers in an asynchronous way, it should. It really makes things simpler. But one thing to avoid in your routing configurations is injecting synchronous calls into an overall asynchronous process.

Quick note on using box plots to show arrival rates during specified interval periods.

Below are a few R functions I use to evaluate and tune our Squid caches, which we use in accelerator mode. The functions work by taking a real stream of requests from either an application or squid log. From there the arrival rate can be determined at every second. Or a filter can be applied and the cache hit ratio or arrival rate re-determined. Or better yet, the series can be filtered a number of times with different filter values to determine the best value for a given filter.

If you work with distributed systems, HTTP referenceable services, and specifically caching systems, you probably should check out On the Intrinsic Locality Properties of Web Reference Streams.

This blog entry has inspired me to make a few notes to work out some ideas through this rather meandering essay.

In very simple terms (read convenient simplification, see below), a queue is a serialized list of pending requests. And it is typically used to broker/filter/throttle requests to a naturally concurrent system behind it. What's interesting is that systems are typically compositions of other naturally concurrent (sub)systems. Turtles all the way down, if you will...

In response to 'test driven development', I propose 'stress driven architecture'.

When developers are asked to load test a system, most will start up a million threads to create a load on the server showing that it will eventually become un-responsive, but they have no numbers that allow them to create a load profile so they can properly plan for peak times in a production environment.