When it comes to secure sites, it’s not easy to achieve a fast loading page. There are a few points that really help: Connections over HTTPS are more expensive compared to an uncompressed connection. So especially try to reduce the number of required connections. And assure keep-alive is active – even a very short time helps (it is used with HTTP1.1 automatically – usually. Test it to be sure). Connections over HTTPS are encrypted per user.
Long and complex article about performance tuning in Java on a method level: http://etutorials.org/Programming/Java+performance+tuning/ Update 2017: Be sure to check the validity.
Sometimes you’re working on a machine and miss a certain tool. In my case, it was iostat I missed on a Red Hat server. iostat is a useful tool for a quick look at the I/O statistics of a unix/linux based machine. Looking for a convenient way to install iostat, my first idea was to yum install iostat, but that didn’t work. With a bit of googling I found that yum install sysstat does the job, as that also installs iostat.
If you’re motivated (or desperate) enough to dive into the mysteries of the JVM, this (somewhat old) list up to 1.6 will be helpful: Original, not available anymore: http://blogs.sun.com/watt/resource/jvm-options-list.html Link from archive.org Also, a good link list is available at the end of that page.
Most of the content of web pages can be grouped in two types: Static and dynamic content. These content types have different requirements on the server software. Content Static content Dynamic content HTML & co .. is prepared for delivery. .. must be created, sometimes with the use of additional software. HTML & co .. is identical for each request. .. is potentially changing with each request.
A well understood pattern of increasing frontend performance of a web application is to deliver static ressources from a different domain. Preferably free of any cookies to save additional bandwidth, the browser can download more of these files in parallel. (This mechanism is often refered to as “cookieless domain”.) Sometimes the adjustments in the application required to achieve this are complicated and have a deep impact on the codebase.
Unnecessary whitespace comes from many sources: It’s added from developers to have a readable code (required!), it’s added from frameworks (oh well), it’s added from auto-formatting and saving rules of your ide (and 4 tabs may end as 32 spaces), and maybe it’s added from other tools in your development chain. In the development cycle whitespace is important, but when the page is delivered it’s unnecessary. So let’s get rid of it with mod_substitute.
The servers are overloaded, and everything grinds down to a sluggish horror. What now? If you’re able to pinpoint performance problems down to a single or a few request types, you can try to manipulate the percentual share of these requests in the overall requests. The goal is to reduce the amount of requests to the trouble makers. This can be achieved by adding a sleep command into the requests responsible for the slow down.
Output of web applications usually is sent in chunks of data, simply because it’s more effective to send a bulk of data then dribble single bytes through the line. But in some situations, it can be very effective to influence the behaviour of this mechanism. If you have a page that is expensive to create but not cacheable as a flat file (like search results), it may be a good solution to manually flush the HTTP-output to the user once the head-section of the page is created.
If your web application suffers from severe slowdowns, these 5 steps will help you to understand the areas of improvement that can have a drastically effect. This is especially true with older applications that didn’t get “web performance” built in by design. Define what you’re actually talking about. There are plenty versions of “slow” available (loading? rendering? usage? whatever?). Point at the slow spots. Find some parameters that describe your problem and measure them.