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...)
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
Posted by Jeroen Borgers at around evening time: May 25th, 2009
By Jeroen Borgers
More and more Internet users buy in web shops these days. Research shows that the part of European Internet users that buys on-line has grown from 40% in 2004 to 80% in 2008. Additionally, large web retailers in The Netherlands see their revenue grow just as if the recession has never materialized. Business seems to be flourishing. (more...)
Loitering objects make web company lose money
Posted by Jeroen Borgers in the early afternoon: September 15th, 2008
By Jeroen Borgers
Recently, I was called in by a company with a website in trouble. And because they make all their money on-line, it was evident that they really wanted to have the issue solved. The day I came in, the site had gone down about 5 times the last 24 hours. Because of this they got less traffic, which directly meant less revenue. The log files showed periods of long response times and OutOfMemoryErrors. Their questions were: Why do we get this behavior? and How do we fix it? My short answer turned out to be: because of too many loitering objects; and this can be fixed by not holding on to them in the HTTP session. (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)