Is our vendor trying to get us to pay for applications we really don't need?

Our company is investigating a software which will allow our HR people to search and recruit new staff. This system is designed using Lotus Notes and offers two ways of access for two user types: recruiters will use the thick client (Notes client) and the applicants the browser based client (typically via MS-IE). The vendor recommends at least 2 Mbps for bandwidth for the application for both types of access. We have doubts on their claim. What should we do?

    Requires Free Membership to View

    Login

The vendor may be right – a minimum 2 Mbps capacity may take care of what you need.

For example, consider that typical Web access will serve at about 100 kbps per browser client. And effects like bandwidth-delay product can limit how much access a thick client can get on longer links. Finally, what really matters is the peak and/or sustained performance you require from the network relative to the number of users you will be supporting – you didn't mention how many.

And you are right to question that estimate.

One critical factor will be how the thick client interacts with the central server. It may download a large file all at once and then upload after completing all interactive operations locally. Or it may support an on-going synchronous dialogue with every keystroke or action. It depends on the software design.

I suggest that you take the time to model the network load on your system – at least roughly.

Ask yourself the following questions:

  • How many users?
  • How are they going to be using the system?
  • How many simultaneous connections using the thick client will be supported?
  • How many simultaneous connections via the Web will be supported?
  • What type of client/server interaction is involved?
  • Do any of the connections across a WAN link include large latencies (greater than 20 ms)?

    From the type of connection/interaction, you can estimate the impact of a slow network on the end-user. And from the number of users, you can guess at the worst case for simultaneous connections. And if you have large latency connections, you can assume that they will self-limit like Web access does, depending on the interaction type.

    If modeling the performance shows the number to be in the right ballpark, you can believe the vendor. However, the next question will be: Is the network actually performing as modelled?

    Just to illustrate: A small amount of loss, for example due to congestion, on large latency links can clobber the thick clients. So you may have to be extra careful with WAN access even though they are within capacity.

    And what if there is loss caused by, say, a bad NIC? Or a duplex conflict? These are not accounted for within the network model. But they can certainly happen and it won't be the vendor's fault. Can you verify that the network is performing to spec?

    You need to undertake three things to ensure success:

    1. Determine your needs (listen to the vendor but do your own calculations)
    2. Model the network and define specs
    3. Continuously verify that the network is performing as required

    The additional information that I referred to is required to complete this exercise.

    • This was first published in October 2004

    Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.
      Back to top