About: Performance tuning is a research topic. Over the lifetime, 1376 publications have been published within this topic receiving 20838 citations. The topic is also known as: tuning & performance tuning.
TL;DR: In this article, the authors present a review of battery energy storage systems for serving grid support in various application tasks based on real-world projects and their characteristics with respect to performance and aging.
Abstract: Battery energy storage systems have gained increasing interest for serving grid support in various application tasks. In particular, systems based on lithium-ion batteries have evolved rapidly with a wide range of cell technologies and system architectures available on the market. On the application side, different tasks for storage deployment demand distinct properties of the storage system. This review aims to serve as a guideline for best choice of battery technology, system design and operation for lithium-ion based storage systems to match a specific system application. Starting with an overview to lithium-ion battery technologies and their characteristics with respect to performance and aging, the storage system design is analyzed in detail based on an evaluation of real-world projects. Typical storage system applications are grouped and classified with respect to the challenges posed to the battery system. Publicly available modeling tools for technical and economic analysis are presented. A brief analysis of optimization approaches aims to point out challenges and potential solution techniques for system sizing, positioning and dispatch operation. For all areas reviewed herein, expected improvements and possible future developments are highlighted. In order to extract the full potential of stationary battery storage systems and to enable increased profitability of systems, future research should aim to a holistic system level approach combining not only performance tuning on a battery cell level and careful analysis of the application requirements, but also consider a proper selection of storage sub-components as well as an optimized system operation strategy.
TL;DR: In this paper, Clements et al. present a UML-based SPE model for object-oriented systems, which is based on the UML UML model of sequence diagrams.
Abstract: Foreword by Grady Booch. Foreword by Paul Clements. Preface. I. INTRODUCTION AND OVERVIEW. 1. Introduction. Software and Performance. Responsiveness. Scalability. The Importance of Performance. Consequences of Performance Failures. Causes of Performance Failures. Getting It Right. How Should You Manage Performance? Reactive Performance Management. Proactive Performance Management. Software Performance Engineering. SPE Modeling Strategies. SPE Models. SPE for Object-Oriented Systems. What Does It Cost? What Do You Need? Summary. 2: SPE Quick View. SPE Process for Object-Oriented Systems. Case Study. Assess Performance Risk (Step 1). Identify Critical Use Cases (Step 2). Select Key Performance Scenarios (Step 3). Establish Performance Objectives (Step 4). Construct Performance Models (Step 5). Determine Software Resource Requirements (Step 6). Add Computer Resource Requirements (Step 7). Evaluate the Models (Step 8). Verify and Validate the Models (Step 9). SPE in the Unified Software Process. Performance Solutions. Performance Principles. Performance Patterns. Performance Antipatterns. Implementation Solutions. Summary. 3: SPE and the UML. Overview. Extending the UML. Stereotypes. Tagged Values. Constraints. Use Cases and Scenarios. Use Cases. Scenarios. Extensions to Sequence Diagram Notation. Instance Decomposition. Looping, Alternation, and References. Specifying Time. Timing Marks. Time Expressions. Timing Constraints. Time in Sequence Diagrams. Concurrency. Threads and Processes. Coregions. Parallel Composition. Synchronization. Summary. II. SPE MODELS. 4: Software Execution Models. Purpose. Representing Software Execution Models. Execution Graphs. Execution Graph Restrictions. Model Solutions. Basic Solution Algorithms. More Advanced Solution Techniques. Analysis Procedures. Execution Graphs from Sequence Diagrams. ICAD Case Study. Architecture 1. Architecture 2. Analysis of Results. Architecture 3. Modeling Hints. Summary. 5: Web Applications and Other Distributed Systems. Introduction. Web Applications. Distributed Object Technology. Middleware. Limitations of Distributed Object Technology. Effective Development with Distributed Object Technology. Modeling Distributed System Interactions. Types of System Interactions. Software Execution Model Representation. Representing Middleware Overhead. Software Model Solution Approximations. Example: Web e-Commerce Application. Database Scenario. Order Process Scenario. Example Summary. Modeling Hints. Summary. 6: System Execution Models. Introduction. System Model Basics. Performance Metrics. Solving the Queueing Model. Networks of Queues. Deriving System Model Parameters from Software Model Results. Using the System Model for SPE. Advanced System Models. Alternate Solution Methods. Schedulability. Distributed System Case Study. Synchronization Model. Modeling Hints. Summary. III. DATA COLLECTION. 7: SPE Data Collection. Introduction. SPE Data Requirements. Key Performance Scenarios. Performance Objectives. Execution Environment. Software Resource Requirements. Computer Resource Requirements. Data Gathering Issues. Performance Walkthrough. Topics. When to Conduct Performance Walkthroughs. Example. Tips for a Successful Performance Walkthrough. Resource Estimation Techniques. Use Measurements. Study Measurements. Use a Mentor. Best-Worst Case Estimates. What to Estimate. Estimating I/O Requirements. Estimating Network Messages Obtaining Computer Resource Requirements. Summary. 8: Software Measurement and Instrumentation. Introduction. What Should You Measure? Workload Data and Data Characteristics. Path Characteristics. Software Resources and Processing Overhead. Computer Resource Usage. Planning for Performance Measurement. Key Considerations. Performance Benchmarks. Designing and Conducting Measurement Studies. Performance Measurement Concepts. Terminology. Factors That May Affect Measurements. Data Collection Techniques and Tools. Data Collection Techniques. Measuring SPE Data. Instrumentation. Instrumentation Design Considerations. Implementation Alternatives. Data Reporting. Application Resource Measurement. Summary. IV. PERFORMANCE SOLUTIONS. 9: Performance-Oriented Design. Principles for Performance-Oriented Design. Performance Control Principles. Performance Objectives Principle. Instrumenting Principle. Independent Principles. Centering Principle. Fixing-Point Principle. Locality Principle. Processing Versus Frequency Principle. Synergistic Principles. Shared Resources Principle. Parallel Processing Principle. Spread-the-Load Principle. Using the Principles. Summary. 10: Performance Patterns. Overview. Fast Path. Problem. Solution. Benefits. Consequences. First Things First. Problem. Solution. Benefits. Consequences. Coupling. Problem. Solution. Benefits. Consequences. Batching. Problem. Solution. Benefits. Consequences. Alternate Routes. Problem. Solution. Benefits. Consequences. Flex Time. Problem. Solution. Benefits. Consequences. Slender Cyclic Functions. Problem. Solution. Benefits. Consequences. Summary. 11: Performance Antipatterns. Overview. The "god" Class. Problem. Solution. Excessive Dynamic Allocation. Problem. Solution. Circuitous Treasure Hunt. Problem. Solution. The One-Lane Bridge. Problem. Solution. Traffic Jam. Problem. Solution. Summary. 12: Implementation Solutions. Overview. Performance Tuning. General Performance Solutions. Fast Path Speed-Up. Improving Scalability. Algorithm and Data Structure Choices. Time Versus Space Trade-Offs. Hardware/Software Platform Dependencies. Performance Solutions for Object-Oriented Software. Language-Independent Solutions. C++ Solutions. Java Solutions. Summary. V. APPLICATIONS. 13: Web Applications. Introduction. Performance Issues. SPE Models for Web Applications. Case Study: Nachtfliegen.com. Plan Itinerary Scenario. Software Model. Hardware/Software Environment. Resource Requirements. Software Model Solution. Performance Improvements. System Execution Model. Sensitivity and Scalability Analysis. Typical Performance Problems. Summary. 14: Embedded Real-Time Systems. Introduction. Embedded Real-Time Systems Background. Timing Requirements. Hardware Constraints. Real-Time Operating Systems. Distributed Systems. Database. Performance Issues. Response Time and Throughput. Schedulability. SPE Models for Embedded Real-Time Systems. Case Study: Telephony Switching. Overview. Architecture and Design. Typical Performance Problems. Summary. VI. MAKING SPE HAPPEN. 15: The SPE Process. Introduction. The SPE Process. Assess Performance Risk. Identify Critical Use Cases. Select Key Performance Scenarios. Establish Performance Objectives. Construct Performance Models. Determine Software Resource Requirements. Add Computer Resource Requirements. Evaluate the Models. Verify and Validate Models. Late Life Cycle SPE Activities. More Detailed Models. More Precise Data. Performance Testing. Baseline Models. Post-Deployment Performance Management. Evolutionary Changes. Capacity Management. SPE Artifacts. Performance Management Plans. Performance V&V Plan. SPE Configuration Management Plan. Performance Drivers. Performance Scenarios. Performance Objectives. Execution Environment Specifications. Performance Models. Model Results. Performance Instrumentation. Performance V&V Reports. Performance Test Plans. Performance Test Results. Integrating SPE Into Your Software Process. The Waterfall Model. The Spiral Model. SPE in the Unified Process. Summary. 16: Implementing SPE. Introduction. Tools. Modeling Tools. Development Tools. SPE Adoption and Use. Experience. Key Considerations. Pilot Projects. Critical Success Factors for Adoption and Use. SPE Implementation Strategies. Organizational Issues. Who Pays for SPE? Costs. Risks. Critical Factors for Successful Projects. SPE Future. Summary. VII. APPENDIXES. Appendix A: UML Notation. Use Case Diagrams. Sequence Diagrams. Basic Sequence Diagrams. Augmented Sequence Diagrams. Deployment Diagrams. Stereotypes, Tagged Values, and Constraints. Stereotypes. Tagged Values. Constraints. Appendix B: SPE Modeling Notations. Execution Graph Notation. Basic Nodes. Synchronization Nodes. Information Processing Graph Notation. Bibliography. Index. 0201722291T09102001
TL;DR: This paper investigates dynamic tuning mechanisms on a new time-based software transactional memory implementation and exhibits the benefits of dynamic tuning.
Abstract: The current generation of software transactional memories has the advantage of being simple and efficient. Nevertheless, there are several parameters that affect the performance of a transactional memory, for example the locality of the application and the cache line size of the processor. In this paper, we investigate dynamic tuning mechanisms on a new time-based software transactional memory implementation. We study in extensive measurements the performance of our implementation and exhibit the benefits of dynamic tuning. We compare our results with TL2, which is currently one of the fastest word-based software transactional memories.
TL;DR: Relational Cloud as discussed by the authors is a transactional database-as-a-service (DBaaS) system that uses a graph-based data partitioning algorithm to achieve near-linear elastic scalability.
Abstract: This paper introduces a new transactional “database-as-a-service” (DBaaS) called Relational Cloud. A DBaaS promises to move much of the operational burden of provisioning, configuration, scaling, performance tuning, backup, privacy, and access control from the database users to the service operator, offering lower overall costs to users. Early DBaaS efforts include Amazon RDS and Microsoft SQL Azure, which are promising in terms of establishing the market need for such a service, but which do not address three important challenges: efficient multi-tenancy, elastic scalability, and database privacy. We argue that these three challenges must be overcome before outsourcing database software and management becomes attractive to many users, and cost-effective for service providers. The key technical features of Relational Cloud include: (1) a workload-aware approach to multi-tenancy that identifies the workloads that can be co-located on a database server, achieving higher consolidation and better performance than existing approaches; (2) the use of a graph-based data partitioning algorithm to achieve near-linear elastic scale-out even for complex transactional workloads; and (3) an adjustable security scheme that enables SQL queries to run over encrypted data, including ordering operations, aggregates, and joins. An underlying theme in the design of the components of Relational Cloud is the notion of workload awareness: by monitoring query patterns and data accesses, the system obtains information useful for various optimization and security functions, reducing the configuration effort for users and operators.
TL;DR: Experimental results from a 17-server farm running the industry standard TPC-W e-commerce benchmark show that co-adaptation renders a cut-down in energy consumption by more than 50%, when workload is not high, while maintaining latency within acceptable bounds.
Abstract: The increased complexity of performance-sensitive software systems leads to increased use of automated adaptation policies in lieu of manual performance tuning. Composition of adaptive components into larger adaptive systems, however, presents challenges that arise from potential incompatibilities among the respective adaptation policies. Consequently, unstable or poorly-tuned feedback loops may result that cause performance deterioration. This paper (i) presents a mechanism, called adaptation graph analysis, for identifying potential incompatibilities between composed adaptation policies and (ii) illustrates a general design methodology for co-adaptation that resolves such incompatibilities. Our results are demonstrated by a case study on energy minimization in multi-tier Web server farms subject to soft real-time constraints. Two independently efficient energy saving policies (an on/off policy that switches machines off when not needed and a dynamic voltage scaling policy) are shown to conflict leading to increased energy consumption when combined. Our adaptation graph analysis predicts the problem, and our co-adaptation design methodology finds a solution that improves performance. Experimental results from a 17-server farm running the industry standard TPC-W e-commerce benchmark show that co-adaptation renders a cut-down in energy consumption by more than 50%, when workload is not high, while maintaining latency within acceptable bounds. The paper serves as a proof of concept of the proposed conflict-identification and resolution methodology and an invitation to further investigate a science for composing adaptive systems.