|
Written by Daniel Leiderman-Gueller
|
|
Wednesday, 02 September 2009 11:20 |
Performance is one of the critical aspects of any non trivial system as it affects all parts of the system. When scaling up the chances are that some part will be a bottle neck. Here are a few ideas on analyzing the performance of a system and how to scale up. As always, an ounce of prevention saves a pound of correction.
Performance can be measured in MB/sec, requests/sec or GUI performance. The performance is actually a set of performance metrics at different stages of the system. Lets assume a system for analyzing IP traffic and generating statistics, as depicted in the following diagram.
The diagram depicts two entities: the IP decoding server and a database (DB). Assuming we need one database to hold all information, we have several limitations:
• The input to the IP decoding server (1)
• The output of the decoding server (2)
• The input to the DB (3)
The input and output of the IP decoding server are simple to understand; They refer to the processing capabilities of one server of such type (without taking into account hardware issues). Database performance is trickier as it refers to insertion into tables as well as retrieval of the inform ation or processing statistics. The system performance is actually the capacity of the lowest link in the chain.
Assuming the IP decoding server is the bottleneck, the scaling up might mean allowing for multiple IP decoding servers connecting to one database. Usually such architectural changes, due to coupling between the components might require logic changes and database modifications. In addition db constraints on multiple accesses might appear.
Scaling up of databases is much trickier, since each database vendor provides different paths for scaling. Some scaling up paths are:
• Scale using more CPUs in an SMP machine - Microsoft SQL
• Scale using more machines in cluster environment- Oracle RAC
• Scale using more machines in MPP architecture - IBM DB2
Is it known that architectural changes are expensive and disruptive, but even more so is changing database vendor. Choices of architecture and scale are critical in the basic design of a system for making a small system adaptable to growth. Tradeoff is development time or additional costs.
Being performance such a critical issue for system design, explicit requirement and clear communication to stake holders is a must. Using performance requirements for selecting the components and having a development path can reduce the possibility of having a major architectural change when scaling up. |
|
Last Updated on Wednesday, 02 September 2009 12:02 |
|
|
Written by Daniel Leiderman-Gueller
|
|
Thursday, 13 August 2009 12:53 |
|
Perspective is a great differentiator, it allows looking at the same image, but seeing complete different stories. While attending a meeting about bandwidth of Wimax, this phenomenon became extremely clear.
There were two perspectives:
1. The network provider: one Wimax cell provides 30 Mbit/s.
2. The user: one Wimax cell provides 10 Mbit/s.
They are talking the same language, the same jargon, looking at the same technical situation, but still they convey a different understanding. In this case, the difference is due to the analsys of BW for each. The user wants bi directional symetrical BW, while the network provider asks about the equipment capacity, regardless of ussage.
why this is important in every day work?
most of the time you suppose you know exactly what both of you and your coworkers are talking about. but this is only an assumption, only a general idea, unless you discuss it.
Now we get to the reason for this whole post: discuss - be sure that the assumptions are clear and that both of you communicate using the same perspective, but one should take care of not overdoing it.
One of the presenters in the meeting on Wimax summed the problem: are you buying or selling? do you want to show more or less? |
|
Last Updated on Thursday, 13 August 2009 13:03 |
|
Written by Daniel Leiderman-Gueller
|
|
Sunday, 02 August 2009 22:02 |
|
Exactly one year ago I posted my first post on this blog. Now, a year later the blog has taken an important place in my life, allowing me to discover and fulfill several goals in life.
Some cold hard numbers:
First post: August 3rd 2008
Total posts: 67 (including this one)
Visits in August 2008: 29
Visits in August 2009: 455
In a graph:
The process of blogging taught me about myself, about my voice, about my ideas and my unique proposition. I found out I'm an entrepreneur and I have to let myself do. I lost the fear of exposing my ideas and preaching for action. My English writing skills have improved, although not as enough as I wished, but I'm not stopping now.
On the negative side, allocating time to blogging was difficult and tiresome. I wanted to post twice a week, but only succeeded in posting 67 posts (1.24 posts a week).
My outlook is good, I still want to keep blogging and increase the rate to twice a week. I want to be able to write more controversial articles and provide thought for me and others.
Most important, thank you for reading! |
|
Last Updated on Sunday, 02 August 2009 22:13 |
|
Written by Daniel Leiderman-Gueller
|
|
Sunday, 26 July 2009 12:39 |
Every person has a comfort zone, where the competence is known and the risks of making fool of oneself are low. The comfort zone is like a good comfy home, where the inside is suited to stay for as long as possible. Outdoors looms the danger, full with traps and unknowns.
Some people always stay indoors; keep themselves only doing what they know, risk haters. Others are the opposite; always stay outdoors, where the danger is constant, risk lovers.
Who are you? How do you divide you attention?
In this age of information and constant change, the comfort zone is a dangerous place. Technical capacities needed today may be obsolete and the comfort zone becomes a trap. Some examples that come to mind are vacuum valve technology, mainframe maintenance and IBM AS400 programming. All of the above became obsolete within some time frame and the jobs related to them as well.
On the other hand, the risk obsolescence of new technologies, or Buzz, is even greater. What was the "emerging technology" a year ago? What about the "latest trend" that was forgotten almost as soon as it emerged? The rate of change and introduction of new "innovations" has increased to the point of being almost impossible to track.
The correct course of action should be defining circles of interest:
- Comfort zone: in this zone the capabilities should be strong, understood and feel natural, almost self evident.
- Technical similarity zone: in this zone the capabilities are limited, but that can reuse some knowledge or thought processes from the comfort zone.
- Green Field: in this zone new capabilities are required, completely different from the comfort zone.
In the comfort zone the information on changes is gathered as ongoing task, so it does not require special effort. The technical similar zone requires extending the inquiries in a direction not obvious, like learning DBA expertise for a network admin. The real growth comes from exploring and learning in the green field. What would happen for the same network administrator if he learned selling capabilities? In case of searching a new job, he will be able to be able to sell himself better or even look for a sales position.
The actual mix of learning new capabilities vs. reinforcing existing ones is very personal, but it should contain some of the three zones. Although the green field is the most difficult, it is the one who can bear more fruit that staying in the dangerous comfort zone.
|
|
Last Updated on Sunday, 26 July 2009 13:08 |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 3 of 19 |
