J2EE Application Performance Optimization

J2EE application performance optimization

How to extract maximum performance from your J2EE Web applications

 

In today's world of larger-then-ever software applications, users still expect real-time data and software that can process data at blazing speeds. With the advent of broadband access, users have grown accustomed to receiving responses in seconds, irrespective of how much data the server handles. It is becoming increasingly important for Web applications to provide as short response times as possible. The most obvious and simple way to improve a Website's performance is by scaling up hardware. But scaling the hardware does not work in all cases and is definitely not the most cost-effective approach. Other solutions can improve performance, without extra costs for the hardware. This article provides some suggestions that prove helpful when trying to maximize a J2EE Web application's performance.
If you decide to try this article's recommendations, keep in mind this article provides suggestions only. Performance tuning is as much an art as it is a science. Changes that often result in improvement might not make any difference in some cases, or, in rare scenarios, they can result in degradation. For best results with performance tuning, take a holistic approach.

Overview

Figure 1 illustrates at a broad level how a J2EE application appears when deployed in a production environment. To get the best performance from a J2EE application, all the underlying layers must be tuned, including the application itself.


Figure 1. J2EE application architecture. Click on thumbnail to view full-sized image.
For maximum performance, all the components in Figure 1—operating system, Web server, application server, and so on—need to be optimized. This article will give a glimpse into tuning a J2EE application server, Web server, relational database, and your J2EE application. For maximum payoff from this article, follow these guidelines:

• Set a goal: Before you begin tuning your J2EE application's performance, set a goal. Often this goal addresses the maximum concurrent users the application will support for a given limit on response times. But the goal can also focus on other variables—for example, the response times should not increase more than 10 percent during the peak hour of user load.
• Identify problem areas: It is important to identify the bottlenecks when you start making changes to improve performance. A little investigation into problems might reveal the specific component that causes poor performance. For example, if the CPU usage on an application server is high, you will want to focus on tuning the application server first.
• Follow a methodical and focused path: Once the goal is set, try to make changes that are expected to have the biggest impact on performance. Your time is better spent tuning a method that takes 10 seconds but gets called 100 times than tuning a method that takes one minute but gets called only once. In an ideal world, you test one change at a time before using it in a production environment. You make one change and stress-test it. If the change results in positive impact, only then will you make it permanent.

Identify bottlenecks

The goal of performance tuning is to identify bottlenecks and remove them. It is an iterative process. Once one area of the application improves, another area will become a bottleneck. You must repeat the cyclic process of first identifying the bottleneck, then resolving the bottleneck, then identifying the next bottleneck until the desired goal has been reached. You will need two kinds of tools that prove helpful in this process. First, you need stress tools that generate load for your application. Second, you need monitoring tools that collect data for various performance indicators.

Stress tools

Many different stress tools are available in the market today. Some of the popular ones are:

• Mercury Interactive's LoadRunner
• Segue's SilkPerformer
• RadView Software's WebLoad

For a comprehensive list of stress tools see this article's Resources section. You must choose a tool that best fits your needs based on the tool's features and associated price tag. Some of the important features you should consider before choosing a tool are:

• Support for a large number of concurrent Web users, each running through a predefined set of URL requests
• Ability to record test scripts automatically from browser
• Support for cookies, HTTP request parameters, HTTP authentication mechanisms, and HTTP over SSL (Secure Socket Layer)
• Option to simulate requests from multiple client IP addresses
• Flexible reporting module that lets you specify the log level and analyze the results long after the tests were run
• Option to specify the test duration, schedule test for a later time, and specify the total load

For the sample tests mentioned in this article, LoadRunner was used.

Performance monitors

Using a monitoring tool, you collect data for various system performance indicators for all the appropriate nodes in your network topology. Many stress tools also provide monitoring tools. Windows OS also has a built-in performance monitor sufficient for many purposes. This Windows performance monitor can be started from the Administrative Tools menu, accessed from the Control Panel menu, or by typing "perfmon" in the Run window (accessed from the Start menu). You can display the performance counters data in real time, but usually, you'll want to log this data into a file so it can be viewed later. To log the data into a file, go to the Counter Logs selection in the left-hand side of the Performance window, right click with your mouse, and select New Log Settings as shown in Figure 2.


Figure 2. Windows performance monitor. Click on thumbnail to view full-sized image.
You can also set the file path/name for where the data should be logged, as well as a schedule of when to collect this data. It is possible to log the data and view it in real time, but the performance counters must be added twice—first, in the System Monitor link on the left-hand side and second, in Counter Logs, as shown above.
Many performance counters are available in Windows OS. The following table lists some of the important counters that you should always monitor:

System resource Performance monitor Description CPU System: Processor queue length Processor queue length indicates the number of threads in the server's processor queue waiting to be executed by the CPU. As a rule of thumb, if the processor queue remains at a value higher than 2 for an extended period of time, most likely, the CPU is a bottleneck. Processor: Percent of processor time This counter provides the total overall CPU utilization for the server. A value that exceeds 70-80 percent for long periods indicates a CPU bottleneck. System: Percent of total privileged time This counter measures what percentage of the total CPU execution time is used for running in kernel/privileged mode. All the I/O operations run under kernel mode, so a high value (about 20-30 percent) usually indicates problems with the network, disk, or any other I/O interface. RAM Memory: Pages per second Pages per second is the number of pages read from or written to the disk for resolving hard page faults. A value that continuously exceeds 25-30 indicates a memory bottleneck. Memory: Available bytes Available bytes is the amount of physical memory available to processes running on the computer, in bytes. A low value (less than 10 MB) usually means the machine requires more RAM. Hard disk Physical disk: Average disk queue length The average number of requests queued for the selected disk. A sustained value above 2 indicates an I/O bottleneck. Physical disk: Percent of disk time The percentage of elapsed time that the selected disk drive is busy servicing requests. A continuous value above 50 percent indicates a bottleneck with hard disks. Network Network interface: Total bytes per second Shows the bytes transfer rate (sent and received) on the selected network interface. Depending on the network interface bandwidth, this counter can tell if the network is the problem. Network interface: Output queue length Indicates the length of an output packet queue in packets. A sustained value higher than 2 indicates a bottleneck in the network interface.

You should add the above counters (and any others as appropriate) in your counter log and collect this data while you stress-test your application using the stress tool. A file generated by the counter log can be opened later by clicking on the View Log File Data button on the right-hand side toolbar. Looking at these counters should give you some hint as to where the problem exists—application server, Web server, or database server.

After identifying the bottleneck this way, you should try to resolve it. You can use two different strategies—either tune the hosting environment in which your application runs or tune the application itself.

Environment tuning

In this section, we look at the possible tuning options in a typical J2EE Web application hosting environment. As already discussed above, a J2EE application environment usually consists of an application server, Web server, and a backend database.

Web server/application server tuning

Most application servers and Web servers provide similar kinds of configuration options though they have different mechanisms to set them. In this article, I cover Tomcat 4.1.x and Apache 1.3.27, which talk to each other using the JK connector. The configuration options presented here exist in most of the other application servers and Web servers, but you will need to locate the correct place to set them.
Apache
Probably the most important setting for your Windows Apache HTTP Server is the option for number of threads. This value should be high enough to handle the maximum number of concurrent users, but not so high that it starts adding its own overhead of too many context switches. The optimum value can be determined by monitoring the number of threads in use during peak hours. To monitor the threads in use, make sure you have the following configuration directives present in the Apache configuration file (httpd.conf):

LoadModule status_module modules/mod_status.so
<Location /server-status>
    SetHandler server-status
    Allow from all
</Location>

Now, from your browser, make an HTTP request to your Apache server with this URL: http://<apache_machine>/server-status. It displays how many requests are being processed and their status (reading request, writing response, etc.). Monitor this page during peak load on the server to ensure the server is not running out of idle threads. After you come up with the optimum number of threads for your application, change the ThreadsPerChild directive in the configuration file to an appropriate value.
A few other items that improve performance in the Apache HTTP Server are:

• DNS reverse lookups are inefficient. Switch off DNS lookups by setting HostnameLookups in the configuration file to off.
• Do not load unnecessary modules. Apache allows dynamic modules that extend basic functionality of the Apache HTTP Server. Comment out all the LoadModule directives you don't need.
• Try to minimize logging as much as possible. Look for directives LogLevel, CustomLog, and LogFormat in the configuration file for changing logging level.
• Minimize the JK connector's logging also by setting the JkLogLevel directive to emerg.

Tomcat

The two most important configuration options for Tomcat are its heap size and number of threads. Unfortunately there is no good way to determine the heap size needed because in most cases, the JVM doesn't start cleaning up the memory until it reaches the maximum memory allocated. One good rule of thumb is to allocate half of the total physical RAM as Tomcat heap size. If you still run out of memory, look into your application design to reduce memory usage, identify any memory leaks, or try various garbage collector options in the JVM. To change the heap size add -Xms<size> -Xmx<size> as the JVM parameter in the command line that starts Tomcat. <size> is the JVM heap size usually specified in megabytes by appending a suffix m, for example, 512m. Initial heap size is -Xms, and -Xmx is the maximum heap size. For server applications, both should be set to the same value.

The number of threads in Tomcat can be modified by changing the values of minProcessors and maxProcessors attributes for the appropriate connector in <Tomcat>/conf/server.xml. If you are using the JK connector, change the values of its attributes. Again, there is no simple way to decide the optimum value for these attributes. The value should be set such that enough threads are available to handle your Web application's peak load. You can monitor a process's current thread count in the Windows Task Manager, which can assist in determining the correct value of these attributes.
A few other options you should be aware of:

• If you are not using the latest JRE (Java Runtime Environment), consider upgrading to the latest one. I have seen up to a 30 percent performance improvement after upgrading from JRE 1.3.1 to JRE 1.4.1.
• Add the -server option to the JVM options for Tomcat, which should result in better performance for server applications. Note that this option, in some cases, causes the JVM to crash for no apparent reason. If you face this problem, remove the option.
• Change the default Jasper (JavaServer Pages, or JSP, compiler) settings in <Tomcat>/conf/web.xml by setting development="false", reloading="false" and logVerbosityLevel="FATAL".
• Minimize logging in Tomcat by setting debug="0" everywhere in <Tomcat>/conf/server.xml.
• Remove any unnecessary resources from the Tomcat configuration file. Some examples include the Tomcat examples Web application and extra <Connector>, <Listener> elements.
• Set the autodeploy attribute of the <Host> tag to false (unless you need any of the default Tomcat applications like Tomcat Manager).
• Make sure you have set reloadable="false" for all your Web application contexts in <Tomcat>/conf/server.xml.

Database tuning

In the case of Microsoft SQL Server, more often than not, you do not need to modify any configuration options, since it automatically tunes your database to a great degree. You should change these settings only if your stress tests identify the database as a bottleneck. Some of the configuration options that you can try are:

• Run your SQL Server on a dedicated server instead of a shared machine.
• Keep your application database and your temporary database on different hard disks.
• Consider taking local backups and moving them to a different machine. The backups should complete much faster.
• Normalize your database to the third normal form. This is usually the best compromise, as the fourth and fifth forms of normalization can result in performance degradation.
• If you have more than 4 GB of physical RAM available, set the awe enabled configuration option to 1, which will allow SQL Server to use more than 4 GB of memory up to a maximum of 64 GB (depending on the SQL Server edition).
• In case you have many concurrent queries executing and enough memory is available, you can increase the value of the min memory per query option (default is 1,024 KB).
• Change the value of the max worker threads option, which indicates the maximum number of user connections allowed. Once this limit is reached, any new user requests will wait until one of the existing worker threads finishes its current task. The default value for this option is 255.
• Set the priority boost option to 1. This will allow SQL Server to run with a higher priority as compared to the other applications running on the same server. If you are running on a dedicated server, it is usually safe to set this option.

If none of the configuration options resolve the bottleneck, you should consider scaling up the database server. Horizontal scaling is not possible in SQL Server, as it does not support true clustering, so usually, the only option is vertical scaling.

Application tuning

After you have tuned your hosting environment, now it is time to get down and dirty inside your application source code and database schema. In this section, we look at one of the many possible ways to tune your Java code and your SQL queries.

Java code optimization

The most popular way to optimize Java code is by using a profiler. Sun's JVM has built-in support for profiling (Java Virtual Machine Profiler Interface, or JVMPI) that can be switched at execution time by passing the right JVM parameters. Many commercial profilers are available; some rely on JVMPI, others provide their own custom hooks into Java applications (using bytecode instrumentation or some other method). But be aware that all these profilers add significant overhead. Thus, your application cannot be profiled at a realistic load level. Use these profilers with a single user or a limited number of users. It is still a good idea to run your application through the profiler and analyze the results for any obvious bottlenecks.
To identify your application's slowest areas in a full-fledged deployed environment, you can add your own timing logs to the application, which can be switched off easily in the production environment. A logging API, such as log4j or J2SE 1.4's Java Logging API, is handy for this purpose. The code below shows a sample utility class that can help you add timing logs to your application:

import java.util.HashMap;
//Import org.apache.log4j.Logger;
public class LogTimeStamp {
    private static HashMap ht = new HashMap();
    // Preferably we should use log4j instead of System.out
//    private static Logger logger = Logger.getLogger("LogTimeStamp");
    private static class ThreadExecInfo {
        long timestamp;
        int stepno;
    }
    public static void LogMsg(String Msg) {
        LogMsg(Msg, false);
    }
    /*
     * Passing true in the second parameter of this function resets the counter for
     * the current thread. Otherwise it keeps track of the last invocation and prints
     * the current counter value and the time difference between the two invocations.
     */
    public static void LogMsg(String Msg, boolean flag) {
        LogTimeStamp.ThreadExecInfo thr;
        long timestamp = System.currentTimeMillis();
        synchronized (ht) {
            thr = (LogTimeStamp.ThreadExecInfo) ht.get(Thread.currentThread().getName());
            if (thr == null) {
                thr = new LogTimeStamp.ThreadExecInfo();
                ht.put(Thread.currentThread().getName(), thr);
            } 
        }
        if (flag == true) {
            thr.stepno = 0;
        }
        if (thr.stepno != 0) {
//            logger.debug(Thread.currentThread().getName() + ":" + thr.stepno + ":" +
//                    Msg + ":" + (timestamp - thr.timestamp));
            System.out.println(Thread.currentThread().getName() + ":" + thr.stepno + ":" +
                    Msg + ":" + (timestamp - thr.timestamp));
        }
        thr.stepno = thr.stepno + 1;
        thr.timestamp = timestamp;
    }
}

After adding the above class in your application, you must invoke method LogTimeStamp.LogMsg() at various checkpoints in your code. This method prints the time (in milliseconds) it took for one thread to get from one checkpoint to the next one. First, call LogTimeStamp.LogMsg("Your Msg", true) at one place in the code that is the start of a user request. Now you can insert the following invocations in your code:

    public void startingMethod() {
        ...
        LogTimeStamp.LogMsg("This is a test message", true); //This is starting point
        ...
        LogTimeStamp.LogMsg("One more test message"); //This will become check point 1
        method1();
        ...
    }
    public void method1() {
        ...
        LogTimeStamp.LogMsg("Yet another test message"); //This will become check point 2
        method2();
        ...
        LogTimeStamp.LogMsg("Oh no another test message"); //This will become check point 4
    }
    public void method2() {
        ...
        LogTimeStamp.LogMsg("Wow! another test message"); //This will become check point 3
        ...
    }

The Perl script analyze.pl, which can be downloaded from Resources, can take the output of the above log messages as input and print the results in the format below. From these results, you now know which part of the code requires the most time and can concentrate on optimizing that part:

Transactions                           Avg. Time  Max Time  Min Time
--------------------------------------------------------------------
[This is a ...] to [One more t...]         14410     20937      7500
[One more t...] to [Yet anothe...]            16        62         0
[Yet anothe...] to [Wow! anoth...]         39860     50844     27703
[Wow! anoth...] to [Oh no anot...]           711      1844        94
[Oh no anot...] to [OK thats e...]         68089    228452     19718

The above approach represents just one of the ways to tune your Java code. You can use whatever methodology works for you. Some excellent resources are available for Java performance tuning. Check Resources for some links. Some general suggestions you should be aware of while developing a J2EE application are:

• Avoid using synchronized blocks in your code as much as possible. That does not mean you should abdicate handling synchronization for your code's multithreaded parts, but you should try to limit its usage. Synchronized blocks can severely impair your application's scalability.
• Proper logging proves necessary in serious software development. You should try to use a logging mechanism (like log4j) that lets you switch off logging in the production environment to reduce logging overhead.
• Instead of creating and destroying resources every time you need them, use a resource pool for every resource that is costly to create. One obvious choice for this is your JDBC (Java Database Connectivity) Connection objects. Threads are also usually good candidates for pooling. Many free APIs are available for pooling various resources.
• Try to minimize the objects you store in HttpSession. Extra objects in HttpSession not only lead to more memory usage, they also add additional overhead for serialization/deserialization in case of persistent sessions.
• Where ever possible, use RequestDispatcher.forward() instead of HttpServletResponse.sendRedirect(), as the latter involves a trip to the browser.
• Minimize the use of SingleThreadModel in servlets so that the servlet container does not have to create many instances of your servlet.
• Java stream objects perform better than reader/writer objects because they do not have to deal with string conversion to bytes. Use OutputStream in place of PrintWriter.
• Reduce the default session timeout either by changing your servlet container configuration or by calling HttpSession.setMaxInactiveInterval() in your code.
• Just as we switched off the DNS lookup in the Web server configuration, try not to use ServletRequest.getRemoteHost(), which involves a reverse DNS lookup.
• Always add directive <%@ page session="false"%> to JSP pages where you do not need a session.
• Excessive use of custom tags also may result in poor performance. Keep performance in mind while designing your custom tag library.

SQL query optimization

The optimization of SQL queries is a vast subject in itself, and many books cover only this topic. SQL query running times can vary by many orders of magnitude even if they return the same results in all cases. Here I just show how to identify the slow queries and offer a few suggestions as to how to fix some of the most common mistakes.

First of all, to identify slow queries, you can use SQL Profiler, a tool from Microsoft that comes standard with SQL Server 2000. This tool should be run on a machine other than your SQL Server database server and the results should be stored in a different database as well. Storing results in a database allows all kinds of reports to be generated using standard SQL queries. Profiling any application inherently adds a lot of overhead, so try to use appropriate filters that can reduce the total amount of data collected.
To start the profiling, from SQL Profiler's File menu, select New, then Trace, and give the connection information and the appropriate credentials to connect to the database you want to profile. A Trace Properties windows will open, where you should enter a meaningful name you will recognize later. Select Save To Table option and now give the connection information and credentials for the database server (this should differ from the server you are profiling) where you want to store the data collected by the profiler. Next, you should be asked to provide the database and the table name where the results will be stored. Usually, you would also want to add a filter, so go to the Filters tab and add the appropriate filters (for example "duration greater than or equal to 500 milliseconds" or "CPU greater than or equal to 20" as shown in Figure 3). Now click on the Run button and the profiling will start.


Figure 3. SQL Profiler. Click on thumbnail to view full-sized image.
Let's say based on SQL Profile's results, you have identified the following query as the most time consuming:

SELECT [TABLE1].[T1COL1], [TABLE1].[T1COL2], 
       [TABLE1].[T1COL3], [TABLE1].[T1COL4]
FROM ((([TABLE1] LEFT JOIN [TABLE4] ON [TABLE1].[T1COL4] = [TABLE4].[T4COL4]) 
        LEFT JOIN [TABLE3] ON [TABLE1].[T1COL3] = [TABLE3].[T3COL3]) 
        LEFT JOIN [TABLE2] ON [TABLE1].[T1COL2] = [TABLE2].[T2COL2]) 
WHERE [TABLE1].[T1COL5] = 'VALUE1'

Now your task is to optimize this query to improve performance. You look at your database and find that TABLE1 has 700,000 records, TABLE2 has 16, TABLE3 has 100, and TABLE4 happens to have more than 4 million records. You should first understand this query's cost, and Query Analyzer comes in handy for this task. Select Show Execution Plan in the Query menu and execute this query in Query Analyzer. Figure 4 shows the resulting execution plan.


Figure 4. Execution plan before indexes. Click on thumbnail to view full-sized image.
From this plan, you see that SQL Server is clearly doing full-table scans for all four tables, and together, they make up around 80 percent of the total query cost. Luckily, another feature in Query Analyzer can analyze a query and recommend appropriate indexes. Run Index Tuning Wizard from the Query menu again. This wizard analyzes the query and gives recommendations for indexes. As shown in Figure 5, it recommends two indexes to be created ([TABLE4].[T4COL4] & [TABLE1].[T1COL5]) and also indicates performance will improve 99 percent!


Figure 5. Index Tuning Wizard. Click on thumbnail to view full-sized image.
After creating the indexes, the execution time declines from 4,125 milliseconds to 110 milliseconds, and the new execution plan shown in Figure 6 shows only two table scans (not a problem as TABLE2 and TABLE3 both have limited records).


Figure 6. Execution plan after indexes. Click on thumbnail to view full-sized image.
This was just an example of what proper tuning can achieve in terms of performance. In general, SQL Server's auto-tuning features automatically handle many tasks for you. For example, reordering WHERE clauses will never yield any benefit, as SQL Server internally handles that. Still, here are a few things you should keep in mind while writing SQL queries:

• Keep the transactions as short as possible. The longer a transaction is open, the longer it holds the locks on the resources acquired, and every other transaction must wait.
• Do not use DISTINCT clauses unnecessarily. If you know the rows will be unique, do not add DISTINCT in the SELECT clause.
• When possible, avoid using SELECT *. Select only the columns from which you need the data.
• Consider adding indexes to those columns causing full-table scans for your queries. Indexes can result in a big performance gain, as shown above, even though they consume extra disk space.
• Avoid using too many string functions or operators in your queries. Functions like SUBSTRING, LOWER, UPPER, and LIKE result in poor performance.

Summary

In this article, I barely scratched the surface of performance tuning. Just reading this article will not make you an expert on all aspects of performance. But I hope you have gained a better appreciation for the methodology and acquired enough knowledge to be able to start the process. For optimum results, you need to tune every aspect of the application starting with the bottlenecks. Even experienced developers make small mistakes that prove costly in terms of performance. Performance tuning helps to identify these mistakes and makes your product not only more scalable, but also more reliable under stress conditions.

Improve Your Web Page Performance

Ways to Improve Your Web Page Performance

(front-end performance)

There are a million and one ways to boost your website’s performance. The methods vary and some are more involved than others. The three main areas that you can work on are: hardware (your web server), server-side scripting optimization (PHP, Python, Java), and front-end performance (the meat of the web page).
This article primarily focuses on front-end performance since it’s the easiest to work on and provides you the most bang for your buck.

Why focus on front-end performance?

The front-end (i.e. your HTML, CSS, JavaScript, and images) is the most accessible part of your website. If you’re on a shared web hosting plan, you might not have root (or root-like) access to the server and therefore can’t tweak and adjust server settings. And even if you do have the right permissions, web server and database engineering require specialized knowledge to give you any immediate benefits.
It’s also cheap. Most of the front-end optimization discussed can be done at no other cost but your time. Not only is it inexpensive, but it’s the best use of your time because front-end performance is responsible for a very large part of a website’s response time.
With this in mind, here are a few simple ways to improve the speed of your website.

1. Profile your web pages to find the culprits.

It’s helpful to profile your web page to find components that you don’t need or components that can be optimized. Profiling a web page usually involves a tool such as Firebug to determine what components (i.e. images, CSS files, HTML documents, and JavaScript files) are being requested by the user, how long the component takes to load, and how big it is. A general rule of thumb is that you should keep your page components as small as possible (under 25KB is a good target).
Firebug’s Net tab (shown above) can help you hunt down huge files that bog down your website. In the above example, you can see that it gives you a break down of all the components required to render a web page including: what it is, where it is, how big it is, and how long it took to load.
There are many tools on the web to help you profile your web page – check out this guide for a few more tools that you can use.

2. Save images in the right format to reduce their file size.

If you have a lot of images, it’s essential to learn about the optimal format for each image. There are three common web image file formats: JPEG, GIF, and PNG. In general, you should use JPEG for realistic photos with smooth gradients and color tones. You should use GIF or PNG for images that have solid colors (such as charts and logos).
GIF and PNG are similar, but PNG typically produces a lower file size. Read Coding Horror’s weigh-in on using PNG’s over GIF’s.

3. Minify your CSS and JavaScript documents to save a few bytes.

Minification is the process of removing unneeded characters (such as tabs, spaces, source code comments) from the source code to reduce its file size. For example:
This chuck of CSS:

.some-class {
  color: #ffffff;
  line-height: 20px;
  font-size: 9px;
}

can be converted to:

.some-class{color:#fff;line-height:20px;font-size:9px;}

…and it’ll work just fine.
And don’t worry – you won’t have to reformat your code manually. There’s a plethora of free tools available at your disposal for minifying your CSS and JavaScript files. For CSS, you can find a bunch of easy-to-use tools from this CSS optimization tools list. For JavaScript, some popular minification options are JSMIN, YUI Compressor, and JavaScript Code Improver. A good minifying application gives you the ability to reverse the minification for when you’re in development. Alternatively, you can use an in-browser tool like Firebug to see the formatted version of your code.

4. Combine CSS and JavaScript files to reduce HTTP requests

For every component that’s needed to render a web page, an HTTP request is created to the server. So, if you have five CSS files for a web page, you would need at least five separate HTTP GET requests for that particular web page. By combining files, you reduce the HTTP request overhead required to generate a web page.
Check out Niels Leenheer’s article on how you can combine CSS and JS files using PHP (which can be adapted to other languages). SitePoint discusses a similar method of bundling your CSS and JavaScript;they were able to shave off 1.6 seconds in response time, thereby reducing the response time by 76% of the original time.
Otherwise, you can combine your CSS and JavaScript files using good, old copy-and-paste‘ing (works like a charm).

5. Use CSS sprites to reduce HTTP requests

A CSS Sprite is a combination of smaller images into one big image. To display the correct image, you adjust the background-position CSS attribute. Combining multiple images in this way reduces HTTP requests.
For example, on Digg (shown above), you can see individual icons for user interaction. To reduce server requests, Digg combined several icons in one big image and then used CSS to position them appropriately.
You can do this manually, but there’s a web-based tool called CSS Sprite Generator that gives you the option of uploading images to be combined into one CSS sprite, and then outputs the CSS code (the background-position attributes) to render the images.

6. Use server-side compression to reduce file sizes

This can be tricky if you’re on a shared web host that doesn’t already server-side compression, but to fully optimize the serving of page components they should be compressed. Compressing page objects is similar to zipping up a large file that you send through email: You (web server) zip up a large family picture (the page component) and email it to your friend (the browser) – they in turn unpack your ZIP file to see the picture. Popular compression methods are Deflate and gzip.
If you run your own dedicated server or if you have a VPS – you’re in luck – if you don’t have compression enabled, installing an application to handle compression is a cinch. Check out this guide on how to install mod_gzip on Apache.

7. Avoid inline CSS and JavaScript

By default, external CSS and JavaScript files are cached by the user’s browser. When a user navigates away from the landing page, they will already have your stylesheets and JavaScript files, which in turn saves them the need to download styles and scripts again. If you use a lot of CSS and JavaScript in your HTML document, you won’t be taking advantage of the web browser’s caching features.

8. Offload site assets and features

Unloading some of your site assets and features to third-party web services greatly reduces the work of your web server. The principle of offloading site assets and features is that you share the burden of serving page components with another server.
You can use Feedburner to handle your RSS feeds, Flickr to serve your images (be aware of the implications of offloading your images though), and the Google AJAX Libraries API to serve popular JavaScript frameworks/libraries like MooTools, jQuery, and Dojo.
For example, on Six Revisions I use Amazon’s Simple Storage Service (Amazon S3 for short), to handle the images you see on this page, as well as Feedburner to handle RSS feeds. This allows my own server to handle just the serving of HTML, CSS, and CSS image backgrounds. Not only are these solutions cost-effective, but they drastically reduce the response times of web pages.

9. Use Cuzillion to plan out an optimal web page structure

Cuzillion is a web-based application created by Steve Souders (front-end engineer for Google after leaving Yahoo! as Chief of Performance) that helps you experiment with different configurations of a web page’s structure in order to see what the optimal structure is. If you already have a web page design, you can use Cuzillion to simulate your web page’s structure and then tweak it to see if you can improve performance by moving things around.
View InsideRIA’s video interview of Steve Sounders discussing how Cuzillion works and the Help guide to get you started quickly.

10. Monitor web server performance and create benchmarks regularly.

The web server is the brains of the operation – it’s responsible for getting/sending HTTP requests/responses to the right people and serves all of your web page components. If your web server isn’t performing well, you won’t get the maximum benefit of your optimization efforts.
It’s essential that you are constantly checking your web server for performance issues. If you have root-like access and can install stuff on the server, check out ab – an Apache web server benchmarking tool or Httperf from IBM.
If you don’t have access to your web server (or have no clue what I’m talking about) you’ll want to use a remote tool like Fiddler or HTTPWatch to analyze and monitor HTTP traffic. They will both point out places that are troublesome for you to take a look at.
Benchmarking before and after making major changes will also give you some insight on the effects of your changes. If your web server can’t handle the traffic your website generates, it’s time for an upgrade or server migration.

 

BIRT REPORT

Eclipse Birt 

Reporting with Eclipse BIRT and Java Objects (POJO's) - Tutorial 

This tutorial describes how to use Eclipse BIRT for reporting on simple Java Objects (POJO's). The tutorial explains also how to deploy the resulting BIRT report into a webcontainer (Tomcat) and how to use it in an Eclipse RCP application. Eclipse 3.7 (Indigo) is used for this tutorial.

---

1. Eclipse BIRT

1.1. Overview

Eclipse BIRT allows the creation of reports based on data from different data sources. Data sources define where the data is stored.
BIRT provides for example the following data sources:

• Databases (via JDBC)
  
• Text Files (cvs, XML)
  
• WebServices (via WSDL-Files)
  
• Scripting Data sources
  

You use in BIRT "Data sets" to defines queries on data source. These data sets can be used in a report.
In a Java program it is often convenient to use Java objects as a data source for reports. This article will focus on the usage of plain old Java objects (POJO) as data sources for BIRT reports.

1.2. Example

In this tutorial we will build a report which will show us information about the stock market. We get the information from a Java Object. The data will be displayed in a chart and in a table with detailed information. The result should look like this:

2. Installation

Use the Eclipse Update Manager to install "Business Intelligence, Reporting and Charting" -> BIRT Framework.

3. Create Project and REport

Create a new Java Project with the name "com.birt.stocks".
Create a new report "stock_report.rptdesign" via File -> New -> Other -> Business Intelligence and Reporting -> Report.

The new report is displayed in the "Report Design" perspective. Delete everything in the example report except the report header. The result should look like the following.

4. Java classes

The report will display stock data. To demonstrate BIRT we use a Mock object for providing the data.
Create package "com.birt.stocks.model" and then the following class. This class will represent the domain model.

package com.birt.stocks.model;

import java.util.Date;

/**
 * Domain model for stock data
 */

public class StockData {
 private Date date;
 private double open;
 private double high;
 private double low;
 private double close;
 private long volume;

 public double getClose() {
  return close;
 }

 public void setClose(double close) {
  this.close = close;
 }

 public Date getDate() {
  return date;
 }

 public void setDate(Date date) {
  this.date = date;
 }

 public double getHigh() {
  return high;
 }

 public void setHigh(double high) {
  this.high = high;
 }

 public double getLow() {
  return low;
 }

 public void setLow(double low) {
  this.low = low;
 }

 public double getOpen() {
  return open;
 }

 public void setOpen(double open) {
  this.open = open;
 }

 public long getVolume() {
  return volume;
 }

 public void setVolume(long volume) {
  this.volume = volume;
 }

} 

Create the package "com.birt.stocks.daomock" and then the following class "StockDaoMock". This will only mock / fake the data and not really get it from the Internet. As we want to learn BIRT here this should be fine.

package com.birt.stocks.daomock;

import java.util.ArrayList;
import java.util.Calendar;
import java.util.List;

import com.birt.stocks.model.StockData;

public class StockDaoMock {

 public List<StockData> getStockValues(String company) {
  // Ignore the company and always return the data
  // A real implementation would of course use the company string
  List<StockData> history = new ArrayList<StockData>();
  // We fake the values, we will return fake value for 01.01.2009 -
  // 31.01.2009
  double begin = 2.5;
  for (int i = 1; i <= 31; i++) {
   Calendar day = Calendar.getInstance();
   day.set(Calendar.HOUR, 0);
   day.set(Calendar.MINUTE, 0);
   day.set(Calendar.SECOND, 0);
   day.set(Calendar.MILLISECOND, 0);
   day.set(Calendar.YEAR, 2009);
   day.set(Calendar.MONTH, 0);
   day.set(Calendar.DAY_OF_MONTH, i);
   StockData data = new StockData();
   data.setOpen(begin);
   double close = Math.round(begin + Math.random() * begin * 0.1);
   data.setClose(close);
   data.setLow(Math.round(Math.min(begin, begin - Math.random() * begin * 0.1)));
   data.setHigh(Math.round(Math.max(begin, close) + Math.random() * 2));
   data.setVolume(1000 + (int) (Math.random() * 500));
   begin = close;
   data.setDate(day.getTime());
   history.add(data);
  }
  return history;
 }
} 

5. Datasource and Dataset

To use Java Objects (POJO's) as datasource in Eclipse BIRT you have to map the fields of your Java classes to JavaScript. This JavaScript is used in your report and will access the Java Object.

5.1. Create Data Source

The data source connects your data with your report. BIRT provides different types of data sources, we use the "Scripted Data Source". Go back to your stocks_report, use the "Report Design" perspective and select the "Data Explorer" View.

Tip

You have to select your report to display the content of the datasource view.

Create a new datasource, named "srcStocks" in your report.

5.2. The Dataset

The dataset defines the mapping for the datasource data and the BIRT data. Create a new dataset named "dataSetSocks".

Press next and define the columns for your report.

5.3. JavaScript

Now we have to write the JavaScript for our dataset. Select the dataset and choose "open" as script. The open script is called before the first access to the dataset. We use this to load our List with the stock objects. To access a Java class you only have to use the following syntax: Packages.myJavaClass where myJavaClass is the full qualified Java class name.

Tip

In case you do not see the script please node that the editor for the report has several tab. One of it is labeled "source".

count = 0;

// Create instance of
// the GetStockHistory class
gsh = new Packages.com.birt.stocks.daomock.StockDaoMock(); 

//Load the List

stock = gsh.getStockValues("Java"); 

Place the following coding in the fetch script.

if(count < stock.size()){
       row["columnDate"] = stock.get(count).getDate();
       row["columnOpen"] = stock.get(count).getOpen();
       row["columnHigh"] = stock.get(count).getHigh();
       row["columnLow"] = stock.get(count).getLow();
       row["columnClose"] = stock.get(count).getClose();
       row["columnVolume"] = stock.get(count).getVolume();
       count++;
       return true;
}

return false; 

Check if your Script works by doubleclicking on the dataset -> Preview Result.

6. Display the data in a table

6.1. Overview

We will now display the data in a table.

6.2. Create a table

Switch from "Data Explorer" to the "Palette". Select the tab "Layout".

Drag and drop the table element on the report.

Define the following settings for the table.

Change back to the "Data Explorer". And drag and drop the dataset columns into the "Details row" of the table.

The result should look like the following.

Done. You can see a preview of the report if you click on the "Review" Tab. The result should look like the following:

7. Chart

7.1. Create a Chart

Switch back to the Palette, select a chart and drag and drop it on your report.
Choose the Line Chart with the standard settings.

Press Next and select your data set.

At the next step we have to assign the columns to the axis. We assign the date to the x axis and the open value to the y axis via drag and drop.

Define 5 series in total. Assign the columns to these series by dragging the column to the Sum sign.

Currently the x axis shows first the newest date. Reverse the x axis by you have to sort the data ascending. Press the highlighted button.

Go to the next tab and give titles to your columns. Hide the last one.

The display of the dates use a long format, we would like to change this. Perform the following and choose "short" as date type of the x axis

Change the display of the lines via the following.

Press finish to include your chart into your report.

8. Deploying in Tomcat

8.1. Overview

The following explains how to use BIRT reports in Tomcat. In general you have to:

• Install the BIRT webviewer in Tomcat
  
• Export your BIRT project into a .jar file
  
• Move the .jar file to the birt-install-directory/WEB-INF/lib directory
  
• Move the report design file into the root directory of birt in tomcat
  
• Restart Tomcat
  

8.2. Install BIRT in Tomcat

We will use a standalone Tomcat 6.0 which we assume is already installed. See Apache Tomcat Tutorial for details.
You need the "Deployment components of BIRT" http://download.eclipse.org/birt/downloads/.
Copy the birt.war of this download into the Tomcat webappsfolder.

Tip

Currently you have to install org.eclipse.commons.logging separately into Tomcat. Download this lib from http://commons.apache.org/logging/ and put the jars into the lib folder of Tomcat.

The Birt example should be available under http://localhost:8080/birt/.If you see something like this, your Tomcat an your Web Viewer should work correct.

8.3. Install your BIRT reports in Tomcat

To run your own reports you have to copy the .rptdesign file in the root of the birt folder in Tomcat. To make your Java classes available export your project into a jar file.

After that the jar file has to be copied to the Tomcat webapps/birt/WEB-INF/lib/ directory. Restart the Tomcat and navigate to your report.
Your report should be found under http://localhost:8080/birt/frameset?__report=stock_report.rptdesign

Tip

If you want to export your report to PDF you also need the library iText from ( http://prdownloads.sourceforge.net/itext/itext-1.3.jar) . Copy the iText.jar in "/birt-viewer/WEB-INF/platform/plugins/com.lowagie.itext/lib". Now restart the Tomcat.

9. Deploying in Eclipse RCP application

9.1. BIRT deploying to an RCP Application

We can use the Birtviewer also in a local RCP Application, it isn't more than an browser view which shows a HTML Page generated by an integrated Webserver.
The following assumes that you are already familiar with Eclipse RCP development. See Eclipse RCP Tutorial in case you need an introduction.
Convert "com.birt.stocks" to a plug-in project, via right mouse click -> Configure -> "Convert to plug-in project".
Create an new plug-in project "com.birt.stocks.rcp". Select the template "RCP Application with a view".
Add the following plugins as dependendies to "com.birt.stocks.rcp".

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Rcp
Bundle-SymbolicName: com.birt.stocks.rcp; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.birt.stocks.rcp.Activator
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 org.eclipse.birt.report.viewer,
 org.eclipse.birt.report.engine.emitter.html,
 com.birt.stocks,
 org.eclipse.birt,
 org.eclipse.birt.chart.ui,
 org.eclipse.birt.chart.device.extension,
 org.eclipse.birt.chart.device.pdf,
 org.eclipse.birt.chart.device.svg,
 org.eclipse.birt.chart.device.swt,
 org.eclipse.birt.chart.engine.extension,
 org.eclipse.birt.chart.reportitem,
 org.eclipse.birt.chart.reportitem.ui,
 org.eclipse.birt.chart.ui.extension,
 org.eclipse.birt.core.script.function,
 org.eclipse.birt.report.engine.script.javascript
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6 

Copy your report to "stock_report_rcp.rptdesign" into this new project. Open this report and change the "open" JavaScript to the following.

count = 0; 
/*
 * load and init data reader
 * import Platform from org.eclipse.core.runtime
 */
importPackage(Packages.org.eclipse.core.runtime);

/* load bundle with POJOs and data loading class */

myBundle = Platform.getBundle("com.birt.stocks");

/* load data reader class */
readerClass = myBundle.loadClass("com.birt.stocks.daomock.StockDaoMock");

/* create new instance of DataReader */
readerInstance = readerClass.newInstance();


/* read data */
stock = readerInstance.getStockValues("Java"); 

Use this code as View.java.

package com.birt.stocks.rcp;

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URL;

import org.eclipse.birt.report.viewer.utilities.WebViewer;
import org.eclipse.core.runtime.FileLocator;
import org.eclipse.core.runtime.Path;
import org.eclipse.core.runtime.Platform;
import org.eclipse.swt.SWT;
import org.eclipse.swt.browser.Browser;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.ui.part.ViewPart;
import org.osgi.framework.Bundle;

public class View extends ViewPart {
 public static final String ID = "com.birt.stocks.rcp.view";

 public void createPartControl(Composite parent) {
  String path = "";
  try {
   Bundle bundle = Platform.getBundle("com.birt.stocks.rcp");
   URL url = FileLocator.find(bundle, new Path("stock_report_rcp.rptdesign"), null);
   path = FileLocator.toFileURL(url).getPath();
  } catch (MalformedURLException me) {
   System.out.println("Fehler bei URL " + me.getStackTrace());
  } catch (IOException e) {
   e.printStackTrace();
  }

  Browser browser = new Browser(parent, SWT.NONE);
  // Use the filename of your report
  WebViewer.display(path, WebViewer.HTML, browser, "frameset");
 }

 /**
  * Passing the focus request to the viewer's control.
  */
 public void setFocus() {
 }
} 

jqGRID

http://www.scribd.com/doc/50888257/Tutorial-jqGrid 

Table of Contents

jqGrid ......................................................................................................................................... 4

How it Works .......................................................................................................................... 23

Tutorial: Creating Your First Grid .................................................................................................. 25

The Data................................................................................................................................ 25

The HTML .............................................................................................................................. 25

The Server-side File ................................................................................................................ 28

PHP and MySQL ...................................................................................................................... 29

COOP Example ....................................................................................................................... 31

Retrieving Data .......................................................................................................................... 33

XML Data ............................................................................................................................... 33

JSON Data ............................................................................................................................. 38

Array Data ............................................................................................................................. 43

Function ................................................................................................................................ 45

User Data .............................................................................................................................. 46

Basic Grids ................................................................................................................................ 48

Properties .............................................................................................................................. 49

Importing/Exporting Grid Configuration ..................................................................................... 56

Events ................................................................................................................................... 58

Methods................................................................................................................................. 59

Integrations ........................................................................................................................... 65

Navigating ................................................................................................................................. 67

Properties, Events and Methods ................................................................................................ 68

Custom Buttons ...................................................................................................................... 69

Searching .................................................................................................................................. 71

Searching on a Single Field ...................................................................................................... 71

Searching on Many Fields ......................................................................................................... 73

Editing ...................................................................................................................................... 76

Cell Editing............................................................................................................................. 76

Inline Editing .......................................................................................................................... 78

Methods................................................................................................................................. 81

Form Editing........................................................................................................................... 84

Advanced Grids .......................................................................................................................... 92

Multiselect Grids ..................................................................................................................... 92

Subgrids ................................................................................................................................ 94

Master/Detail Grids ............................................................................................................... 100

Treegrids ............................................................................................................................. 102

 

3 -User Modules ........................................................................................................................... 113

Posting Data......................................................................................................................... 113

Formatter ............................................................................................................................ 114

Show/Hide Columns .............................................................................................................. 117

Table to jqGrid ..................................................................................................................... 118

Case Applications ..................................................................................................................... 119

Images in Grids .................................................................................................................... 119

Dynamic Editing Forms .......................................................................................................... 120

Search Forms ....................................................................................................................... 123

Trouble-Shooting ..................................................................................................................... 127

==================================================================

How it Works

Understanding this will help you to work better with jqGrid and use the full capabilities of the plugin.The first thing we must understand is that we have two major divisions:

$

Server-side manipulation, and

$

Client-side representation.In other words, jqGrid is a component that helps you, in an easy way, to represent database informationon the client side using a server-side technology. Moreover it helps you to manipulate that data back intothe database.What is server-side manipulation (SSM)? There are many definitions possible, but I try to explain it interms of jqGrid.

Basically SSM means the server handles the editing and not the user's browser. SSM isn’t something that

is visible within a web page. Everything is done on the server side using any common programming

language. Basically it’s a server

-side command that tells the server to place a file or text within the pageonce it is called from a user.In terms of jqGrid this means that you should care about this: you must have a piece of code that dealswith information stored in the database using some scripting language and web server. Using this codeyou should be able to return requested information back to the client (web browser). jqGrid uses Ajaxcalls to retrieve the requested information and represent it to client using Java Script language.Having the needed (requested) information, jqGrid constructs the representation (tabular data)described by you in what is called the Column Model(colModel). The constructed tabular data at the client side has:

$

Caption layer

$

Header layer

$

Body layer

$

Navigation layer

enoughtheory

enoughtheory