SQL Server数据库如下方法来优化查询 :
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量(尺寸)越大，提高I/O越重要.
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小，使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段
5、提高网速;
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。
7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert， Delete还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离;OLTP和OLAP分离
10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。(参照SQL帮助文件'分区视图')
a、在实现分区视图之前，必须先水平分区表
b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12.commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物. 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
14、SQL的注释申明对执行没有任何影响
15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。游标可以按照它所支持的提取选项进行分类： 只进 必须按照从第一行到最后一行的顺序提取行。
FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大，他的目的是支持循环。有四个并发选项 READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。 OPTIMISTIC WITH valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。在 SQL Server 中，这个性能由 timestamp 数据类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任何方式更改带有 timestamp 列的行时，SQL Server 先在时间戳列中存储当前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 个表具有 timestamp 列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较 timestamp 列即可。如果应用程序对没有 timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。 SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 Select 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则 COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标 Select 语句中的锁提示。锁提示 只读 乐观数值 乐观行版本控制 锁定无提示 未锁定 未锁定 未锁定 更新 NOLOCK 未锁定 未锁定未锁定 未锁定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 错误 更新 更新 更新 TABLOCKX 错误 未锁定 未锁定更新其它 未锁定 未锁定 未锁定 更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。
16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题所在;用索引优化器优化索引
17、注意UNion和UNion all 的区别。UNION all好
18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的
19、查询时不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。 SET LOCKTIME设置锁的时间
21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为他们不走索引全是表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描)，一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，严重优化的重点是这些慢的地方。
24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。
26、MIN() 和 MAX()能使用到合适的索引。
27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。
28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。
29、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次，所以有时会慢些。
30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。
32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。
select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
83 <!---->
'JCNAD00333138','JCNAD00303570','JCNAD00303569',
'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
'JCNAD00254567','JCNAD00254585','JCNAD00254608',
'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
'JCNAD00279196','JCNAD00268613') order by postdate desc
35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
36、当用Select INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到 Select INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
38、一次更新多条记录比分多次更新每次一条快,就是说批处理好
39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好
40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：
a、计算字段的表达是确定的
b、不能用在TEXT,Ntext，Image数据类型
c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程
42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快
43、Select COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!
44、当服务器的内存够多时，配制线程数量 = 最大连接数+5，这样能发挥最大的效率;否则使用 配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量 = 最大连接数+5，严重的损害服务器的性能。
45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
46、通过SQL Server Performance Monitor监视相应硬件的负载 Memory: Page Faults / sec计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
Process:
1、% DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。 由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部 分。这个总数显示了作为实例时间百分比的平均忙时。
2、%Processor Time计数器 如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
3、% Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的 % 包括为间断和 DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。
4、% User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 Physical Disk: Curretn Disk Queue Length计数器该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。 SQLServer:Cache Hit Ratio计数器该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。
84 <!---->
47、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。
48、查询的关联同写的顺序
select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '号码'）
select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '号码'， A = '号码'）
select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '号码'， A = '号码'）
49、
(1)IF 没有输入负责人代码 THEN code1=0 code2=9999 ELSE code1=code2=负责人代码 END IF 执行SQL语句为: Select 负责人名 FROM P2000 Where 负责人代码>=:code1 AND负责人代码 <=:code2
<clk></clk> (2)IF 没有输入负责人代码 THEN Select 负责人名 FROM P2000 ELSE code= 负责人代码 Select 负责人代码 FROM P2000 Where 负责人代码=:code END IF 第一种方法只用了一条SQL语句,第二种方法用了两条SQL语句。在没有输入负责人代码时,第二种方法显然比第一种方法执行效率高,因为它没有限制条件; 在输入了负责人代码时,第二种方法仍然比第一种方法效率高,不仅是少了一个限制条件,还因相等运算是最快的查询运算。我们写程序不要怕麻烦
50、关于JOBCN现在查询分页的新方法(如下)，用性能优化器分析性能的瓶颈，如果在I/O或者网络的速度上，如下的方法优化切实有效，如果在CPU或者内存上，用现在的方法更好。请区分如下的方法，说明索引越小越好。
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by ReferenceID
select * from @local_variable where Fid > 40 and fid <= 60
end 和
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from @local_variable where Fid > 40 and fid <= 60
end 的不同
begin
create table #temp (FID int identity(1,1),ReferenceID varchar(20))
insert into #temp (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from #temp where Fid > 40 and fid <= 60 drop table #temp
end
另附：存储过程编写经验和优化措施 From：网页教学网
一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP(存储过程)的优化的项目开发人员，对数据库有浓厚兴趣的人。
二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
三、内容：
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。
3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
a)SQL的使用规范：
i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
iii. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写;如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
v. 不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
vi. 尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
vii. 尽量使用“>=”，不要使用“>”。
viii. 注意一些or子句和union子句之间的替换
ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。
x. 注意存储过程中参数和数据类型的关系。
xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面(400k)，那么系统将会进行锁升级，页级锁会升级成表级锁。
b)索引的使用规范：
i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
iii. 避免对大表查询时进行table scan，必要时考虑新建索引。
iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
v. 要注意索引的维护，周期性重建索引，重新编译存储过程。
c)tempdb的使用规范：
i. 尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。
iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度;如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
v. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
vi. 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
d)合理的算法使用：
根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。
转自：http://fableking.iteye.com/blog/360900
posted @
2011-08-13 12:41 [ 王志伟 ] 阅读(265) |
评论 (0) |
编辑 收藏千万人同时访问的网站，一般是有很多个数据库同时工作，说明白一点就是数据库集群和并发控制，这样的网站实时性也是相对的。这些网站都有一些共同的特点：数据量大，在线人数多，并发请求多，pageview高，响应速度快。总结了一下各个大网站的架构，主要提高效率及稳定性的几个地方包括：
1、程序
程序开发是一方面，系统架构设计（硬件+网络+软件）是另一方面。
软件架构方面，做网站首先需要很多web服务器存储静态资源，比如图片、视频、静态页等，千万不要把静态资源和应用服务器放在一起。
一个好的程序员写出来的程序会非常简洁、性能很好，一个初级程序员可能会犯很多低级错误，这也是影响网站性能的原因之一。
网站要做到效率高，不光是程序员的事情，数据库优化、程序优化这是必须的，在性能优化上要数据库和程序齐头并进！缓存也是两方面同时入手。第一，数据库缓存和数据库优化，这个由dba完成（而且这个有非常大的潜力可挖，只是由于我们都是程序员而忽略了他而已）。第二，程序上的优化，这个非常的有讲究，比如说重要一点就是要规范ＳＱＬ语句，少用in 多用or，多用preparestatement 存储过程，另外避免程序冗余如查找数据少用双重循环等。另外选用优秀的开源框架加以支持，我个人认为中后台的支持是最最重要的，可以选取spring＋ibatis。因为ibatis直接操作SQL并有缓存机制。spring的好处就不用我多说了，ＩＯＣ的机制可以避免new对象，这样也节省开销。据我分析，绝大部分的开销就是在NEW的时候和连接数据库时候产生的，请尽量避免。另外可以用一些内存测试工具来做一个demo说明hibernate和ibatis谁更快！前台你想用什么就用什么，struts,webwork都成，如果觉得自己挺牛X可以试试用tapestry。
用数据库也未必不能解决访问量巨大所带来的问题，作成静态文件硬盘的寻址时间也未必少于数据库的搜索时间，当然对资料的索引要下一翻工夫。我自己觉得门户往往也就是当天、热门的资料点击率较高，将其做缓存最多也不过1~2G的数据量吧，举个例子：
◎ 拿网易新闻来说http://news.163.com/07/0606/09/3GA0D10N00011229.html
格式化一下，方便理解：http://域名/年/月日/新闻所属分类/新闻ID.html
可以把当天发布的、热门的、浏览量大的作个缓存，用hashtable（key：年-月-日-分类-ID，value：新闻对象），静态将其放到内存（速度绝对快过硬盘寻址静态页面）。
通常是采用oracle存储过程＋2个weblogic，更新机制也几乎一样每签发一条新闻，就会生成静态页面，然后发往前端的web服务器，前端的web都是做负载均衡的。另外还有定时程序，每5-15分钟自动生成一次。在发布新闻的同时将数据缓存。当然缓存也不会越来越大，在个特定的时间段（如凌晨）删除过期的数据。做一个大的网站远没有想象中那么简单，服务器基本就要百十个的。
这样可以大大增加一台计算机的处理速度，如果一台机器处理不了，可以用httpserver集群来解决问题了。
2、网络
中国的网络分南电信和北网通，访问的ip就要区分南北进入不同的网络。
3、集群
通常会使用CDN与GSBL与DNS负载均衡技术，每个地区一组前台服务器群，比如新浪和搜狐，而网易，百度使用了DNS负载均衡技术，每个频道一组前台服务器；一搜使用了DNS负载技术，所有频道共用一组前台服务器集群。
网站使用基于Linux集群的负载均衡，失败恢复，包括应用服务器和数据库服务器，基于linux-ha的服务状态检测及高可用化。
应用服务器集群可以采用apache+tomcat集群和weblogic集群等；web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；Squid也可以，方法很多，可以根据情况选择。
4、数据库
因为是千万人同时访问的网站，所以一般是有很多个数据库同时工作的，说明白一点就是数据库集群和并发控制，数据分布到地理位置不同的数据中心，以免发生断电事故。
主流的数据库有Sun的是MySQL和Oracle。
Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一款非常优秀的开源数据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
MySQL数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。
另外还有一点的是，那些网站的静态化网页并不是真的，而是通过动态网页与静态网页网址交换所出现的假象，这可以用urlrewrite这样的开源网址映射器实现。这样的网站实时性也是相对的，因为在数据库复制数据的时候有一个过程，一般在技术上可以用到hibernate和ecache，但是如果要使网站工作地更好，可以使用EJB和websphere，weblogic这样大型的服务器来支持，并且要用oracle这样的大型数据库。
大型门户网站不建议使用Mysql数据库，除非你对Mysql数据的优化非常熟悉。Mysql数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。
大型网站要用oracle，数据方面操作尽量多用存储过程，绝对提升性能；同时要让DBA对数据库进行优化，优化后的数据库与没优化的有天壤之别；同时还可以扩展分布式数据库，以后这方面的研究会越来越多；
5、页面
从开始就考虑使用虚拟存储/簇文件系统。它能让你大量并行IO访问，而且不需要任何重组就能够增加所需要的磁盘。
页面数据调用更要认真设计，一些数据查询可以不通过数据库的方式，实时性要求不高的可以使用lucene来实现，即使有实时性的要求也可以用lucene（基于Java的全文索引/检索引擎），lucene+compass还是非常优秀的。
新闻类的网站可以用静态页存储，采用定时更新机制减轻服务器负担；首页每个小模块可以使用oscache缓存，这样不用每次都拉数据。
前端的基于静态页面缓存的web加速器，主要应用有squid等。squid 将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载
网站的静态化网页并不是真的，而是通过动态网页与静态网页网址交换做出现的假象，这可以用urlrewrite这样的开源网址映射器实现，后缀名为htm或者html并不能说明程序生成了静态页面，可能是通过url重写来实现的，为的只不过是在搜索引擎中提升自己网站的覆盖面积罢了。
生成静态页面的服务器和www服务器是两组不同的服务器，页面生成后才会到www服务器，一部分数据库并不是关系数据库，这样更适合信息衍生，www、mail服务器、路由器多，主要用负载平衡解决访问瓶颈。
◎ 静态页面的缺点：
1) 增加了程序的复杂度
2) 不利于管理资料
3) 速度不是最快
4) 伤硬盘
6、缓存
从一开始就应该使用缓存，高速缓存是一个更好的地方存储临时数据，比如Web站点上跟踪一个特定用户的会话产生的临时文件，就不再需要记录到数据库里。
不能用lucene实现的可以用缓存，分布式缓存可以用memcached，如果有钱的话用10来台机器做缓存，> 10G的存储量相信存什么都够了；如果没钱的话可以在页面缓存和数据缓存上下功夫，多用OSCACHE和EHCACHE，SWARMCACHE也可以，不过据说同步性不是很好；
可以使用Memcache（分布式缓存）进行缓存，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，memcache是LJ开发的一款分布式缓存产品，很多大型网站在应用，我们可以把Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。
单机内存缓存、文件缓存、数据库缓存等的策略都是可以很简单的实现的，例如可以使用微软的Caching Application Block，但如何在集群环境中使多个缓存、多层缓存并保存同步是个重大问题。大型网站一般都使用缓存服务器群，并使用多层缓存。业内最常用的有：
Squid cache，Squid服务器群，把它作为web服务器端前置cache服务器缓存相关请求来提高web服务器速度。Squid将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载
memcache，memcache服务器群，一款分布式缓存产品，很多大型网站在应用; 它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索，而多个用户查询相同的SQL时，数据库压力会增大，而通过memcache的查询缓存命中，数据直接从memcache内存中取，每次缓存命中将替换到数据库服务器的一次往返，到达数据库服务器的请求更少，间接地提高了数据库服务器的性能，从而使应用程序运行得更快。它通过基于内存缓存对象来减少数据库查询的方式改善网站系统的反应，其最吸引人的一个特性就是支持分布式部署。有关memcache，以下文章可以参考：参考1，参考2，参考3官方站点。
e-Accelerator，比较特殊，PHP的缓存和加速器。是一个免费开源的PHP加速、优化、编译和动态缓存的项目，它可以通过缓存PHP代码编译后的结果来提高PHP脚本的性能，使得一向很复杂和离我们很远的 PHP脚本编译问题完全得到解决。通过使用eAccelerator，可以优化你的PHP代码执行速度，降低服务器负载，可以提高PHP应用执行速度最高达10倍。
7、服务器操作系统与Web服务器
最底层首先是操作系统。好的操作系统能提高好的性能、稳定性和安全性，而这些对大型网站的性能、安全性和稳定性都是至关重要的。
- 淘宝网（阿里巴巴）: Linux操作系统 + Web 服务器: Apache
- 新浪：FreeBSD + Web 服务器：Apache
- Yahoo：FreeBSD + Web 服务器：自己的
- Google: 部分Linux + Web 服务器：自己的
- 百度：Linux + Web 服务器: Apache
- 网易：Linux + Web 服务器: Apache
- eBay: Windows Server 2003/8 (大量) + Web 服务器：Microsoft IIS
- MySpace: Windows Server 2003/8 + Web 服务器：Microsoft IIS
由此可见，开源操作系统做Web应用是首选已经是一个既定事实。在开源操作系统中Linux和FreeBSD差不太多，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。但熟悉Linux的技术人员更多些，利于系统管理、优化等，所以Linux使用更广泛。而Windows Server和IIS虽然有的网站使用，但不开源，而且需要购买微软的一系列应用产品，限制了其使用。总之，开源操作系统，尤其是Linux做Web应用是首选已经是一个既定事实。
常用的系统架构是:
- Linux + Apache + PHP + MySQL
- Linux + Apache + Java (WebSphere) + Oracle
- Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库
以上一些不太成熟的想法，可以从某一个层次开始，逐步细化，把产品的性能指标提高上去。
转自：
http://blog.sina.com.cn/s/blog_56fd58ab0100o2hw.html
posted @
2011-08-13 12:29 [ 王志伟 ] 阅读(470) |
评论 (0) |
编辑 收藏
以前在安装sql的时候，如此提示，我只要重新启动即可，可是今天重新启动了N次计算机，问题却丝毫没有解决，依然提示这样的话。“以前的某个程序安装已在安装计算机上创建挂起的文件操作。运行安装程序之前必须重新启动计算机。” 只好google以下，最终得知是安装程序在先前的安装过程中在系统注册表留下某些信息，导致不能安装。于是经过多次试，发现删除掉如下键值信息即可安装：
在运行窗口输入regedit，打开注册表编辑器，在HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\session Manager中找到PendingFileRenameOperations，删除该键值（这个键值是安装程序暂挂项目，只要找到对应的应用程序清除掉就行了），关闭注册表编辑器。重新安装SQL Server 2000即可。
特整理收藏与下，以便查找。
资料引用:http://www.knowsky.com/340304.html
posted @
2011-07-03 22:23 [ 王志伟 ] 阅读(168) |
评论 (0) |
编辑 收藏
打开Sql Server 2000企业管理器时，显示的错误状态：
MMC 不能打开文件 C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC。
分析：
参看文件是否存在或被损坏。
无论那种，先将其删除
然后，在运行框中输入 mmc，打开控制台
执行以下三个步骤：
1、控制台--添加/删除管理单元--添加--找到Microsoft SQL 企业管理器--添加--关闭--确定
2、控制台--选项--控制台模式选择"用户模式完全访问"--将下面的选择全部取消
3、控制台--另存为--存储为:C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC
在第三步时可能会遇到“无法保存”，这种现象。
则在运行框中输入 regsvr32 C:\Windows\system32\msxml3.dll
然后再执行上面的第三步，即可
参考：
http://www.leezao.cn/article.asp?id=467
posted @
2011-07-03 22:22 [ 王志伟 ] 阅读(736) |
评论 (0) |
编辑 收藏
性能测试过程中，我们该如何监控java虚拟机内存的使用情况，用以判断JVM是否存在内存问题呢？如何判断JVM垃圾回收是否正常？一般的top指令基本上满足不了这样的需求，因为它主要监控的是总体的系统资源，很难定位到java应用程序。
在项目实践过程中，我们探索和使用了一款新工具－－Jstat。
先秀一下。Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。可见，Jstat是轻量级的、专门针对JVM的工具，非常适用。
那，该怎么用呢？
语法结构如下：jstat [Options] vmid [interval] [count]
Options — 选项，我们一般使用 -gcutil 查看gc情况
vmid — VM的进程号，即当前运行的java进程号
interval– 间隔时间，单位为秒或者毫秒
count — 打印次数，如果缺省则打印无数次
下面给出一个实际的例子：
注：由于JVM内存设置较大，图中百分比变化不太明显
图中参数含义如下：
S0 — Heap上的 Survivor space 0 区已使用空间的百分比
S1 — Heap上的 Survivor space 1 区已使用空间的百分比
E — Heap上的 Eden space 区已使用空间的百分比
O — Heap上的 Old space 区已使用空间的百分比
P — Perm space 区已使用空间的百分比
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
上图的示例，红框中，我们可以看到，5次young gc之后，垃圾内存被从Eden space区(E)放入了Old space区(O)，并引起了百分比的变化，导致Survivor space使用的百分比从19.69%(S0)降到10.34%(S1)。有效释放了内存空间。绿框中，我们可以看到，一次full gc之后，Old space区(O)的内存被回收，从36.81%降到35.01%。
图中同时打印了young gc和full gc的总次数、总耗时。而，每次young gc消耗的时间，可以用相间隔的两行YGCT相减得到。每次full gc消耗的时间，可以用相隔的两行FGCT相减得到。例如红框中表示的第一行、第二行之间发生了1次young gc，消耗的时间为52.281-52.252＝0.029秒。
常驻内存区(P)的使用率，始终停留在37.6%左右，说明常驻内存没有突变，比较正常。
如果young gc和full gc能够正常发生，而且都能有效回收内存，常驻内存区变化不明显，则说明java内存释放情况正常，垃圾回收及时，java内存泄露的几率就会大大降低。但也不能说明一定没有内存泄露。
以上，介绍了Jstat按百分比查看gc情况的功能。其实，它还有其它功能，例如加载类信息统计功能、内存池信息统计功能等，那些是以绝对值的形式打印出来的，比较少用，在此就不做介绍。
为了更全面的监控JVM内存使用情况，我们需要引入更强大的工具来进一步分析–JConsole。敬请关注。
--------
一、概述
SUN 的JDK中的几个工具，非常好用。秉承着有免费，不用商用的原则。以下简单介绍一下这几种工具。(注：本文章下的所有工具都存在JDK5.0以上版本的工具集里，同javac一样，不须特意安装) 。
我一共找到以下四个工具：重点看看jconsole和jmap。
jps
:与unix上的ps类似，用来显示本地的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。
jstat
:一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。
jmap
:打印出某个java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。
jconsole
:一个java GUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。
二、 使用介绍：
1、jstat ：我想很多人都是用过unix系统里的ps命令，这个命令主要是用来显示当前系统的进程情况，有哪些进程，及其 id。 jps 也是一样，它的作用是显示当前系统的java进程情况，及其id号。我们可以通过它来查看我们到底启动了几个java进程（因为每一个java程序都会独占一个java虚拟机实例），和他们的进程号（为下面几个程序做准备），并可通过opt来查看这些进程的详细启动参数。
使用方法：在当前命令行下打 jps(需要JAVA_HOME，没有的话，到改程序的目录下打) 。
可惜没有linux下的ps好用，名称不好用。但是在第四个工具jconsole的界面里面会有具体JAR包的名称。
2、jstat ：对VM内存使用量进行监控。
jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。以下详细介绍各个参数的意义。
jstat -class pid:显示加载class的数量，及所占空间等信息。
jstat -compiler pid:显示VM实时编译的数量等信息。
jstat -gc pid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。
jstat -gccapacity:可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。其他的可以根据这个类推， OC是old内纯的占用量。
jstat -gcnew pid:new对象的信息。
jstat -gcnewcapacity pid:new对象的信息及其占用量。
jstat -gcold pid:old对象的信息。
jstat -gcoldcapacity pid:old对象的信息及其占用量。
jstat -gcpermcapacity pid: perm对象的信息及其占用量。
jstat -util pid:统计gc信息统计。
jstat -printcompilation pid:当前VM执行的信息。
除了以上一个参数外，还可以同时加上 两个数字，如：jstat -printcompilation 3024 250 6是每250毫秒打印一次，一共打印6次，还可以加上-h3每三行显示一下标题。
3、jmap 是一个可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。使用方法 jmap -histo pid。如果连用 SHELL jmap -histo pid>a.log可以将其保存到文本中去（windows下也可以使用），在一段时间后，使用文本对比工具，可以对比出GC回收了哪些对象。jmap -dump:format=b,file=f1 3024可以将3024进程的内存heap输出出来到f1文件里。
4、jconsole 是一个用java写的GUI程序，用来监控VM，并可监控远程的VM，非常易用，而且功能非常强。由于是GUI程序，这里就不详细介绍了，不会的地方可以参考ＳＵＮ的官方文档。
使用方法：命令行里打 jconsole，选则进程就可以了。
友好提示：windows查看进程号，由于任务管理器默认的情况下是不显示进程id号的，所以可以通过如下方法加上。ctrl+alt+del打开任务管理器，选择‘进程’选项卡，点‘查看’->''选择列''->加上''PID''，就可以了。当然还有其他很好的选项。
三、参考资料：
article:http://elf8848.javaeye.com/blog/442806
jps:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jps.html
jstat:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html
jmap:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html
jconsole:http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
posted @
2011-05-29 23:08 [ 王志伟 ] 阅读(7474) |
评论 (0) |
编辑 收藏
PermGen space这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
我在做
TMS的发布工具的时候，就遇到了问题，这个工具的目的是把一个相同的系统，在tomcat下自动的发布多份，但当卸载，重新发布多次后， tomcat就挂了，整个电脑如同死机一般。后来使用文章里的set JAVA_OPTS=-server -Xms800m -Xmx800m -XX:PermSize=64M-XX:MaxNewSize=256m-XX:MaxPermSize=128m -Djava.awt.headless=true 解决了问题，不过在2G的电脑上，我是把-XX:MaxPermSize=128m 调到了-XX:MaxPermSize=256m。另外我还尝试了把所有的lib都放到tomcat的lib下，一些lib就不能在本项目中再出现了。
现在看，还是spring，hibernate之类的产生的类导致PermGen space空间不足造成的这些问题。
http://www.javaeye.com/topic/80620?page=1 这个帖子里讨论了这个问题，有人做了些有益的分析可以看看。
我又继续在我的笔记本上做了测试T42,1G内存。tomcat版本6.0.14。
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true
这个配置反复发布是可以的，另外又一次测试了将项目下的jar包放到tomcat的lib下的对比。重新安装一个lib下为空的程序是10秒，否则是30秒。
总结一下：
1、修改tomcat的启动参数，类似如下的样子
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
echo Using CATALINA_BASE: %CATALINA_BASE%
echo Using CATALINA_HOME: %CATALINA_HOME%
echo Using CATALINA_TMPDIR: %CATALINA_TMPDIR%
if ""%1"" == ""debug"" goto use_jdk
echo Using JRE_HOME: %JRE_HOME%
goto java_dir_displayed
:use_jdk
echo Using JAVA_HOME: %JAVA_HOME%
:java_dir_displayed
echo Using JAVA_OPTS: %JAVA_OPTS%
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m 2、将通用的lib文件放到tomcat的目录下
posted @
2011-05-29 23:05 [ 王志伟 ] 阅读(344) |
评论 (0) |
编辑 收藏
非侵入式系介绍DI用语，我得理解是两个组件（类，接口）之间，比较独立，不深入到另一个类内部，哪位大虾能点拨一二？
关于“侵入式”和“非侵入式”设计
有读者讲“侵入式”这一术语无法理解，这里给一个简单解释，是我个人的看法。
在设计一个类时，按理说，需要考虑的应该只是该类所企图表示的那个“概念”本身：为表示有关概念应记录哪些信息，该类的对象与外界交换信息的界面等等。但定义这个类并不是为了放在那里观赏，而是为了使用。在考虑类对象的使用时，使用环境的一些要素就可能“侵入”这个类的设计之中。实际上，许多情况下我们常常可以在“侵入式”设计和“非侵入式”设计之间做一个选择，不同选择各有优缺点。在考虑非类的程序部分时，这种问题也同样存在。
例如，我们可能需要对类A的对象做引用计数，这里有两种基本可能性：将计数功能纳入类A的设计内（侵入式引用计数设计，此时类A的对象中包含了与引用计数有关的要素，这显然是与类A所要表示的概念无关的东西），或者将计数功能放在类A之外（非侵入式引用计数）。
本书中讨论容器时提出了“侵入式容器”设计和“非侵入式容器”设计的概念：当我们希望将类A的对象放入一种容器时，是否需要将该容器的实现要素“侵入”类A的设计实现之中（这显然是与类A本身并无必然关系的要素）。不同考虑导致不同的容器设计。
我基本上知道了，从夏大虾得著作中得知。
比如struts，需要继承一些struts得类，这就是侵入式，使得系统离不开那个框架。
而spring中，业务类不需要继承框架得类，将来抛弃spring也比较方便。
楼上大虾（土豆块）能否谈下ejb与spring之间得关系。你用ejb吗？如果用了，感觉如何？
非侵入式(non-intrusive)设计是目前非常热门的话题。在一般的讨论中，非侵入式设计总是和Spring这样的IoC容器或者AOP技术联系在一起。但是从思想上说，non-intrusive并不等价于IoC或者AOP，它是一个比AOP更加宽泛的概念。
首先，我们考察一下何谓intrusive。典型的intrusive实现是继承特定的基类, 或者实现特定的接口. 在抽象的意义上说, intrusive意味着在基础结构中预留了一些特殊的,专用的结构, 这些结构对于基础功能而言不仅仅是无用的, 甚至是有害的, 例如影响性能或者模糊了原有的概念结构, 而系统整体的后期扩展能力也受到这些预设的结构通道的限制.
non-intrusive设计的基本特点是尽量利用基础结构的元素, 而不是引入额外的特殊结构.例如, 在witrix平台的tpl模板中
＜button tpl:tag="ui:FlatButton" value="xx" onclick="alert('ok')" /＞
如果后台tpl引擎不解析＜ui:FlatButton＞标签, 那么该标签的表现就是普通的html button. 这里整个页面的界面表现结构没有被tpl标签所破坏,而如果像jsp tag那样强行规定必须采用节点语法, 即
＜ui:FlatButton value="xx" onclick="alert('ok')" /＞
则在没有tpl引擎的情况下, 界面结构被tpl标签所破坏,此时在dreamweaver这样的可视化工具中我们无法再识别出有效的界面元素, 丧失了WYSIWYG编辑的能力.
tpl:tag属性属于html语法本身规定了的自定义属性, 它在html中的存在是符合规范的, 而且它对于button来说没有造成什么限制或损害, 因而是一种无害的标记. 在没有tpl模板引擎的情况下, tpl:tag属性与其他自定义属性一样处于同样的地位, 没有什么特殊的作用. 而一旦tpl模板引擎识别出该特殊标记, 整个节点就被解释成一个具有丰富表现形式的平面按钮而不是系统缺省风格的普通按钮. 从级列设计的角度上说, button对应于ui:FlatButton在没有tpl解析能力情况时退化了的结果. 在EJB3的规范中, 普通的POJO(Plain Old Java Object)对象在经过无害的标记(annotation)之后通过Enhance过程获得持久化等特性, POJO正对应于EJB Object的退化形式. 在某种意义上我们可以说, 存在着多少种可退化方式，就对应着多少种non-intrusive design。
与传统设计中的结构堆砌不同, 现代技术更加强调在原有结构基础上的同态变化, 关注原有结构中的某些部分出现特殊意义后所产生的对称破缺. 在non-intrusive设计中, 基础的结构中没有为扩展内置什么特殊的结构, 一般仅仅是标记而已, 这些标记是无害的甚至本身在基础结构中是有用的, 例如某些javascript库在前台html页面中利用html标签的class属性作为标记. 为了识别这些属于结构标准部分的标记并对之进行处理,我们需要一种可选择的结构透明性, 具体来说我们需要能渗透到系统内部,准确的定位到标记处. 这就类似于x光检测, x光只与某些特殊材料发生强烈作用而普通部分对于x光而言是透明的. 而当外部引擎识别出这些特殊的标记之后, 可能需要操纵该局部结构, 例如在基础结构中插入一些新的结构以实现基础结构的增强. 这些都可能需要应用类似于AOP的技术, 而在这一增强过程中关于扩展结构的具体知识存在于扩展引擎中而不是基础结构中, 因而往往整体表现出一种IoC的特性.
转自：http://hi.baidu.com/westsky/blog/item/46d452f0127cebaaa50f522f.html
posted @
2011-04-19 10:23 [ 王志伟 ] 阅读(4542) |
评论 (0) |
编辑 收藏
<1> js或者jQuery访问页面中的框架iframe.
注意:框架内的页面是不能跨域的! 假设有两个页面,在相同域下.
假设：父窗口 index.html ，有 id 为 subifrm 的 iframe
1. 在index.html执行JS直接访问子窗口中某元素 :
document.getElementById('subifrm').contentWindow.document.getElementById('test').style.color='red'
2. 利用jquery 来访问子窗口
$("#subifrm").contents().find("#test").css('color','red');
====================================================================
====================================================================
<2> 用DOM方法与jquery方法结合的方式实现互动操作
1.在父窗口中操作 选中IFRAME中的所有单选钮
$(window.frames["iframe1"].document).find("input[@type='radio']").attr("checked","true");
2.在IFRAME中操作 选中父窗口中的所有单选钮
$(window.parent.document).find("input[@type='radio']").attr("checked","true");
====================================================================
====================================================================
<3> 使用jquery操作iframe
1 页面里有两个ifame
<iframe id="leftiframe"></iframe>
<iframe id="mainiframe></iframe>
<iframe id="leftiframe"></iframe>
<iframe id="mainiframe></iframe>
leftiframe中jQuery改变mainiframe的src代码：
$("#mainframe",parent.document.body).attr("src","http://www.baidu.com")
2、 如果内容里面有一个ID为mainiframe的ifame
<iframe id="mainifame"></ifame>
<iframe id="mainifame"></ifame>
ifame包含一个someID
<div id="someID">you want to get this content</div>
<div id="someID">you want to get this content</div>
得到someID的内容
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
2 、如上面所示
leftiframe中的jQuery操作mainiframe的内容someID的内容
$("#mainframe",parent.document.body).contents().find("someID").html();或者 $("#mainframe",parent.document.body).contents().find("someID").val();
source:http://suan2046.javaeye.com/blog/575421
posted @
2011-03-07 14:14 [ 王志伟 ] 阅读(873) |
评论 (0) |
编辑 收藏
一、
1、数据库压力问题
所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端 (weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3 个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google 很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。
二、F5的负载均衡 是必不可少的，他的每秒点击量能达到将近30万，并且它有会话的粘性，只要是同一个ip发过来的请求，它就会把它分到同一台机器的，不用担心分发错误的。现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库
oracle是RAC群集。性能很好
三、tomcat为什么死掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。把缓存做好，减少动态查询
四、
1、F5的使用
F5不光可以做web的负载均衡，也可以做基于第4层的负载均衡。
比如：银行接口，大部分基于socket通讯的，就可以在前面架设一套F5设备，将请求分发到不同的服务器上。
大部分使用F5都是在web层次上，如果使用基于源IP地址的策略，有很多客户端都是基于代理服务器，这个时候源IP地址是一样的，其实并没有把这些用户给分发到不同的服务器上，建议采用基于cookie insert的方式，采用cookie的会话保持策略，loadbalance的算法，需要仔细的结合自己的应用的实际情况来设置。
2、大并发的问题
现在你得到了一个大概的系统能承受的并发，但是还达不到系统的设计目标。
应该从应用的角度去分析这个问题，web方面，通过工具(httplook)，检查一下客户端发起的请求都是什么响应状态，如果看到很多304请求状态，你需要优化你的url缓存，看一下每个url的耗费时间，仔细针对比较慢的进行调优；对于tomcat或者weblogic，在高并发的情况下，用kill -3 <PID>，获得ThreadDump(HeapDump需要特殊的设置)，看一下在高并发下，jvm的线程到底在干什么，仔细的分析可能对你有帮助。
如果在这些还没有改善的情况下，应当去想一想，硬件是否足够、配置是否合理等等系统级别的问题。
五、似乎在说瓶颈在于tomcat并发承载能力不够，但为什么tomcat只能承担单机200个并发？当并发急剧上升的时候，tomcat在执行动态请求的时候，瓶颈在哪里？是哪部分程序，或者哪个环节首先导致tomcat失去响应的？在davexin描述的刀片硬件上面，tomcat上面如果跑的仅仅是最简单的jsp页面，在采用BEA JRockit JVM的情况下，500个并发也可以达到。
我的推测是瓶颈还是出在EJB远程方法调用上！
tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。
如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。
另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。
六、tomcat之所以并发低很可能是由于remote session bean造成的，remote session bean又一次被滥用了，在楼主的这种业务情况下，web层和service层根本不需要分开，象楼主这样分开带来就是一访问业务层就带来长时间的远程请求，确实导致tomcat上servlet资源释放的问题。那么remote session bean应该被用在什么地方呢，without ejb上有写到金融系统常用ejb。我把他的这句话延伸一下，也就是说当业务的运行时间远超过远程调用的时间时，我们就可以用remote session bean来把这个业务分离出去。而楼主的系统中没有这种业务情况。所以使用remote session bean应该来说是一个错误的选择，不过这个错误的选择带来的危害被大量的硬件所掩盖，带来的是成本的提高。而性能上还不如slsb。
所以我觉得如果要改架构最便捷的方法是使用slsb，把remote session bean去掉。这样改造的成本比较低，如果换成spring+hibernate成本就高得多了。也就是说可以 struts+Bean+DAO+helper，然后把weblogic作cluster，任意一个node上都部署相同的应用。也就是水平扩展，理论上来讲当性能不满足要求时添加node就行了，如果能做成农场就更加方便了。当然即使非农场也没有关系，可以用现在在使用的stick分发。这样的改造之所以方便是因为把remote session bean改成slsb是很容易的，而且团队里的人估计对ejb都更加熟悉一点，成本会比较低一点
七、
近段时间正在做购买新硬件和新软件的预算，公司高层准备买weblogic10和oracle 10g，所以请了bea公司的人员和我一块做测试，经过近几天的测试，测试一下新的系统指标1万个并发，需要多少软件和多少硬件能够支撑，已经测试了不同的组合方式，有了不同的结果，分别如下：
1。1台weblogic10 能支持900个用户并发（没有用ejb），平均响应时间 10秒。
2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户，平均响应时间 9秒，由于本人使用的loadRunner最多支持1000个web并发，虽然此时weblogic没有任何错误，但是没办法再向上压用户，所以不知道最高能支撑多少个并发用户，很遗憾。
3。1台weblogic8， 能支持900个用户并发（没有用ejb），平均响应时间 11秒。但是没有weblogic10在同样时间内处理的交易数量多。可以判定性能不能weblogic10。
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。
5。1台tomcat6.14加1台weblogic8，还不如方案4，tomcat结超时更多，说明此种结构瓶颈在tomcat。由于还没有看tomcat6.14的调优资料。所以还请高手给建议。
6。1台tomcat4.1加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。
7。1台tomcat6.14加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。
明天还要做一个weblogic10 cluster测试，等有了测试结果，再根大家交流。
以上测试机器都为 linux as4 操作系统，2cpu + 2G内存，发现cpu利用率最高占45%，一般就在10%左右，内存可以用到1.5G。 loadRunner机器为2cpu + 2G内存，window server 2003操作系统。
有以上的结果，bea公司人员建议购买16-20cpu的licens。机器购买4cpu + 8G内存机器4-6台。前端tomcat增加到50台。
由于根据以前的宕机记录，主要表现在tomcat层，个别高峰时候也出现在F5。故不敢轻易的舍弃无状态session bean。由于tomcat做了大部分的业务，只有需要数据库的时候才调用weblogic中间件，由于weblogic的价格还是比较昂贵的，公司以前购买的weblogic licens数量限制。所以还不能把所有的tomcat换成weblogic。如果有20台weblogic的licens，我也就不担心1万个并发了。
八、
坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。阿里巴巴和淘宝网那是每天多少亿PV的电子商务网站了，其实也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本质上还是在用tomcat。
今年年初，RedHat在深圳的HW大客户在内部做过性能对比评测，JBoss4 vs WebLogic 9，在web容器一项的评测当中，JBoss4胜出。这个结果并不令人感到意外，因为web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。这一点你只要对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。
以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。
从你上面的发言来看，你们之所以采用EJB，无非是因为经费有限，无法购买充足的weblogic license。所以退而求其次，购买少量的weblogic license，专门跑业务层服务器，用SLSB暴露远程接口给tomcat调用。然后部署n十多台免费的tomcat服务器跑web。为省钱而采用 EJB到是一个很新鲜的事，但实际上这就是一个很愚蠢的决定。
weblogic的优秀更多的体现在他对于J2EE标准优秀的支持，各种复杂的企业应用场景以及传统的中间件应用的丰富而方便的集成手段上。简单的来说，就是weblogic/websphere是企业应用的首选，特别是强调事务的企业应用，例如金融，电信计费。但在互联网应用方面，weblogic/websphere根本就体现不出有什么能够超过resin/tomcat的地方，诚然weblogic express的web容器稳定性要好于tomcat，但没有互联网企业在大规模部署tomcat水平群集的时候，还会为这一点而疯狂买单购买 weblogic license。
所以我个人很不理解，作为一个互联网公司的CTO，怎么会如此迷信weblogic，因为我认识的互联网公司高层，没有什么人愿意用商业产品，绝大多数都是用开源的，我不惮揣测他的背景可能来自传统企业应用出身的吧，呵呵。
九、
这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：
1、你的tomcat没有配置好，严重影响了性能表现
2、tomcat和weblogic之间的接口出了问题
上面的帖子其实我也介绍过了，如果只是单纯的作为servlet容器来看，tomcat的性能不应该比weblogic差，甚至还要更好，所以你可以这样来拟定测试方案：
在同样硬件环境下对比测试tomcat5.5和weblogic10的servlet容器性能，分别写几个访问数据库，和不访问数据库的JSP页面测试就可以了，并发从500往上走，看看哪个throughput更高。记得要调优tomcat5.5，配置apr支持要打开。
如果测试结果表明tomcat并发响应能力远远差于weblogic，那就说明你的tomcat配置有很大的问题，好好钻研tomcat configuration && performance tuning吧；
如果测试结果表明tomcat并发响应能力与weblogic相当，或者差不多，那么很不幸，问题不在tomcat本身，而是出在了tomcat到 weblogic的接口上。而tomcat是通过weblogic提供的EJB client jar去调用weblogic的EJB的，那你只好咨询BEA去寻求解决方案了。
十、
1.基础配置优化
tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？
2.业务层优化
部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？
3.展示层优化
动态页面发布为静态页面？
Cache部分动态页面内容？
十一、
对于楼主的问题，以及公司的架构方案，我认为你们仍然在犯错！
误区：遇到性能问题的第一件事情就是找硬件和容器的事情!
性能问题的基本上无一例外的都出在写的程序有问题，满足不了伸缩性。
好好看看你们的程序吧，不要再给bea打电话了，你得到的建议，基本上都是用不到的。
robin的观点是对的，我甚至怀疑你们的数据库连接是否有释放问题的。
增加你们前端的内存，多做缓存。hibernate的cache方案不差jdbc对数据库的频繁使用
html的书写是否符合w3的规范
最好在一个服务器上部署整个应用！
十二、
淘宝用的weblogic8,他们的web层使用的Turbine，且大量的使用velocity，由于对事务要求及其苛刻用到了ejb,也用到 spring很多其他服务，访问数据库使用ibatis，他们对weblogic优化到的极致加上外面也架了apache,，在如此高并发的情况，且高度复杂的搜索。。。，还能保持如此的响应速度，确实很不错。
淘宝的搜索功能说是在的非常强大，不晓得是不是yahoo中国来人做的，一直觉得很神奇
robbin大哥说的还是很有道理，对于大多数门户门户网站，使用EJB确实浪费，购买weblogic的钱可以购买很多硬件来 apache,tomcat负载均衡远远胜过于ejb方案的性能。没有绝对的性能好坏之分，主要还是看你的需求，weblogic永远是对于银行，证券，电信的行业所准备，他们所使用的硬件对象也绝对不是刀片，双路至强的硬件这样的东东。
十三、
经过今天修改tomcat的参数，修改如下：
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" enableLookups="false" redirectPort="8443"
acceptCount="500" maxProcessors="500" minProcessors="500"
maxSpareProcessors="200"
connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。谢谢robbin的建议。
由于本人使用的loadRunner 能支持的独立client数量在100个，所以没办法对ejb进行单独的压力测试。因为我在对前段应用调用ejb时，最多并发用户已经达到1000个，但是通过监控weblogic10中发布的ejb应用和连接池，发现ejb应用等待数量为0，但是连接池中最多有60个活动连接，有7个连接在等待，因为此时设置的weblogic连接池最大数量是60，后来对连接池数量进行增大到160个，再次进行测试，发现性能反而不如把连接池数量调为60个的时候。问起bea的人，他们也说不清楚原因。
同时对他们所提供的一种更好的jvm进行测试，jvm的名字是 RealTime.发现性能并没有太大改善。
我们现在的系统已经作了很多的缓存，有全局的，有局部的，都是放到内存中的HashMap，静态的页面都是放在apache上的，不过没有使用 apr， 接下来如果有时间，会测试一下这个咚咚，。
che 前面是F5负载均衡器，在apache后面是tomcat，tomcat在公网上，然后通过内网网卡访问weblogic，weblogic才能访问数据库，tomcat不能直接访问数据库的，由于以前的网络结构的原因，也有安全的原因，公司还有部分服务器在北京（无线事业部）和广州（老系统，以后会逐渐迁移到上海），虽然现在也有其他的安全方案可以把tomcat放在内网，去掉weblogic，但是这种改变是需要时间的，也要考虑平稳过渡，所以还请各位理解。至于购买weblogic，公司也是有自己的考虑的。因为以前就是运行在weblogic上的，如果现在不用了，如果出了问题，就很难办了。
十四、是的，如果调整参数，可以达到并发人数达到1000以上，但是通过对比同样压力下的weblogic和tomcat，发现tomcat的响应时间都比weblogic长，并且tomcat的cpu的占用率达到45%-60%，而同样的压力下weblogic的cpu占用只有3%-5%。内存都是2G都用了97%，说明主要差别表现在cpu和相应时间上，我没有做tomcat 1000人并发测试，但是从以前600人并发的响应时间判断，我觉得响应时间可能会超过15秒。所以从综合各方面性能指标考虑，我觉得要找出一个响应时间，并发人数，完成交易数量3方面考虑折中，找出一个满足应用响应时间和并发用户的折中吧，如果是并发交易量比较大的应用，我想应该减少并发用户，提高单位时间内交易数量来满足应用需求吧。
十五、
又回到了realtime的定义，并不是很快的意思，而是响应时间是可预计的。
而JVM对响应时间可预计性的影响，主要表现在
1.线程调度受操作系统线程调度的影响
2.垃圾收集引起的暂停
所以jrockit选择了动态垃圾收集，以频繁的收集来换取每次中断时间的减少，所以，对吞吐量来说，是反而会下降的。大部分jvm都有吞吐量优先，短暂停时间两种截然不同的垃圾收集算法。
http://www.javaeye.com/topic/117564?page=1
posted @
2011-02-24 15:17 [ 王志伟 ] 阅读(211) |
评论 (0) |
编辑 收藏
转自：http://blog.csdn.net/fanwenqiang666/archive/2010/01/15/5188961.aspx
问题：
在Struts2中<jsp:forward page="xxx.action"></jsp:forward>失效了，不但调转不过去还报404错误。不知道是Struts2中不支持还是需要其他的配置。
原因：
因为struts2采用过滤器的方式处理请求，默认情况时监控url地址的变化
解决办法
1、配置web.xml 解决
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern >/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
2、用js近来做项目发现在Struts2中<jsp:forward page="xxx.action"></jsp:forward>失效了，不但调转不过去还报404错误。不知道是Struts2中不支持还是需要其他的配置。
解决
<script language="javascript">location.replace(URL)</script>
3、利用html meta
<meta http-equiv="refresh" content="0;URL=xxx.action">；
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fanwenqiang666/archive/2010/01/15/5188961.aspx
posted @
2010-12-20 09:53 [ 王志伟 ] 阅读(786) |
评论 (0) |
编辑 收藏