Posts Tagged ‘Cache’

Improving web site performance with Apache .htaccess

May 23rd, 2011

Web performance is getting more and more attention from web developers and is one of the hottest topic in web development.

Fred Wilson considered it at 10 Golden Principles of Successful Web Apps as the #1 principle for successful web apps.

First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it.

Faster website means more revenue and traffic
  • Amazon: 100 ms of extra load time caused a 1% drop in sales (source: Greg Linden, Amazon).
  • Google: 500 ms of extra load time caused 20% fewer searches (source: Marrissa Mayer, Google).
  • Yahoo!: 400 ms of extra load time caused a 5–9% increase in the number of people who clicked “back” before the page even loaded (source: Nicole Sullivan, Yahoo!).

Google experiments reached similar results:

Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment). That’s 0.2% to 0.6% fewer searches for changes under half a second!

And speed is now a factor contributing to Google Page Rank:

Google, in their ongoing effort to make the Web faster, blogged last month that “we’ve decided to take site speed into account in our search rankings.” This is yet another way in which improving web performance will have a positive impact on the bottom line.

The good news is that some of the most important speed optimizations can be easily done with simple .htaccess rules.
These rules can make any website faster by compressing content and enabling browser cache. They also follow the Best Practices for Speeding Up Your Web Site from Yahoo!’s Exceptional Performance team.

» Read more: Improving web site performance with Apache .htaccess

JBoss PojoCache configuration

March 17th, 2009

Everyone knows that documentation is not one of JBoss strengths.
This article is meant to fill this gap. It describes and exemplifies how to configure JBoss PojoCache as a MBean service, using loadtime transformations with JBossAop framework, so you don’t need precompiled instrumentation.

Introduction

This section gives you an introduction about PojoCache and its advantages over TreeCache (a plain cache system).

PojoCache is an in-memomy, transactional, and replicated POJO (plain old Java object) cache system that allows users to operate on a POJO transparently without active user management of either replication or persistency aspects. PojoCache, a component of JBossCache (uses PojoCache class as an internal implementation, the old implementation TreeCacheAop has been deprecated.), is the first in the market to provide a POJO cache functionality. JBossCache by itself is a 100% Java based library that can be run either as a standalone program or inside an application server.

TreeCache limitations:

  • Users will have to manage the cache specifically; e.g., when an object is updated, a user will need a corresponding API call to update the cache content.
  • If the object size is huge, even a single field update would trigger the whole object serialization. Thus, it can be unnecessarily expensive.
  • The object structure can not have a graph relationship. That is, the object can not have sub-objects that are shared (multiple referenced) or referenced to itself (cyclic). Otherwise, the relationship will be broken upon serialization.

PojoCache advantages:

  • No need to implement Serializable interface for the POJOs.
  • Replication (or even persistency) is done on a per-field basis (as opposed to the whole object binary level).
  • The object relationship and identity are preserved automatically in a distributed, replicated environment. It enables transparent usage behavior and increases software performance.

» Read more: JBoss PojoCache configuration

Speed up your site by compressing and caching your content with .htaccess

January 6th, 2009

Please read Improving web site performance with Apache .htaccess for an updated version of this article.

.htaccess – gzip and cache your site for faster loading and bandwidth saving is one of the most popular posts on samaxes.
It’s basically on how to compress and cache your site content with Apache and .htaccess file.

It works like a charm, but it’s not yet the perfect configuration for me.
I wanted something that I can use out-of-the-box without having to rely on external extension modules or tools.

If you are lucky enough to have Apache 2 with your hosting provider you can use the mod_deflate module that comes bundled with it.

In order to compress your text files with this Apache’s module you just have to add the following lines to your .htaccess file:

<ifModule mod_deflate.c>
  <filesMatch "\.(css|js|x?html?|php)$">
    SetOutputFilter DEFLATE
  </filesMatch>
</ifModule>

This will gzip all your .css, .js, .html, .html, .xhtml, and .php files.
» Read more: Speed up your site by compressing and caching your content with .htaccess

.htaccess – gzip and cache your site for faster loading and bandwidth saving

April 20th, 2008

Please read Improving web site performance with Apache .htaccess for an updated version of this article.

Last week I changed my hosting provider from Site5 to NearlyFreeSpeech.NET.
Despite the fact that the first one is faster than the second, NFSN is a lot more cheaper (I only pay for what I really use).

So in order to speed up my site and save bandwidth (the more I use the more I pay) I use .htaccess file to gzip my text based files and optimize cache HTTP headers.
Although this site is powered by WordPress which has some really great plugins to optimize PHP output I wanted a more generic solution which can be applied to all PHP web applications.

I also try to follow as much as I can the rules for high performance web sites so don’t be surprised if some Expires header seems too long (far future Expires header rule requires at least 172801 seconds).
» Read more: .htaccess – gzip and cache your site for faster loading and bandwidth saving

J2EE cache filter

January 2nd, 2008

In my current web project I was having some performance issues, I needed a tool that allowed me to do some testing so I can see what’s wrong and what I can do better so my application perform faster.

My search lead me to High Performance Web Sites and YSlow, a very good talk by Steve Souders the Chief Performance Yahoo! at Yahoo!

YSlow is an easy-for-use plugin that allows you to inspect any web page just clicking a button.

YSlow analyzes web pages and tells you why they’re slow based on the rules for high performance web sites. YSlow is a Firefox add-on integrated with the popular Firebug web development tool. YSlow gives you:

  • Performance report card
  • HTTP/HTML summary
  • List of components in the page
  • Tools including JSLint

A good way to reduce the number of Http Connections required to load a web page is to store images and other resources in the browser cache.

Expires is a HTTP header that allows you to define when a resource (image, css, javascript, …) will need to be reloaded. It is a String representation of a Date in the format EEE, dd MMM yyyy HH:mm:ss z.
Cache-Control response headers give Web publishers more control over their content and address the limitations of Expires.

To correctly produce these headers I implemented a Java cache filter.
Using the cache filter is very simple. Grab it here and configure your web.xml, here’s an example:

<filter>
    <filter-name>imagesCache</filter-name>
    <filter-class>com.samaxes.filter.CacheFilter</filter-class>
    <init-param>
        <param-name>privacy</param-name>
        <param-value>public</param-value>
    </init-param>
    <init-param>
        <param-name>expirationTime</param-name>
        <param-value>2592000</param-value><!-- 30 days -->
    </init-param>
</filter>

<filter>
    <filter-name>cssCache</filter-name>
    <filter-class>com.samaxes.filter.CacheFilter</filter-class>
    <init-param>
        <param-name>privacy</param-name>
        <param-value>public</param-value>
    </init-param>
    <init-param>
        <param-name>expirationTime</param-name>
        <param-value>604800</param-value><!-- 7 days -->
    </init-param>
</filter>

<filter>
    <filter-name>javascriptCache</filter-name>
    <filter-class>com.samaxes.filter.CacheFilter</filter-class>
    <init-param>
        <param-name>privacy</param-name>
        <param-value>private</param-value>
    </init-param>
    <init-param>
        <param-name>expirationTime</param-name>
        <param-value>172801</param-value><!-- 48 hours + 1 second -->
    </init-param>
</filter>

<filter-mapping>
    <filter-name>imagesCache</filter-name>
    <url-pattern>*.png</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>imagesCache</filter-name>
    <url-pattern>*.jpg</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>imagesCache</filter-name>
    <url-pattern>*.gif</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>cssCache</filter-name>
    <url-pattern>*.css</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>javascriptCache</filter-name>
    <url-pattern>*.js</url-pattern>
</filter-mapping>

Note: YSlow far future Expires header magical number is 172801 seconds (48 hours + 1 second).