| Solaris |
|
|
Our goal is to assure the architectural choices will likely lead to acceptable performance and avoid surprising resource consumption. Each project should have performance goals.
The goals should be specific about how they will be evaluated and on what type of test platform. Test plans should include verifying that any performance regression is identified, so it can be evaluated. If the performance of the typical case is improved, but certain usage performs drastically worse, a careful, educated trade-off must be made.
Resources and constraints might be how many processors can be used, kernel memory, file descriptors, virtual memory, filesystem space, ports consumed. Which resources are likely to be bottlenecks? Consider any limits to the project's scalability such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc. Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical?
What is the impact on system performance (positive or negative)?
What are the project's effects on boot time requirements? What is the average memory usage or working set of this component?
Minimize the working set of the component that wakes up just to determine if there's work to do. Try to consume only negligible resources on systems that do not require the program or service, e.g., by using inetd.
Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance, capacity, and system load?
Terms of Use
|
Privacy
|
Trademarks
|
Copyright Policy
|
Site Guidelines
|
Site Map
|
Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.
© 2012, Oracle Corporation and/or its affiliates.