Some of the disk bottlenecks for application server disks are:
a) Persistent store writes
b) Transaction logging (tlogs)
c) HTTP logging
d) Server logging

The disk I/O on an application server can be optimized using faster disks or RAID, disabling syschronous JMS writes, using JTA direct writes for tlogs, or increasing the HTTP log buffer.

The following steps provide you a roadmap to help tuning your application environment to optimize performance:
a) Understanding your performance objectives;
b) Measuring your performance metrics;
c) Locate your bottlenecks in your system;
d) Minimize the impact of the bottlenecks;
e) Achieve your performance goals.

More details can be found in the weblogic tuning guide. But I think the details about the general performance tuning in the docs in not very good. You can read the weblogic  related topics in it. After all, weblogic is their own. Their guide shall be the authoratative.

Abstract:Customized log solution described below allows you to write your own data and parameters to log files, export results to an Excel spreadsheet and then analyze them using powerful pivot table or other tools.

We use our custom log function to log data, analyze test results and to get average response times or tps for individual groups, time intervals or parameters – how long it took to display home page for Brasil vs India?
Custom logs also help you in a case when you are not able to use LR Analysis tool to analyze test results.

The idea is to write to regular log files only the data you really want/need. In run-time settings we disable logging and use our custom log function to write to log files.
The sequence in LR scrīpt is:

1.get transaction start time: using LR parameter of type Date/Time: strcpy(cur_time, lr_eval_string("{pTime}"));

2.execute the transaction

3.get:
a.transaction status: rc=lr_get_transaction_status(tr_name);
b.response time: tr_duration = lr_get_transaction_duration(tr_name);
c.message you want to log – usually a parameter used in transaction or transaction results: strcpy(msg, lr_eval_string("{parameter}"));

4.call function STATUS with all these parameters that writes to the log file to:
a.save current log settings: msg_class=lr_get_debug_message();
b.enable logging:: lr_set_debug_message(LR_MSG_CLASS_BRIEF_LOG, LR_MSG_ON );
c.get vuser and group information: lr_whoami(&vuser_id, &group, &sc_id);
d.write all your data to the log file: lr_log_message("Status:, %s, %s, %s, %3.3f ...
e.restore original log level: lr_set_debug_message(msg_class, LR_MSG_ON);

5.After the test combine all log files from log folder to one file using Windows command prompt: find “Status:” *.log >> trans_log.csv
6.open the result log file in Excel and use pivot table or other tools to analyze the data

Attached is the complete scrīpt and scenario.

Things to consider:
Always functionally test your site before load testing it. There is no point in load testing a broken site. There are several automated functional testing tools available. Often times you can take your functional test, and re-use it in the load-testing tool to save time.

Second, you want to test the scalability of your application, or architecture. You should test for 10 – 20% over you peak traffic levels. Many times peak traffic is in the form of concurrent users, but can be measured in pages/sec, hits/sec, MB/sec. For web based commerce concurrent users represents a very realistic load. So if you site has peak 500 people you should test at 550 to 600 concurrent users/sessions. Note that for this test you want to turn off functional checks, we are specifically testing to see if the hardware can handle the load.

Lastly, after you have SUCCESSFULLY completed the first two steps you move into load testing with functional checks. This determines if your application scales accurately with load, or if it starts to drop images, or links when heavily loaded. I recommend a stepped or incremental approach here. Try it with just the page layout, and links being functionally verified. Then move to checking the URLs of the links, then add images, and finally entire page checks. This process will allow you to identify what content may be suffering and when.

Where you find the problems and how to rectify them is more challenging, dependants on your system architectur, and comes with experience. Here are some things that I have found true. Web Server and Web Application Server software configuration are the most common culprits, not hardware. You should start your analysis with these two, then proceed to checking their hardware. (I.e. CPU load, memory usage, available hard drive cache, etc..) After those have been exhausted move to your network, check your load balance, routers, and gateway.