Showing posts from 2010

Memory Tuning - How OS Page Sizes Can Impact Oracle Performance

Theory Modern operating systems provide each process it's own virtual address space that is potentially larger than physical memory. It does this by mapping the virtual addresses onto actual physical memory pages. The following diagram shows how large virtual address spaces are mapped onto small physical memory.  The virtual to physical relationship is maintained in mapping tables. Linux maintains a separate map for each process. The map contains one entry for each page where the size of the page is set by the operating system.  The CPU attempts to speed up the mapping of virtual memory to physical addresses by caching a subset of the mapping entries in its internal cache.  Modern large memory systems and the resulting large processes have increased the size of memory mapping tables faster than the cpu cache sizes have increased. The processor cache is usually very small with only maybe 100 entries in may processors. This mismatch causes faults that can have significan

Improving Software Quality with Continuous Instrumentation

Better Software is No Accident   The most reliable way to build better software is to integrate quality into process with as much automation as possible.  Automated measurements and metrics provide continuous public visibility to the current state and trends. It is easiest to apply these techniques to new projects but they can also be applied to existing processes in an incremental fashion: Balance the value with the ease of automation. You may sometimes pick less than ideal metrics if they are easier to add Success breeds success.  Do simple stuff first and get points on the board Incrementally improve and change.  Add changes at the rate the team can absorb, often at a slightly faster rate than they would like to go. This presentation covers what we were able to implement in about 15 months.  We didn't take on design concepts like cohesion, fan-in, fan-out and file tangles until the second year. It focuses more on actual software production than on the requirements, desig

Eclipse in the Enterprise

Eclipse in a Large Company's IT Shop Many say that the optimal development team is 5-7 people but that isn't how larger Enterprise software projects work. Those projects have dozens or even hundreds of developers using multiple technologies and Languages. Eclipse's plug-in architecture makes Eclipse more than an IDE. It is a developer desktop environment that many enterprises cannot take full advantage of because of they don't standardize their configurations and toolsets and because they require human intervention for setup. Supersize Me Complex problem that often seems simple to the outsider or new team member No one person knows the whole business problem No one person knows the whole technical implementation No one understands how each technical layer works A lot more effort is put into staffing the initial build than the ongoing maintenance Some work will be defensive in nature protecting from future mistakes All applications ar

Enhancing Scalability with Distributed Object Caching

Teams take various approaches when scaling applications usually doing things like increasing the number of tiers in the application(s) and adding more hardware to each tier. Both of these approaches tend to create operational issues as the system size increases. Some systems have large amounts of user data that can create their own problems when trying to provide fault tolerance and when the number of users combined with the user data is to large to fit in server memory. Persisting data to a relational store often has two much overhead in these situations. Teams can scale up their applications and provide additional stability through the use of commercially available distributed object caches. (Originally 7/2010)

Lightweight Monitors for Metrics and Troubleshooting

Lightweight Monitoring tools can be integrated into applications to provide quantitative information about how an application is being used and how it is performing. Development teams can integrate lightweight monitoring that augments , or in some cases replaces, the server level monitoring provided by system or operations tools. Internal monitoring can provide stick counts and performance information at the method level or on a business transaction basis. Monitors can easily be enhanced to that lets teams track traffic or performance across time, release and program instance. (7/2010)

Coding Standards are Part of Continuous Improvement

Coding standards extend to something beyond just code formatters. Coding Standards give team members the same understanding of what's expected of them.  Developers spend less time trying to understand code when it's style and operating model look similar across modules and applications. Standards must take into account the range of developer skill set allowing for ongoing improvement from training. It may be that you allow or disallow some feature/approach to reduce the number of defects even if some developers are capable of doing "more". Developers like to be free to develop "in their own fashion" but management wants code to have the same shape and look from developer to developer because they care about developer portability across development efforts. Standards can be created that still let developers be creative on the interesting problems. Automated Standards Support Tooling can help enforce coding standards by providing constant reminders that the