Collected thoughts about software and site performance ...

Web performance matters. Responsive sites can make the online experience effective, even enjoyable. A slow site can be unusable. This site is about online performance, how to achieve and maintain it, its impact on user experience, and ultimately on site effectiveness.

Home | Entries about Software Engineering (14), in reverse date order:

If I Had A Hammer ...

Illustration: Ultimate Geeks Multi-Tool Hammer

If I had a hammer
I'd hammer in the morning
I'd hammer in the evening
All over this land
I'd hammer out danger
I'd hammer out a warning
I'd hammer out love between my brothers and my sisters
All over this land

--Pete Seeger and Lee Hays, 1949 [Wikipedia]

In May 2007, after I wrote about Controlling What You Can't Measure, I had a conversation with Ben Simo (see the comments) about metrics and tools ...

Click to read more ...

Scalability is Not Optional

Illustration: Kent Langley

My recent post, Asynchronous Architectures [4], summarized a presentation by Werner Vogels at the 2007 QCON conference in London.

A subsequent post by Kent Langley in his new ProductionScale blog -- entitled Getting Rid of the Relational Database -- supports the arguments advanced by Vogels.

Click to read more ...

Asynchronous Architectures [4]

Illustration: Werner Vogels

This is the fourth in a series of posts presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment.

In a QCon conference presentation on Availability and Consistency or how the CAP theorem ruins it all, Werner Vogels, Amazon CTO, examines the tension between availability & consistency in large-scale distributed systems, and presents a model for reasoning about the trade-offs between different solutions. I recommend you find time to watch the entire 52-minute video.

Click to read more ...

Asynchronous Architectures [3]

Dan Pritchett's Design Rule

Performance Wisdom: 13

Always assume high latency, not low latency

This post is the third in a series presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment.

The first reviewed the case for asynchronous communication among interdependent components or services, and Bell's Law of Waiting. The second highlighted The Fallacies of Distributed Computing, and discussed the importance of reflecting the business process in distributed systems design.

This post reviews The Challenges of Latency, an article about how asynchronous architectures can improve the quality of Web applications, published on the InfoQueue site by eBay architect Dan Pritchett in May 2007. Dan's article is especially relevant today, given the high level of interest in adopting Web services and SOA approaches.

Click to read more ...

Asynchronous Architectures [2]

The Fallacies of Distributed Computing

Performance Wisdom: 12

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
...

This post is the second in a series presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment. The first post reviewed the general case for asynchronous communication among interdependent components or services, and highlighted Bell's Law of Waiting.

The Fallacies of Distributed Computing highlight crucial differences between centralized and distributed computing. Network components introduce potential problems that a centralized solution does not have to consider.

In this post I discuss how the design of distributed systems should draw on that of manual business systems. Of course, distributed computing can shorten the timescales of some business operations enormously. But drawing analogies with the way manual systems work is an observation that will help us to design efficient and scalable distributed systems.

Click to read more ...

Asynchronous Architectures [1]

Bell's Law of Waiting

Performance Wisdom: 11

All computers wait at the same speed

In Five Scalability Principles, I reviewed an article published by MySQL about the five performance principles that apply to all application scaling efforts. When discussing the first principle -- Don't think synchronously -- I stated that Decoupled processes and multi-transaction workflows are the optimal starting point for the design of high-performance (distributed) systems.

That's a quote from High-Performance Client/Server, from a section on Abandoning the Single Synchronous Transaction Paradigm, in Chapter 15, Architecture for High Performance. My 1998 book is out of print now, and contains some outdated examples and references. But most of the discussions of performance principles are timeless, and you can pick up a used copy for about $3.00 at Amazon.

So I am planning some more posts built around excerpts from the manuscript. I'll be updating and generalizing the terminology as necessary for today's environments, and adding some guidelines in my Performance Wisdom series.

Click to read more ...

Java Performance Optimization

Illustration: Pro Java EE5 Performance Management and Optimization (cover)

Do you subscribe to email newsletters? If you're like me, you get lots of them. New ones appear in my inbox every morning. They pile up, demanding to be read. In fact, they seem to breed like rabbits, producing new offspring -- when did I express an interest in Enterprise VOIP Security Architecture issues? Sometimes in a housekeeping splurge I delete a few dozen at once, suffering a momentary twinge of anxiety at having perhaps missed something important. So usually I skim them before hitting the delete button.

TechTarget's Search Software Quality service seems to be especially prolific, but is also a regular source of interesting references -- like TheServerSide.com, the subject of a recent note. According to the site's home page:

Java Performance Management for Large-Scale Systems

There are many classes of enterprise applications that have stringent performance and scalability requirements. TheServerSide.com has assembled a collection of resources to help you better design, develop, test and manage high performance, large-scale systems - learn new and innovative approaches for performance tuning, memory management, concurrent programming, JVM clustering and more.

Click to read more ...

Distributing Java Applications

Illustration: a checklist

Testing Anti-Patterns

Clustering and distributing Java applications has never been easier than it is today. As a result, writing good distributed performance tests and tuning those applications is increasingly important. Performance tuning and testing of distributed and/or clustered applications is an important skill and many who do it can use a little help.

That paragraph introduces a new series of four posts about how to approach testing for distributed Java applications by Steve Harris of Terracotta, who blogs as DSO Guy. Steve frames his guidelines as anti-patterns -- in other words, pitfalls or "commonly-reinvented bad solutions to problems" to be avoided [see Wikipedia].

Click to read more ...

Ten Dimensions of a Web Application

Illustration: Jonathan Kohl

Jonathan Kohl, is a consultant, author, and speaker who specializes in software testing. His blog, Collaborative Software Testing, includes many discussions of frameworks, heuristics, and mnemonics that serve as guides for different aspects of testing.

In particular, a November 2006 post on Modeling Web Applications presented a 9-part framework for testing Web applications and the associated mnemonic, FP DICTUMM.

Click to read more ...

Controlling What You Can't Measure

Tom Gilb on Measurement

Management Wisdom: 2

Performance Wisdom: 6

Anything you need to quantify can be measured in some way that is superior to not measuring it at all

Posts on The Importance of Measurements and Controlling Software Projects have reviewed the origin of the saying that "you can't manage what you can't (or don't) measure". Today I look more closely at its meaning and validity -- how true is it?

One apparent contradiction is that this much quoted fact of management is also widely viewed as a fallacy -- or at least, as an over-exaggerated claim -- especially by people in the software engineering profession, which seems (in the person of Tom DeMarco) to have coined the saying in the first place. That contradiction was highlighted in a 2003 book by Robert L. Glass, Facts and Fallacies of Software Engineering [Amazon].

Click to read more ...

Displaying entries 1 - 10 of 14    Previous Page | Next Page [older] | Home