On 13Nov2009 08:26, Stainforth, Matthew (SD/DS) <Matthew.Stainforth@xxxxxx> wrote: | I think this is going to depend greatly on the maturity of your | organization and could look like any of these: [...] | 4. proper load testing tools in a dedicated PST environment If feasible, I would go for (4). The tricky bit is making a test suite with your load test tool that is representative of how things will be done in the real world. Once you have that you can set up something to measure usage. Remember that lack of bandwidth (up to a point) won't result in failure for your clients, more probably degraded performance. The flip side of that is that if you're testing on a LAN the high local bandwidth can skew the results of your test (i.e. indicate you may need more bandwidth than you really do) because I/O bound stuff can run faster. Make sure your test has tunable delays to constrain this "run really fast" tendency. (Or if you're lucky you can make a special LAN with a tunable throughput - then you can simulate your target bandwidth more realisticly). Cheers, -- Cameron Simpson <cs@xxxxxxxxxx> DoD#743 http://www.cskk.ezoshosting.com/cs/ In article 1t8n9hINNq9j@xxxxxxxxxxxxx, mcrider@xxxxxxxxxxxxx (Mcrider) writes: >Could one of you physicist-type cyber-riders give a lucid description/ >explanation of what some folks loosely refer to as a 'tank-slapper'? An undamped oscillation of camber thrust, with positive feedback, applied to the front contact patch? :^) - Ed Green, Ed.Green@xxxxxxxxxxxx, DoD#0111 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
