常见优化问题

1)数据唯一性差的字段不要使用索引
比如性别，只有两种可能数据。意味着索引的二叉树级别少，多是平级。这样的二叉树查找无异于全表扫描。
2) 频繁更新的字段不要使用索引
比如logincount登录次数，频繁变化导致索引也频繁变化，增大数据库工作量，降低效率。
3) 字段不在where语句出现时不要添加索引
只有在where语句出现，mysql才会去使用索引
4) 数据量少的表不要使用索引
使用了改善也不大
另外。如果mysql估计使用全表扫描要比使用索引快，则不会使用索引。

 

 

 

 

 

 

Mysql 缓存

https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&rsv_idx=1&tn=baidu&wd=mysql%20%E6%9F%A5%E8%AF%A2%20%E8%87%AA%E5%8A%A8%E7%BC%93%E5%AD%98&oq=thinkphp&rsv_pq=94144201000199f6&rsv_t=9a7eEUdSXVNampxnCiHQKCMQ6MNRe4hORZGeYxh%2F3%2BEH1eqMl8xludYhufc&rqlang=cn&rsv_enter=1&inputT=18426&rsv_sug3=83&rsv_sug1=66&rsv_sug7=100&sug=mysql%20%E6%9F%A5%E8%AF%A2&rsv_n=1&rsv_sug2=0&rsv_sug4=18426

 

 

 

我们首先讨论索引，因为它是加快查询的最重要的工具。还有其他加快查询的[url=javascript:;]技术[/url]，但是最有效的莫过于恰当地使用索引了。在 MySQL 的邮件清单上，人们通常询问关于使查询更快的问题。在大量的案例中，都是因为表上没有索引，一般只要加上索引就可以立即解决问题。但这样也并非总是有效，因为优化并非总是那样简单。然而，如果不使用索引，在许多情形下，用其他手段改善性能只会是浪费时间。应该首先考虑使用索引取得最大的性能改善，然后再寻求其他可能有帮助的技术。 
本节介绍索引是什么、它怎样改善查询性能、索引在什么情况下可能会降低性能，以及怎样为表选择索引。下一节，我们将讨论 MySQL 的查询优化程序。除了知道怎样创建索引外，了解一些优化程序的知识也是有好处的，因为这样可以更好地利用所创建的索引。某些编写查询的方法实际上会妨碍索引的效果，应该避免这种情况出现。（虽然并非总会这样。有时也会希望忽略优化程序的作用。我们也将介绍这些情况。） 


索引对单个表查询的影响 
索引被用来快速找出在一个列上用一特定值的行。没有索引，MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大，花费时间越多。如果表对于查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要考虑所有数据。如果一个表有1000 行，这比顺序读取至少快100倍。注意你需要存取几乎所有1000行，它较快的顺序读取，因为此时我们避免磁盘寻道。 
例如对下面这样的一个student表： 
mysql>SELECT * FROM student
+------+---------+---------+---------+---------+
| id   | name    | english | chinese |history |
+------+---------+---------+---------+---------+
|   12 | Tom     |      66|      93 |      67|
|   56 |Paul    |      78|      52 |      75|
|   10 |Marry   |      54|      89 |      74|
|    4 |Tina    |      99|      83 |      48|
|   39 | William |      43|      96 |      52|
|   74 |Stone   |      42|      40 |      61|
|   86 |Smith   |      49|      85 |      78|
|   37 |Black   |      49|      63 |      47|
|   89 |White   |      94|      31 |      52|
+------+---------+---------+---------+---------+
这样，我们试图对它进行一个特定查询时，就不得不做一个全表的扫描，速度很慢。例如，我们查找出所有english成绩不及格的学生： 
mysql>SELECT name,english FROM student WHERE english<60;
+---------+---------+
| name    | english |
+---------+---------+
| Marry   |      54 |
| William |      43 |
| Stone   |      42 |
| Smith   |      49 |
| Black   |      49 |
+---------+---------+
其中，WHERE从句不得不匹配每个记录，以检查是否符合条件。对于这个较小的表也许感觉不到太多的影响。但是对于一个较大的表，例如一个非常大的学校，我们可能需要存储成千上万的记录，这样一个检索的所花的时间是十分可观的。 
如果，我们为english列创建一个索引： 
mysql>ALTER TABLE student ADD INDEX (english) ;
+-------------------+
| index for english |
+-------------------+
|                42|
|                43|
|                49|
|                49|
|                54|
|                66|
|                78|
|                94|
|                99|
+-------------------+
如上表，此索引存储在索引文件中，包含表中每行的english列值，但此索引是在 english的基础上排序的。现在，不需要逐行搜索全表查找匹配的条款，而是可以利用索引进行查找。假如我们要查找分数小于60的所有行，那么可以扫描索引，结果得出5行。然后到达分数为66的行，及Tom的记录，这是一个比我们正在查找的要大的值。索引值是排序的，因此在读到包含Tom的记录时，我们知道不会再有匹配的记录，可以退出了。如果查找一个值，它在索引表中某个中间点以前不会出现，那么也有找到其第一个匹配索引项的定位算法，而不用进行表的顺序扫描（如二分查找法）。这样，可以快速定位到第一个匹配的值，以节省大量搜索时间。数据库利用了各种各样的快速定位索引值的技术，这些技术是什么并不重要，重要的是它们[url=javascript:;]工作[/url]正常，索引技术是个好东西。 
因此在执行下述查询 
mysql>SELECT name,english FROM user WHERE english<60;
其结果为： 
+---------+---------+
| name    | english |
+---------+---------+
| Stone   |      42 |
| William |      43 |
| Smith   |      49 |
| Black   |      49 |
| Marry   |      54 |
+---------+---------+
你应该可以发现，这个结果与未索引english列之前的不同，它是排序的，原因正式如上所述。
索引对多个表查询的影响 
前面的讨论描述了单表查询中索引的好处，其中使用索引消除了全表扫描，极大地加快了搜索的速度。在执行涉及多个表的连接查询时，索引甚至会更有价值。在单个表的查询中，每列需要查看的值的数目就是表中行的数目。而在多个表的查询中，可能的组合数目极大，因为这个数目为各表中行数之积。 
假如有三个未索引的表 t1、t2、t3，分别只包含列 c1、c2、c3，每个表分别由含有数值 1 到 1000 的1000 行组成。查找对应值相等的表行组合的查询如下所示： 
此查询的结果应该为 1000 行，每个组合包含 3 个相等的值。如果我们在无索引的情况下处理此查询，则不可能知道哪些行包含那些值。因此，必须寻找出所有组合以便得出与 WHERE 子句相配的那些组合。可能的组合数目为1000×1000×1000（十亿），比匹配数目多一百万倍。很多工作都浪费了，并且这个查询将会非常慢，即使在如像 MySQL 这样快的数据库中执行也会很慢。而这还是每个表中只有 1000 行的情形。如果每个表中有一百万行时，将会怎样？很显然，这样将会产生性能极为低下的结果。如果对每个表进行索引，就能极大地加速查询进程，因为利用索引的查询处理如下： 
1) 如下从表 t1 中选择第一行，查看此行所包含的值。 
2) 使用表 t2 上的索引，直接跳到 t2 中与来自t1 的值匹配的行。类似，利用表 t3 上的索引，直接跳到 t3中与来自t1 的值匹配的行。 
3) 进到表 t1 的下一行并重复前面的过程直到 t1 中所有的行已经查过。 
在此情形下，我们仍然对表 t1 执行了一个完全扫描，但能够在表 t2 和 t3 上进行索引查找直接取出这些表中的行。从道理上说，这时的查询比未用索引时要快一百万倍。 
如上所述，MySQL 利用索引加速了 WHERE 子句中与条件相配的行的搜索，或者说在执行连接时加快了与其他表中的行匹配的行的搜索。 
多列索引对查询的影响 
假定你发出下列SELECT语句： 
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
如果一个多列索引存在于col1和col2上，适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上，优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。 
你可以这样创建一个多列索引： 
mysql>ALTER TABLE tbl_name ADD INDEX(col1,col2);
而你应该这样创建分开的单行列索引： 
mysql>ALTER TABLE tble_name ADD INDEX(col1);mysql>ALTER TABLE tble_nameADD INDEX(col1);
如果表有一个多列索引，任何最左面的索引前缀能被优化器使用以找出行。例如，如果你有一个3行列索引(col1,col2,col3)，你已经索引了在(col1)、(col1,col2)和(col1,col2,col3)上的搜索能力。 
如果列不构成索引的最左面前缀，MySQL不能使用一个部分的索引。假定你下面显示的SELECT语句： 
mysql> SELECT * FROM tbl_name WHERE col1=val1;mysql> SELECT * FROMtbl_name WHERE col2=val2;mysql> SELECT * FROM tbl_name WHERE col2=val2 ANDcol3=val3;
如果一个索引存在于(col1、col2、col3)上，只有上面显示的第一个查询使用索引。第二个和第三个查询确实包含索引的列，但是(col2)和(col2、col3)不是(col1、col2、col3)的最左面前缀。 
如果LIKE参数是一个不以一个通配符字符起始的一个常数字符串，MySQL也为LIKE比较使用索引。例如，下列SELECT语句使用索引： 
mysql> select * from tbl_name where key_col LIKE"Patrick%";mysql> select * from tbl_name where key_col LIKE"Pat%_ck%";
在第一条语句中，只考虑有"Patrick" <= key_col <"Patricl"的行。在第二条语句中，只考虑有"Pat"<= key_col < "Pau"的行。 
下列SELECT语句将不使用索引： 
mysql> select * from tbl_name where key_col LIKE"%Patrick%";mysql> select * from tbl_name where key_col LIKEother_col;
在第一条语句中，LIKE值以一个通配符字符开始。在第二条语句中，LIKE值不是一个常数。 
如果 column_name 是一个索引，使用column_name IS NULL的搜索将使用索引。 
MySQL通常使用找出最少数量的行的索引。一个索引被用于你与下列操作符作比较的列：=、>、>=、<、<=、BETWEEN和一个有一个非通配符前缀象'something%'的LIKE的列。 
对于一个多列索引，如果在WHERE子句的所有AND层次使用索引，将不使用来索引优化查询。为了能够使用索引优化查询，必须把一个多列索引的前缀使用在一个AND条件组中。 
下列WHERE子句使用索引： 
... WHERE index_part1=1 AND index_part2=2... WHERE index=1 OR A=10 ANDindex=2      ... WHERE index_part1='hello' ANDindex_part_3=5          这些WHERE子句不使用索引： ... WHEREindex_part2=1 AND index_part3=2  ... WHERE index=1 OR A=10                  ...WHERE index_part1=1 OR index_part2=10  
MySQL索引的作用 
所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。字符串是自动地压缩前缀和结尾空间。CREATE INDEX句法。 
索引用于： 
快速找出匹配一个WHERE子句的行。 
在多个表的查询时，执行连接时加快了与其他表中的行匹配的行的搜索。 
对特定的索引列找出MAX()或MIN()值。 
如果排序或分组在一个可用索引的最左面前缀上进行(例如，ORDER BYkey_part_1,key_part_2)，排序或分组一个表。如果所有键值部分跟随DESC，键以倒序被读取。 
在一些情况中，一个查询能被优化来检索值，不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀，为了更快，值可以从索引树被检索出来。 
索引的弊端 

一般情况下，如果 MySQL 能够知道怎样用索引来更快地处理查询，它就会这样做。这表示，在大多数情况下，如果您不对表进行索引，则损害的是您自己的利益。可以看出，作者描绘了索引的诸多好处。但有不利之处吗？是的，有。实际上，这些缺点被优点所掩盖了，但应该对它们有所了解。 
首先，索引文件要占磁盘空间。如果有大量的索引，索引文件可能会比数据文件更快地达到最大的文件尺寸。其次，索引文件加快了检索，但增加了插入和删除，以及更新索引列中的值的时间（即，降低了大多数涉及写入的操作的时间），因为写操作不仅涉及数据行，而且还常常涉及索引。一个表拥有的索引越多，则写操作的平均性能下降就越大。在8.4.4节记录装载和修改的速度中，我们将更为详细地介绍这些性能问题，并讨论怎样解决。 
选择索引的准则 
创建索引的语法已经在4.5索引属性中进行了介绍。这里，我们假定您已经阅读过该节。但是知道语法并不能帮助确定表怎样进行索引。要决定表怎样进行索引需要考虑表的使用方式。本节介绍一些关于怎样确定和挑选索引列的准则： 
1、搜索的索引列，不一定是所要选择的列 
换句话说，最适合索引的列是出现在 WHERE 子句中的列，或连接子句中指定的列，而不是出现在SELECT 关键字后的选择列表中的列，例如： 


SELECTcol_a                           ←不适合作索引列FROMTbl1 LEFT JOIN tbl2ON tbl1.col_b =tbl2.col_c      ←适合作索引列WHEREcol_d =expr                    ←适合作索引列
当然，所选择的列和用于 WHERE 子句的列也可能是相同的。关键是，列出现在选择列表中不是该列应该索引的标志。 
出现在连接子句中的列或出现在形如 col1 = col2 的表达式中的列是很适合索引的列。查询中的col_b 和col_c 就是这样的例子。如果 MySQL 能利用连接列来优化一个查询，表示它通过消除全表扫描相当可观地减少了表行的组合。 
2、使用惟一索引 
考虑某列中值的分布。对于惟一值的列，索引的效果最好，而具有多个重复值的列，其索引效果最差。例如，存放年龄的列具有不同值，很容易区分各行。而用来记录性别的列，只含有“M”和“F”，则对此列进行索引没有多大用处（不管搜索哪个值，都会得出大约一半的行）。 
3、使用短索引 
如果对串列进行索引，应该指定一个前缀长度，只要有可能就应该这样做。例如，如果有一个 CHAR(200) 列，如果在前 10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。对前 10 个或 20 个字符进行索引能够节省大量索引空间，也可能会使查询更快。较小的索引涉及的磁盘 I/O 较少，较短的值比较起来更快。更为重要的是，对于较短的键值，索引高速缓存中的块能容纳更多的键值，因此，MySQL 也可以在内存中容纳更多的值。这增加了找到行而不用读取索引中较多块的可能性。（当然，应该利用一些常识。如仅用列值的第一个字符进行索引是不可能有多大好处的，因为这个索引中不会有许多不同的值。） 
4、利用最左前缀 
在创建一个 n 列的索引时，实际是创建了 MySQL 可利用的n 个索引。多列索引可起几个索引的作用，因为可利用索引中最左边的列集来匹配行。这样的列集称为最左前缀。（这与索引一个列的前缀不同，索引一个列的前缀是利用该的前 n 个字符作为索引值。） 
假如一个表在分别名为 state、city 和zip 的三个列上有一个索引。索引中的行是按 state/city/zip 的次序存放的，因此，索引中的行也会自动按state/city 的顺序和 state 的顺序存放。这表示，即使在查询中只指定state 值或只指定 state 和 city 的值，MySQL 也可以利用索引。因此，此索引可用来搜索下列的列组合： 
MySQL 不能使用不涉及左前缀的搜索。例如，如果按 city 或 zip 进行搜索，则不能使用该索引。如果要搜索某个州以及某个 （索引中的列1和列3），则此索引不能用于相应值的组合。但是，可利用索引来寻找与该州相符的行，以减少搜索范围。 
5、不要过度索引 
不要以为索引“越多越好”，什么东西都用索引是错的。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能，这一点我们前面已经介绍过。在修改表的内容时，索引必须进行更新，有时可能需要重构，因此，索引越多，所花的时间越长。如果有一个索引很少利用或从不使用，那么会不必要地减缓表的修改速度。此外，MySQL 在生成一个执行计划时，要考虑各个索引，这也要费时间。创建多余的索引给查询优化带来了更多的工作。索引太多，也可能会使 MySQL 选择不到所要使用的最好索引。只保持所需的索引有利于查询优化。 
如果想给已索引的表增加索引，应该考虑所要增加的索引是否是现有多列索引的最左索引。如果是，则就不要费力去增加这个索引了，因为已经有了。 
6、考虑在列上进行的比较类型 
索引可用于“<”、“<=”、“=”、“>=”、“>”和BETWEEN 运算。在模式具有一个直接量前缀时，索引也用于 LIKE 运算。如果只将某个列用于其他类型的运算时（如STRCMP( )），对其进行索引没有价值。 

本节介绍了索引在优化查询中的作用，包括了索引优化查询的原理，索引在各种情况的检索中的益处，也包括索引的的弊端：增加了存储的空间，使装载数据变慢。 
索引是优化查询的最常用也是最有效的的方法，一个数据表，尤其是容量很大的表，建立合适的索引，会使查询的速度提高很大

 

 

 

 

 

 

 

 

 

 

file_get_contents获取网址内容信息

Web       安全问题

SQL注入、XPath注入、cgi命令执行

 

加快web访问

1尽量减少HTTP请求

减少server响应时间

用压缩  ) 压缩CSS压缩javascript

开启浏览器缓存

优化图像

优化css

减少网站插件的使用数量

减少重定向

 

 

 

 

 

跨域请求加密

提高SQL查询效率的30种方法

 

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在where及 orderby 涉及的列上建立索引。 

2.应尽量避免在 where子句中对字段进行 null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： 
select id from t where num is null 
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： 
select id from t where num=0 

3.应尽量避免在 where子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 

4.应尽量避免在 where子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： 
select id from t where num=10 or num=20 
可以这样查询： 
select id from t where num=10 
union all 
select id from t where num=20 

5.in 和 not in也要慎用，否则会导致全表扫描，如： 
select id from t where num in(1,2,3) 
对于连续的数值，能用 between就不要用 in 了： 
select id from t where num between 1 and 3 

6.下面的查询也将导致全表扫描： 
select id from t where name like '%abc%' 
若要提高效率，可以考虑全文检索。 

7. 如果在 where子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描： 
select id from t where num=@num 
可以改为强制查询使用索引： 
select id from t with(index(索引名))where num=@num 

8.应尽量避免在 where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如： 
select id from t where num/2=100 
应改为: 
select id from t where num=100*2 

9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如： 
select id from t where substring(name,1,3)='abc'--name以abc开头的id 
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id 
应改为: 
select id from t where name like 'abc%' 
select id from t where createdate>='2005-11-30' andcreatedate<'2005-12-1' 

10.不要在 where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。 

12.不要写一些没有意义的查询，如需要生成一个空表结构： 
select col1,col2 into #t from t where 1=0 
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样： 
create table #t(...) 

13.很多时候用 exists代替 in 是一个好的选择： 
select num from a where num in(select num from b) 
用下面的语句替换： 
select num from a where exists(select 1 from b where num=a.num) 

14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。 

15. 索引并不是越多越好，索引固然可以提高相应的select的效率，但同时也降低了insert及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。 

16.应尽可能的避免更新clustered索引数据列，因为clustered索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新clustered索引数据列，那么需要考虑是否应将该索引建为clustered索引。 

17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 

18.尽可能的使用varchar/nvarchar代替char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。 

19.任何地方都不要使用 select* from t，用具体的字段列表代替“*”，不要返回用不到的任何字段。 

20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。 

21.避免频繁创建和删除临时表，以减少系统表资源的消耗。 

22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。 

23.在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替 createtable，避免造成大量 log，以提高速度；如果数据量不大，为了缓和系统表的资源，应先createtable，然后insert。 

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后 droptable，这样可以避免系统表的较长时间锁定。 

25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。 

26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。 

27. 与临时表一样，游标并不是不可使用。对小型数据集使用FAST_FORWARD游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。 

28.在所有的存储过程和触发器的开始处设置SET NOCOUNT ON，在结束时设置 SETNOCOUNT OFF。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC消息。 

29.尽量避免大事务操作，提高系统并发能力。 

30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理

 

 

 

 

 

 

 

 

 

 

 

 

 

压力测试工具

 

Grinder –  Grinder是一个开源的JVM负载测试框架，它通过很多负载注射器来为分布式测试提供了便利。支持用于执行测试脚本的Jython脚本引擎HTTP测试可通过HTTP代理进行管理。根据项目网站的说法，Grinder的主要目标用户是“理解他们所测代码的人——Grinder不仅仅是带有一组相关响应时间的‘黑盒’测试。由于测试过程可以进行编码——而不是简单地脚本化，所以程序员能测试应用中内部的各个层次，而不仅仅是通过用户界面测试响应时间。

Pylot -Pylot是一款开源的测试web service性能和扩展性的工具，它运行HTTP负载测试，这对容量计划，确定基准点，分析以及系统调优都很有用处。Pylot产生并发负载（HTTP Requests），检验服务器响应，以及产生带有metrics的报表。通过GUI或者shell/console来执行和监视test suites。

Web Capacity Analysis Tool (WCAT) –这是一种轻量级负载生成实用工具，不仅能够重现对 Web服务器（或负载平衡服务器场）的脚本 HTTP请求，同时还可以收集性能统计数据供日后分析之用。WCAT是多线程应用程序，并且支持从单个源控制多个负载测试客户端，因此您可以模拟数千个并发用户。该实用工具利用您的旧机器作为测试客户端，其中每个测试客户端又可以产生多个虚拟客户端（最大数量取决于客户端机器的网络适配器和其他硬件）。您可以选择使用 HTTP 1.0还是 HTTP 1.1请求，以及是否使用 SSL。并且，如果测试方案需要，您还可以使用脚本执行的基本或 NTLM身份验证来访问站点的受限部分。（如果您的站点使用 cookie、表单或基于会话的身份验证，那您可以创建正确的 GET或 POST 请求来对测试用户进行身份验证。）WCAT还可管理您站点可能设置的任何 cookie，所以配置文件和会话信息将永久保存。

fwptt – fwptt 也是一个用来进行WEB应用负载测试的工具。它可以记录一般的请求，也可以记录Ajax请求。它可以用来测试 asp.net， jsp， php 或是其它的Web应用。

JCrawler – JCrawler是一个开源( CPL)的WEB应用压力测试工具。通过其名字，你就可以知道这是一个用Java写的像网页爬虫一样的工具。只要你给其几个URL，它就可以开始爬过去了，它用一种特殊的方式来产生你WEB应用的负载。这个工具可以用来测试搜索引擎对你站点产生的负载。当然，其还有另一功能，你可以建立你的网站地图和再点击一下，将自动提交Sitemap给前5名的搜索引擎！

Apache JMeter – Apache JMeter是一个专门为运行和服务器装载测试而设计的、100％的纯Java桌面运行程序。原先它是为Web/HTTP测试而设计的，但是它已经扩展以支持各种各样的测试模块。它和用于HTTP和SQL数据库（使用JDBC）的模块一起运送。它可以用来测试静止资料库或者活动资料库中的服务器的运行情况，可以用来模拟对服务器或者网络系统加以重负荷以测试它的抵抗力，或者用来分析不同负荷类型下的所有运行情况。它也提供了一个可替换的界面用来定制数据显示，测试同步及测试的创建和执行。

Siege -Siege（英文意思是围攻）是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。 Siege支持基本的认证，cookies， HTTP和 HTTPS 协议。

http_load – http_load 以并行复用的方式运行，用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。可以可以测试HTTPS类的网站请求。

Web Polygraph – Web Polygraph这个软件也是一个用于测试WEB性能的工具，这个工具是很多公司的标准测试工具，包括微软在分析其软件性能的时候，也是使用这个工具做为基准工具的。很多招聘测试员的广告中都注明需要熟练掌握这个测试工具。

OpenSTA – OpenSTA是一个免费的、开放源代码的web性能测试工具，能录制功能非常强大的脚本过程，执行性能测试。例如虚拟多个不同的用户同时登陆被测试网站。其还能对录制的测试脚本进行,按指定的语法进行编辑。在录制完测试脚本后，可以对测试脚本进行编辑，以便进行特定的性能指标分析。其较为丰富的图形化测试结果大大提高了测试报告的可阅读性。OpenSTA 基于CORBA 的结构体系，它通过虚拟一个proxy，使用其专用的脚本控制语言，记录通过 proxy 的一切HTTP/S traffic。通过分析OpenSTA的性能指标收集器收集的各项性能指标，以及HTTP 数据，对系统的性能进行分析。

欢迎您留下你认为不错的WEB应用性能测试的工具。