Web performance in seven steps: Summary and Conclusions
Posted by Jeroen Borgers at around evening time: January 20th, 2010
Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I'll sum up the topics we've dealt with and draw some conclusions. (more...)
Web performance in seven steps; Step 7: Share the responsibility for the whole chain
Posted by Jeroen Borgers in the late evening: November 18th, 2009
Last time I blogged about performance tuning based on evidence, the tuning cycle and some best practices. This time I'll blog about the last step of the seven steps: sharing the responsibility for the whole system chain.
When an incident happens in production, this usually means stress. A performance problem in production often leads to finger pointing. (more...)
Web performance in seven steps; Step 6: Tune based on evidence
Posted by Jeroen Borgers in the late evening: November 2nd, 2009
Last time I blogged about the relevance of monitoring and diagnostics in production to solve incidents quickly and prevent future problems. This time I'll talk about tuning based on evidence.
If an application turns out to be too slow, tuning can provide a solution. Tuning can take place on multiple levels. Adding hardware can be a cheap solution. However, when you add hardware at a place where the bottleneck is not located, this has little use.
(more...)
Web performance in seven steps; Step 5: Monitor and diagnose
Posted by Jeroen Borgers late at night: August 31st, 2009
Last time I blogged about the importance of continuous performance testing. When you write and run performance tests continuously, just like unit tests, you get early performance insights in new and changed features of your software. This will minimize surprises and be more productive. Now I’ll blog about monitoring and diagnostics.
When a new version of the software is released into the production environment, the question always is: will it actually perform like we saw in testing and acceptance environments? And we keep our fingers crossed.
(more...)
Web performance in seven steps; Step 4: Test continuously
Posted by Jeroen Borgers at around evening time: July 22nd, 2009
Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.
Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.
At a popular web shop I had the following challenge: (more...)
Web performance in seven steps; step 3: test representatively
Posted by Jeroen Borgers at around evening time: June 29th, 2009
Last time I blogged about the importance of benchmarking the architecture and new technology in a Proof of Concept for Performance. This time I’ll deal with the importance of representative performance testing.
Slowness of applications in development environments is often neglected with the rationale that faster hardware in the production environment will solve this problem. However, whether this is really true can only be predicted with a test on a representative environment and in a representative way. In such an environment, there needs to be more representative than just the hardware.
(more...)
Web performance in seven steps; step 2: Execute a proof of concept
Posted by Jeroen Borgers at around evening time: June 15th, 2009
Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more...)
JPA implementation patterns: Field access vs. property access
Posted by Vincent Partington around lunchtime: June 13th, 2009
Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.
The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more...)
Web performance in seven steps; step 1: define performance requirements
Posted by Jeroen Borgers at around evening time: June 10th, 2009
Last week I blogged about how performance problems manifest themselves: frustration, loss of revenue and disruption of development; and how adding hardware is a questionable solution. This week I'll blog about the first step to assure web performance.
It can be a valid choice to run the risk of performance problems in production and deal with them in a re-active manner. However, it is usually wiser to be pro-active and prevent them. This approach brings more certainty, peace of mind and also saves money. It consists of seven steps. Step 1: Define performance requirements.
(more...)
Web performance in seven steps; how performance problems manifest themselves
Posted by Jeroen Borgers at around evening time: June 2nd, 2009
Last week I blogged about the increasing load at web shops and the increasing challenges for developers and operators. The question to be answered was stated as: how can we prevent performance and availability problems; how can we assure that a web site is always quick and available? In this blog I’ll describe some of the forms in which I found performance difficulties to present themselves. (more...)
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)