Myisam is preferred without transaction and little update(delete)

Big than 4G datafile can user Myisam merge table.

InnoDB with auto_increment primary key is preferred.

Few storage process

Guess: 20m records max per table , 500G data max per tablespace , 256 tables per database (may problem)

Use prepared statement and  batch

Optimize Your Queries For the Query Cache

// query cache does NOT work

$r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()");

// query cache works!

$today = date("Y-m-d");

$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

EXPLAIN Your SELECT Queries

LIMIT 1 When Getting a Unique Row

Index and Use Same Column Types for Joins

Do Not ORDER BY RAND()

Avoid SELECT *

t is a good habit to always specify which columns you need when you are doing your SELECT’s.

Use ENUM over VARCHAR

Use NOT NULL If You Can

Store IP Addresses as UNSIGNED INT (?)

Fixed-length (Static) Tables are Faster

Vertical Partitioning

Vertical Partitioning is the act of splitting your table structure in a vertical manner for optimization reasons.

Example 1: You might have a users table that contains home addresses, that do not get read often. You can choose to split your table and store the address info on a separate table. This way your main users table will shrink in size. As you know, smaller tables perform faster.

Example 2: You have a “last_login” field in your table. It updates every time a user logs in to the website. But every update on a table causes the query cache for that table to be flushed. You can put that field into another table to keep updates to your users table to a minimum.

But you also need to make sure you don’t constantly need to join these 2 tables after the partitioning or you might actually suffer performance decline.

Split the Big DELETE or INSERT Queries

If you have some kind of maintenance script that needs to delete large numbers of rows, just use the LIMIT clause to do it in smaller batches to avoid this congestion.

Smaller Columns Are Faster

Use an Object Relational Mapper

f you do not need the time component, use DATE instead of DATETIME.

Consider horizontally spitting many-columned tables if they contain a lot of NULLs or rarely used columns.

Be an SQL programmer who thinks in sets, not procedural programming paradigms

InnoDB can’t optimize SELECT COUNT(*) queries. Use counter tables! That’s how to scale InnoDB.

Prefer MM with hive

refer :

http://blog.tuvinh.com/top-20-mysql-best-practices/

PreparedStatements are implemented by the driver, as MySQL does not have a prepared statement feature. Because of this, the driver does not implement getParameterMetaData() or getMetaData() as it would require the driver to have a complete SQL parser in the client.

Starting with version 3.1.0 MySQL Connector/J, server-side prepared statements and binary-encoded result sets are used when the server supports them.

Quick Troubleshooting Tips on Solaris OS and Linux for Java SE 6

This "Quick Start Guide" gives you some quick tips for troubleshooting. The subsections list some typical functions that can help you in troubleshooting, including one or more ways to get the information or perform the action.

These tips are organized as follows:

Hung, Deadlocked, or Looping Process
Post-mortem Diagnostics, Memory Leaks
Monitoring
Actions on a Remote Debug Server
Other Functions

Hung, Deadlocked, or Looping Process

• Print thread stack for all Java threads:
  • Control-"
  • kill -QUIT pid
  • jstack pid (or jstack -F pid if jstack pid does not respond)
• Detect deadlocks:
  • Request deadlock detection: JConsole tool, Threads tab
  • Print information on deadlocked threads: Control-"
  • Print list of concurrent locks owned by each thread: -XX:+PrintConcurrentLocks set, then Control-"
  • Print lock information for a process: jstack -l pid
• Get a heap histogram for a process:
  • Start Java process with -XX:+PrintClassHistogram, then Control-"
  • jmap -histo pid (with -F option if pid does not respond)
• Dump Java heap for a process in binary format to file:
  • jmap -dump:format=b,file=filename pid (with -F option if pid does not respond)
• Print shared object mappings for a process:
  • jmap pid
• Print heap summary for a process:
  • Control-"
  • jmap -heap pid
• Print finalization information for a process:
  • jmap -finalizerinfo pid
• Attach the command-line debugger to a process:
  • jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=pid

Post-mortem Diagnostics, Memory Leaks

• Examine the fatal error log file. Default file name is hs_err_pidpid.log in the working-directory.
• Create a heap dump:
  • Start the application with HPROF enabled: java -agentlib:hprof=file=file,format=b application; then Control-"
  • Start the application with HPROF enabled: java -agentlib:hprof=heap=dump application
  • JConsole tool, MBeans tab
  • Start VM with -XX:+HeapDumpOnOutOfMemoryError; if OutOfMemoryError is thrown, VM generates a heap dump.
• Browse Java heap dump:
  • jhat heap-dump-file
• Dump Java heap from core file in binary format to a file:
  • jmap -dump:format=b,file=filename corefile
• Get a heap histogram for a process:
  • Start Java process with -XX:+PrintClassHistogram, then Control-"
  • jmap -histo pid (with -F option if pid does not respond)
• Get a heap histogram from a core file:
  • jmap -histo corefile
• Print shared object mappings from a core file:
  • jmap corefile
• Print heap summary from a core file:
  • jmap -heap corefile
• Print finalization information from a core file:
  • jmap -finalizerinfo corefile
• Print Java configuration information from a core file:
  • jinfo corefile
• Print thread trace from a core file:
  • jstack corefile
• Print lock information from a core file:
  • jstack -l corefile
• Attach the command-line debugger to a core file on the same machine:
  • jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=path,core=corefile
• Attach the command-line debugger to a core file on a different machine:
  • On the machine with the core file: jsadebugd path corefile
    and on the machine with the debugger: jdb -connect sun.jvm.hotspot.jdi.SADebugServerAttachingConnector:debugServerName=machine
• libumem can be used to debug memory leaks.

Monitoring

Note: The vmID argument for the jstat command is the virtual machine identifier. See the jstat man page for a detailed explanation.

• Print statistics on the class loader:
  • jstat -class vmID
• Print statistics on the compiler:
  • Compiler behavior: jstat -compiler vmID
  • Compilation method statistics: jstat -printcompilation vmID
• Print statistics on garbage collection:
  • Summary of statistics: jstat -gcutil vmID
  • Summary of statistics, with causes: jstat -gccause vmID
  • Behavior of the gc heap: jstat -gc vmID
  • Capacities of all the generations: jstat -gccapacity vmID
  • Behavior of the new generation: jstat -gcnew vmID
  • Capacity of the new generation: jstat -gcnewcapacity vmID
  • Behavior of the old and permanent generations: jstat -gcold vmID
  • Capacity of the old generation: jstat -gcoldcapacity vmID
  • Capacity of the permanent generation: jstat -gcpermcapacity vmID
• Monitor objects awaiting finalization:
  • JConsole tool, VM Summary tab
  • jmap -finalizerinfo pid
  • getObjectPendingFinalizationCount method in java.lang.management.MemoryMXBean class
• Monitor memory:
  • Heap allocation profiles via HPROF: java -agentlib:hprof=heap=sites
  • JConsole tool, Memory tab
  • Control-" prints generation information.
• Monitor CPU usage:
  • By thread stack: java -agentlib:hprof=cpu=samples application
  • By method: java -agentlib:hprof=cpu=times application
  • JConsole tool, Overview and VM Summary tabs
• Monitor thread activity:
  • JConsole tool, Threads tab
• Monitor class activity:
  • JConsole tool, Classes tab

Actions on a Remote Debug Server

First, attach the debug daemon jsadebugd, then execute the command:

• Dump Java heap in binary format to a file: jmap -dump:format=b,file=filename hostID
• Print shared object mappings: jmap hostID
• Print heap summary : jmap -heap hostID
• Print finalization information : jmap -finalizerinfo hostID
• Print lock information : jstack -l hostID
• Print thread trace : jstack hostID
• Print Java configuration information: jinfo hostID

Other Functions

• Interface with the instrumented Java virtual machines:
  • Monitor for the creation and termination of instrumented VMs: jstatd daemon
  • List the instrumented VMs: jps
  • Provide interface between remote monitoring tools and local VMs: jstatd daemon
  • Request garbage collection: JConsole tool, Memory tab
• Print Java configuration information from a running process:
  • jinfo pid
• Dynamically set, unset, or change the value of certain Java VM flags for a process:
  • jinfo -flag flag
• Print command-line flags passed to the VM:
  • jinfo -flags
• Print Java system properties:
  • jinfo -sysprops
• Pass a Java VM flag to the virtual machine:
  • jconsole -Jflag ...
  • jhat -Jflag ...
  • jmap -Jflag ...
• Print statistics of permanent generation of Java heap, by class loader:
  • jmap -permstat
• Report on monitor contention.
  • java -agentlib:hprof=monitor=y application
• Evaluate or execute a script in interactive or batch mode:
  • jrunscript
• Interface dynamically with an MBean, via JConsole tool, MBean tab:
  • Show tree structure.
  • Set an attribute value.
  • Invoke an operation.
  • Subscribe to notification.
• Run interactive command-line debugger:
  • Launch a new VM for the class: jdb class
  • Attach debugger to a running VM: jdb -attach address
  http://www.blogjava.net/justinchen/archive/2009/01/08/248738.html

Caching

• Configurable Query Result, Filter, and Document cache instances
• Pluggable Cache implementations
• Cache warming in background
  • When a new searcher is opened, configurable searches are run against it in order to warm it up to avoid slow first hits. During warming, the current searcher handles live requests.
• Autowarming in background
  • The most recently accessed items in the caches of the current searcher are re-populated in the new searcher, enabing high cache hit rates across index/searcher changes.
• Fast/small filter implementation
• User level caching with autowarming support

CREATE TABLE ProjectPaths(



VertexId INTEGER,



Depth INTEGER,



Path VARCHAR(300) 。







)

public void traverseDepthFirst( AST ast )

{

//  Root AST node cannot be null or

//  traversal of its subtree is impossible.

if ( ast == null )

{

throw new IllegalArgumentException(

"node to traverse cannot be null!" );

}

//  Map to hold parents of each

//  AST node.  Unfortunately the AST

//  interface does not provide a method

//  for finding the parent of a node, so

//  we use the Map to save them.



Map parentNodes = new HashMap();



//  Start tree traversal with first child

//  of the specified root AST node.



AST currentNode = ast.getFirstChild();



//  Remember parent of first child.



parentNodes.put( currentNode , ast );



//  Iterate through nodes, simulating

//  recursive tree traversal, and add them

//  to queue in proper order for later

//  linear traversal.  This "flattens" the

//  into a linear list of nodes which can

//  be visited non-recursively.



while ( currentNode != null )

{

//  Visit the current node.



strategy.visit( currentNode );



//  Move down to current node's first child

//  if it exists.



AST childNode   = currentNode.getFirstChild();



//  If the child is not null, make it

//  the current node.



if ( childNode != null )

{

//  Remember parent of the child.



parentNodes.put( childNode , currentNode );



//  Make child the current node.



currentNode = childNode;



continue;

}



while ( currentNode != null )

{

//  Move to next sibling if any.



AST siblingNode = currentNode.getNextSibling();



if ( siblingNode != null )

{

//  Get current node's parent.

//  This is also the parent of the

//  sibling node.



AST parentNode  = (AST)parentNodes.get( currentNode );



//  Remember parent of sibling.



parentNodes.put( siblingNode , parentNode );



//  Make sibling the current node.



currentNode     = siblingNode;



break;

}

//  Move up to parent if no sibling.

//  If parent is root node, we're done.



currentNode = (AST)parentNodes.get( currentNode );



if ( currentNode.equals( ast ) )

{

currentNode = null;

}

}

}

<jsp-property-group>
  <deferred-syntax-allowed-as-literal>
    true
  </deferred-syntax-allowed-as-literal>


</jsp-property-group>

<%@page  language="java" deferredSyntaxAllowedAsLiteral="true" %>

办法3 ：不用 jsp2.1 el

>   <jsp-config>
>     <jsp-property-group>
>       <url-pattern>*.jsp</url-pattern>
>       <el-ignored>true</el-ignored>
>     </jsp-property-group>
>   </jsp-config>


http://www.mail-archive.com/dev@struts.apache.org/msg28920.html

我现在的疑问
在一个页面中采用两个 el 引擎，是否会对性能造成一定影响？
较小。