站点性能优化
A. 如何进行网站WEB性能优化
采用浏览器缓存；图片、JS的预载入；将脚本放在底部；精简JS；精简CSS；使用压缩组件等方法进行网站WEB性能优化
B. 如何进行网站的性能调优
1、首先服务器和域名DNS服务器都使用国内的，这个对速度肯定影响最大；
2、如回果使用了HTTPS，那么建议启答用HTTP2；
3、静态文件使用CDN；
4、低配云主机（VPS）性能一般比虚拟主机更低，所以根据自己情况可以考虑用虚拟主机；
5、优化前端代码，减少html节点数量；
还有比如dns-prefetch等等很多方式，都有一定好处，没办法一一列举了。
C. 如何进行网站性能优化
内容页面优化就一个要点：你的访客要看到什么内容你就做什么内容。建议你以一个访客的角度来看你自己的网站，内容是否完善、页面是否好看、框架是否清晰……做好这些就算是内容优化了。
D. 什么是网站性能优化技术
一、提高服务器并发处理能力
我们总是希望一台服务器在单位时间内能处理的请求越多越好，这也成了web服务器的能力高低的关键所在。服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计，使得多个任务可以轮流使用系统资源，这些资源包括CPU、内存以及I/O等。这就需要选择一个合适的并发策略来合理利用这些资源，从而提高服务器的并发处理能力。这些并发策略更多的应用在apache、nginx、lighttpd等底层web server软件中。
二、Web组件分离
这里所说的web组件是指web服务器提供的所有基于URL访问的资源，包括动态内容，静态网页，图片，样式表，脚本，视频等等。这些资源在文件大小，文件数量，内容更新频率，预计并发用户数，是否需要脚本解释器等方面有着很大的差异，对不同特性资源采用能充分发挥其潜力的优化策略，能极大的提高web站点的性能。例如：将图片部署在独立的服务器上并为其分配独立的新域名，对静态网页使用epoll模型可以在大并发数情况下吞吐率保持稳定。
三、数据库性能优化和扩展。
Web服务器软件在数据库方面做的优化主要是减少访问数据库的次数，具体做法就是使用各种缓存方法。也可以从数据库本身入手提高其查询性能，这涉及到数据库性能优化方面的知识本文不作讨论。另外也可以通过主从复制，读写分离，使用反向代理，写操作分离等方式来扩展数据库规模，提升数据库服务能力。
四、Web负载均衡及相关技术
负载均衡是web站点规模水平扩展的一种手段，实现负载均衡的方法有好几种包括基于HTTP重定向的负载均衡，DNS负载均衡，反向代理负载均衡，四层负载均衡等等。
对这些负载均衡方法做简单的介绍：基于HTTP重定向的负载均衡利用了HTTP重定向的请求转移和自动跳转功能来实现负载均衡，我们熟悉的镜像下载就使用这种负载均衡。DNS负载均衡是指在一个DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时返回不同的解析结果将客户端的访问引到不同的机器上，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。反向代理负载均衡也叫七层负载均衡，这是因为反向代理服务器工作在TCP七层结构的第七层(应用层)，它通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。四层负载均衡是基于NAT技术的负载均衡，它将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次TCP连接请求动态使用其中一个内部IP地址，达到负载均衡的目的。此外，还有工作在数据链路层(第二层)的直接路由方式下的负载均衡，它通过修改数据包目标MAC地址来实现。以及，基于IP隧道的负载均衡，在这种方式下可以将实际服务器根据需要部署在不同的地域，并根据就近访问的原则来转移请求，CDN服务便是基于IP隧道技术来实现的。
Web负载均衡在扩展web服务器规模的同时也给web站点性能优化提供了一个更大更复杂也更灵活自由的平台，基于该平台性能优化的策略包括共享文件系统，内容分发与同步，分布式文件系统，分布式计算，分布式缓存等等。
五、web缓存技术
web缓存技术被认为是减轻服务器负载、降低网络拥塞、增强万维网可扩展性的有效途径，其基本思想是利用客户访问的时间局部性(Temporal Locality)原理，将客户访问过的内容在Cache中存放一个副本，当该内容下次被访问时，不必连接到驻留网站或重新计算生成，而是由Cache中保留的副本提供。Web缓存可以带来如下的好处：
(1) 减少网络流量，从而减轻网络拥塞;这是因为缓存避免了一部分HTTP请求。
(2) 降低客户访问延迟，其主要原因有：①已缓存的内容，客户可以缓存获取而不是从服务器获取或重新计算生成，从而减小了传输延迟缩短了响应时间;②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取;
(3) 由于客户的部分或者全部请求内容可以从通过缓存获取，从而减轻了远程服务器负载。
(4) 如果由于服务器故障或网络故障造成服务器无法响应客户请求，客户可以从缓存中获取缓存的内容副本，使得web站点服务的鲁棒性(Robustness)得到了加强。
可以看出web缓存能给web站点带可观的性能提升。其实在用户发出请求到一幅完整的网页呈现在用户面前这一过程中缓存无处不在，下面是web性能优化时常用的缓存技术，你会发现缓存被广泛应用在各个环节。
浏览器缓存：浏览器一般会在用户文件系统中创建一个目录，用于存放缓存文件，并给每个缓存文件打上必要的标记，比如过期时间等。这些标记主要用于浏览器和服务器之间的缓存协商。
Web服务器缓存：一个URL在一段较长时间内对应一个唯一的响应内容，比如静态内容或者更新不太频繁的动态内容，web服务器可将响应内容缓存起来，下次web服务器便可以在收到请求后立即拿出事先缓存好的响应内容并返回给浏览器。
代理服务器缓存：暴露在互联网中与后端的web服务器通过内部网络相连的前端服务器称为反向代理服务器，建立在反向代理服务器上的缓存称为反向代理缓存。暴露在互联网中与后端的web客户端通过内部网络相连的前端服务器称为正向代理服务器，建立在正向代理服务器上的缓存称为正向代理缓存。代理服务器缓存位于客户端和web服务器之间，可以将它看做二者之间的一个中继站。它的存在可以改善客户端的访问速度、提升web server的服务能力、安全性等等。
总共分析总结了五种技术，主要希望能够对web server性能优化这块提供一个整体的认识。后续会专门就web缓存技术发表一些自己的看法。
E. 高性能Web站点的优化招数
1.这里的吞吐率特指Web服务器单位时间内处理的请求。
2.压力测试的前提：1>并发用户数 2>总请求数 3>请求资源描述
3.用户平均请求等待时间主要用户衡量服务器在一定并发用户数的情况下，对于单个用户的服务器质量；而服务器平均请求处理时间与前者相比，则用于衡量服务器的整体服务质量，它其实就是吞吐率的倒数。
4.对http header中标记为Connection: Keep-Alive的请求，开启web服务器的长连接支持。减少系统调用accept的次数，即减少建立连接的开销。
5.老调重弹，进程，内核级线程和用户级线程在不同情况下的优劣。IO模型，mmap（内村映射），直接IO，例如sendfile syscall以及异步IO等。多路IO复用（select， poll，epoll and kqueue etc）
6.服务器并发策略
1> 一个进程处理一个连接，非阻塞IO。稳定性强，但context switch的开销随http request递增而快速增长。
2> 一个内核级线程处理一个连接，非阻塞IO，多进程多线程混合方式。Context switch的问题依然存在。理论上可以支持更多的并发连接。
3>一个进程处理多个连接，非阻塞IO。（epoll， kqueue）lighttpd, nginx。支持并发性能强劲。 上述情况的适用范围不能一刀切，而且这里都是指单机并发，需根据实际情况（实际并发数）来选择。通常，在并发用户数较大的情况下，Web服务器使用什么样的并发策略，是影响最大并发数的关键。 在实际应用中，动态内容缓存可能是使用得最多的技术，但是并不见得所有的动态内容都适合使用网页缓存，缓存带来的性能提升恰恰与有些动态数据实时交互的需求形成矛盾，这就是一个权衡。
1. 缓存动态生成的html代码。
2. 把动态内容静态化，直接缓存整个html文件。这样就可以直接访问缓存。这时的更新策略：
1>在数据更新时重新生成静态化内容 2>定时重新生成静态化内容
3. 使用SSI（server side include）进行局部静态化。但web server的SSI功能会对静态文件的吞吐率有负面影响。 减少http请求，充分利用浏览器的缓存。而webapp通过http协议（更具体位置就是http header）来与浏览器协商，那些东东浏览器可以使用其缓存即可。
1. Last-Modified/If-Modified-Since
2. ETag/If-None-Match
3.Expires + Cache-Control: max-age=<seconds>
1和2需要浏览器和webserver交互后，有服务器端通知浏览器是否使用浏览器缓存，而3则是在过期前直接使用浏览器缓存，这样就直接kill掉了http request。同时还需注意，在使用SSI的内容中，由于整个页面是服务器动态生成的，所以Last-Modified标记在不同的Web服务器中有不同的生成方法。 Web服务器隐藏在代理服务器之后。这种代理机制称为反向代理（Reverse proxy），同时，实现这种机制的服务器便成为反向代理服务器。隐藏在反向代理服务器之后的Web服务器，我们习惯称它为后端服务器（Back-end server），当然，反向代理服务器就被称为前端服务器(Front-end server)。
引入反向代理服务器的目的之一就是基于缓存的加速。我们可以将内容缓存在反向代理服务器上，所有缓存机制的实现仍然采用HTTP/1.1协议。
缓存命中率和后端吞吐率的理想技术模型
缓存丢失率=（活跃内容数/（实际吞吐率×平均缓存有效期））×100%
缓存命中率= 1-缓存丢失率 后端吞吐率= 活跃内容数/平均缓存有效期
缓存命中率= （1-（后端吞吐率/实际吞吐率））×100%
后端吞吐率 = （1 – 缓存命中率）×实际吞吐率
结论： 1. 活跃内容数和平均缓存有效期一定的情况下，缓存命中率与实际吞吐率成正比。
2. 实际吞吐率和平均缓存有效期一定的情况下，缓存命中率与活跃内容数成反比。
3. 活跃内容数和实际吞吐率一定的情况下，缓存命中率与平均缓存有效期成正比。
4. 活跃内容数一定的情况下，后端吞吐率与平均缓存有效期成反比。
5. 平均缓存有效期一定的情况下，后端吞吐率与活跃内容数成正比。
6. 缓存命中率的变化不一定会影响后端吞吐率。
7. 后端吞吐率的变化不一定会影响缓存命中率。
ESI – Edge Side Include类似与SSI，但不在webserver端组装内容，而是在http代理服务器上组装内容，包括反向代理。在处理只有局部更新动态内容时AJAX是更好的原则，它不依赖与底层webserver的实现，但ESI的优势在于再有多个后端服务器的情况下，变可以避免多个后端的重复组装，减少总工作量。 从以下几个方面来看Web组件的差异：
1. 文件大小
2. 文件数量
3. 内容更新频率
4. 预计并发用户数
5. 是否需要脚本解释器
6. 是否涉及大量CPU计算
7. 是否访问数据库
8. 访问数据库的主要操作是读还是写
9. 是否包含RPC
对每种类型的Web组件采取不同的优化方式（一种或多种）：
1. 是否使用epoll模型
2. 是否使用sendfile() syscall
3. 是否使用异步IO
4. 是否支持HTTP持久连接（http keep-alive）
5. 是否需要opcode缓存
6. 是否使用动态内容缓存以及有效期为多长
7. 是否使用Web服务器缓存以及有效期为多长
8. 是否使用浏览器缓存以及有效期为多长
9. 是否使用反向代理缓存以及有效期为多长
10. 是否使用负载均衡策略
按照Web组件的不同类型将其放在不同的二级域名/机器/不同类型的WebServer
同时，还需考虑到不同的浏览器对同一个域名下的访问有多大并发数限制，而使用多个域名。
IE6，7 2(http/1.1)
IE8 6(http/1.1)
Firefox2 2(http/1.1)
Firefox3 6(http/1.1)
发挥各自的潜力
对于动态内容：开启opcode缓存，使用足够快的CPU，足够大的内存，多进程以及与数据库保持高速连接
对于静态内容：支持epoll，非阻塞IO，异步IO，使用sendfile，单进程（对于IO密集型任务，多进程无法发挥优势），使用高速磁盘，使用RAID
对于image, css and script分配合理设置其过期时间(expires) 1.合理的执行计划，包括合理使用索引
2.使用慢查询分析工具，找出执行很慢的sql并优化之。
3.合理的数据库缓存，索引缓存，数据缓存等
4.更具实际需求选择合理的数据库引擎或数据库
5.反范式化设计，对查询带来优化，但增加写和更新的工作量。
6.放弃关系型数据库，针对实际情况，读写要求极高时 数据库扩展： 读写分离，按业务实施合理的垂直分区，对热点表进行水平分区。 DNS负载均衡
需要DNS服务商提供该功能，且DNS记录存在缓存，无法及时修改，带来更新延迟。
反向代理负载均衡
HTTP重定向和DNS解析在请求的调度上体现在“转发”上，而其则体现在“转移”。
任何对于实际服务器的http请求都必须经过调度器；调度器必须等待实际服务器的http响应，并将它反馈给用户。
由于调度策略在自己手中，就可以使用诸如按照权重进行调度等策略。也可以对个应用服务器进行健康监控，对无效服务器不在把请求转移给它；还可以实现sticky sessions。
作为负载均衡调度器的反向代理服务器在扩展上的制约，反向代理服务器的处理能力制约了整个集群的处理能力，其次，容易出现单点故障
IP负载均衡
Netfilter+ IPVS
用iptables修改Netfilter规则，进行基于IP的tcp包转发，也即调度。 IPVS（IP Virtual Server）也成为LVS(Linux Virtual Server)。
两者结合的具体策略有 1. LVS + NAT
2. LVS + DR
F. 网站性能优化怎么办
一、前端优化
网站性能优化是一个很综合的话题，涉及到服务器的配置和网站前后端程序等各个方面，我只是从实际经历出发，分享一下自己所尝试过的网站性能优化方法。之所以在标题上挂一个web2.0，是因为本文更偏重于中小网站的性能优化，我所使用的系统也是典型web2.0的LAMP架构。
首先讲讲前端的优化，用户访问网页的等待时间，有80%是发生在浏览器前端，特别是页面和页面中各种元素（图片、CSS、javascript、 flash…）的下载之上。因此在很多情况下，相对于把大量的时间花在艰苦而繁杂的程序改进上，前端的优化往往能起到事半功倍的作用。雅虎最近将内部使用的性能测试工具yslow向第三方公开，并发布了著名的网站性能优化的十三条规则，建议你下载并安装yslow，并作为测评网站优化效果的工具。下面我挑其中特别有价值的具体说明一下优化的方法：
对于第一次访问您网站，尚未在浏览器cache中缓存您网站内容的用户，我们可以做的事情包括：
1）减少一个页面访问所产生的http连接次数
对于第一次访问你网站的用户，页面所产生的http连接次数是影响性能的一个关键瓶颈。
对策：
- 尽量简洁的页面设计，最大程度减少图片的使用，通过放弃一些不必要的页面特效来减少javascript的使用。
- 使用一些优化技巧，比如利用图片的背景位移减少图片的个数；image map技术；使用Inline images将css图片捆绑到网页中。
- 尽量合并js和css文件，减少独立文件个数。
2) 使用gzip压缩网页内容
使用gzip来压缩网页中的静态内容，能够显著减少用户访问网页时的等待时间（据说可达到60%）。主流的web服务器都支持或提供gzip压缩，如果使用apache服务器，只需要在配置文件中开启 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是静态的页面，使用gzip压缩都能够显著提高服务器效率并减少带宽支出，注意图片内容本身已经是压缩格式了，务必不要再进行压缩。
3）将CSS放在页面顶端，JS文件放在页面底端
CSS的引用要放在html的头部header中，JS文件引用尽量放在页面底端标签的后面，主要的思路是让核心的页面内容尽早显示出来。不过要注意，一些大量使用js的页面，可能有一些js文件放在底端会引起一些难以预料的问题，根据实际情况适当运用即可。
4）使JS文件内容最小化
具体来说就是使用一些javascript压缩工具对js脚本进行压缩，去除其中的空白字符、注释，最小化变量名等。在使用gzip压缩的基础上，对js内容的压缩能够将性能再提高5%。
5）尽量减少外部脚本的使用，减少DNS查询时间
不要在网页中引用太多的外部脚本，首先，一次dns的解析过程会消耗20-120毫秒的时间；其次，如果在页面中引用太多的外部文件（如各种广告、联盟等代码），可能会因为外部文件的响应速度而将你的网站拖得很慢。如果不得不用，那么就尽量将这些脚本放在页脚吧。不过有一点需要提及，就是浏览器一般只能并行处理同一域名下的两个请求，而对于不同子的域名则不受此限制，因此适当将本站静态内容（css,js）放在其他的子域名下（如 static.xxx.com）会有利于提高浏览器并行下载网页内容的能力。
对于您网站的经常性访问用户，主要的优化思路就是最大限度利用用户浏览器的cache来减少服务器的开销。
1）在header中添加过期时间(Expires Header)
在header中给静态内容添加一个较长的过期时间，这样可以使用户今后访问只读取缓存中的文件，而不会与服务器产生任何的交互。不过这样做也存在一些问题，当图片、CSS和js文件更新时，用户如果不刷新浏览器，就无法获得此更新。这样，我们在对图片、css和js文件修改时，必须要进行重命名，才能保证用户访问到最新的内容。这可能会给开发造成不小的麻烦，因为这些文件可能被站点中的许多文件所引用。flickr提出的解决办法是通过url rewrite使不同版本号的URL事实上指向同一个文件，这是一个聪明的办法，因为url级别的操作效率是很高的，可以给开发过程提供不少便利。
要理解为什么这样做，必须要了解浏览器访问url时的工作机制：
a. 第一次访问url时，用户从服务器段获取页面内容，并把相关的文件（images,css,js…）放在高速缓存中，也会把文件头中的expired time,last modified, ETags等相关信息也一同保留下来。
b. 用户重复访问url时，浏览器首先看高速缓存中是否有本站同名的文件，如果有，则检查文件的过期时间；如果尚未过期，则直接从缓存中读取文件，不再访问服务器。
c. 如果缓存中文件的过期时间不存在或已超出，则浏览器会访问服务器获取文件的头信息，检查last modifed和ETags等信息，如果发现本地缓存中的文件在上次访问后没被修改，则使用本地缓存中的文件；如果修改过，则从服务器上获取最新版本。
我的经验，如果可能，尽量遵循此原则给静态文件添加过期时间，这样可以大幅度减少用户对服务器资源的重复访问。
2）将css和js文件放在独立外部文件中引用
将css和js文件放在独立文件中，这样它们会被单独缓存起来，在访问其他页面时可以从浏览器的高速缓存中直接读取。一些网站的首页可能是例外的，这些首页的自身浏览可能并不大，但却是用户访问网站的第一印象以及导向到其他页面的起点，也可能这些页面本身使用了大量的ajax局部刷新及技术，这时可以将 css和js文件直接写在页面中。
3）去掉重复的脚本
在IE中，包含重复的js脚本会导致浏览器的缓存不被使用，仔细检查一下你的程序，去掉重复引用的脚本应该不是一件很难的事情。
4）避免重定向的发生
除了在header中人为的重定向之外，网页重定向常在不经意间发生，被重定向的内容将不会使用浏览器的缓存。比如用户在访问www.xxx.com，服务器会通过301转向到www.xxx.com/，在后面加了一个“/”。如果服务器的配置不好，这也会给服务器带来额外的负担。通过配置apache的 alias或使用mod_rewrite模块等方法，可以避免不必要的重定向。
还有一些，比如使用CDN分发机制、避免CSS表达式等、避免使用ETags等，因为不太常用，这里就不再赘述了。
做完了上述的优化，可以试着用yslow测试一下网页的性能评分，一般都可以达到70分以上了。
当然，除了浏览器前端和静态内容的优化之外，还有针对程序脚本、服务器、数据库、负载的优化，这些更深层次的优化方法对技术有更高的要求。本文的后半部分将重点探讨后端的优化。
二、后端优化
上次写完web2.0网站前端优化篇之后，一直想写写后端优化的方法，今天终于有时间将思路整理了出来。
前端优化可以避免我们造成无谓的服务器和带宽资源浪费，但随着网站访问量的增加，仅靠前端优化已经不能解决所有问题了，后端软件处理并行请求的能力、程序运 行的效率、硬件性能以及系统的可扩展性，将成为影响网站性能和稳定的关键瓶颈所在。优化系统和程序的性能可以从以下的方面来入手：
1）apache、mysql等软件的配置的优化
尽管apache和mysql等软件在安装后使用的默认设置足以使你的网站运行起来，但是通过调整mysql和apache的一些系统参数，还是可以追求更高的效率和稳定性。这个领域中有很多专业的文章和论坛（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要进行深入的研究和实践，这里就不重点讨论了。
2）应用程序环境加速
这里仅以我最常应用的php开发环境为例，有一些工具软件可以通过优化PHP运行环境来达到提速的目的，其基本原理大致是将PHP代码预编译并缓存起来，而不需要改变任何代码，所以比较简单，可以将php的运行效率提升50%以上。比较常用的免费php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，还有收费的Zend Performance Suite
3）将静态内容和动态内容分开处理
apache是一个功能完善但比较庞大的web server，它的资源占用基本上和同时运行的进程数呈正比，对服务器内存的消耗比较大，处理并行任务的效率也一般。在一些情况下，我们可以用比较轻量级的web server来host静态的图片、样式表和javascript文件，这样可以大大提升静态文件的处理速度，还可以减少对内存占用。我使用的web server是来自俄罗斯的nginx，其他选择方案还包括lighttpd和thttpd等。
4）基于反向代理的前端访问负载均衡
当一台前端服务器不足以应付用户访问时，通过前端机实现web访问的负载均衡是最快速可行的方案。通过apache的mod_proxy可以实现基于反向代理的负载均衡，这里推荐使用nginx做代理服务器，处理速度较apache更快一些。
5）应用缓存技术提高数据库效能，文件缓存和分布式缓存
数据库访问处理并发访问的能力是很多网站应用的关键瓶颈，在想到使用主从结构和多farm的方式构建服务器集群之前，首先应该确保充分使用了数据库查询的缓存。一些数据库类型（如mysql的innoDB）自身内置对缓存的支持，此外，还可以利用程序方法将常用的查询通过文件或内存缓存起来。比如通过 php中的ob_start和文件读写函数可以很方便的实现文件形式的缓存，而如果你拥有多台服务器，可以通过memcache技术通过分布式共享内存来对数据库查询进行缓存，不仅效率高而且扩展性好，memcache技术在livejournal和Craigslist.org等知名网站应用中都得到了检验。
6）服务器运行状态的检测，找到影响性能的瓶颈所在
系统优化没有一劳永逸的方法，需要通过检测服务器的运行状态来及时发现影响性能的瓶颈，以及可能存在的潜在问题，因为网站的性能，永远取决于木桶中的短板。可以编写一些脚本来检测web服务的运行，也有一些开源的软件也提供了很好的功能
7）良好的扩展架构是稳定和性能的基础
一些技巧和窍门可以帮你度过眼前的难关，但要想使网站具备应付大规模访问的能力，则需要从系统架构上进行彻底的规划，好在很多前人无私的把他们架构
网站的经验分享给我们，使我们可以少走甚多弯路。我最近读到的两篇有启发的文章：
- 从LiveJournal后台发展看大规模网站性能优化方法
- Myspace的六次重构
最后不得不提到程序编码和数据库结构对性能的影响，一系列糟糕的循环语句，一个不合理的查询语句、一张设计不佳的数据表或索引表，都足以会使应用程序运行的速度成倍的降低。培养全局思考的能力，养成良好的编程习惯，并对数据库运行机制有所了解，是提高编程质量的基础。
G. 如何优化Web网站性能
这个问题不难!是抄优化网站性能，不是提高用户体验，那么能增加资金预算的话，硬件方面提高配置，比如用更快的CPU，加大内存，使用高速硬盘，增加带宽等等。
软件方面，对程序代码和数据库进行优化，网站页面生成静态页，减少对数据库和服务器的压力，使用存储过程等等。
H. 如何对网站进行性能优化
一、删除功能：重要数据伪删除，删除校验用户（避免A用户可以删除任何人数据）。文件上传预览删除功能不能做服务器文件删除，不要为了节省服务器资源给用户留下接口。如果要资源有限，那么在删除的时候也需要做用户校验（文件命名或文件路径关联用户ID等）
二、发短信:基本上没有人愿意自己和短信运营商直接对接短信业务，一般都是通过第三方短信服务商购买短信。在用户主动获取短信的时候前端做图片验证码校验，后端做发送量，发送间隔校验（图片验证码是可以被机识别的）。做短信日志记录，这些日志可以为前面的后台校验提供数据，系统运行期间的各种好处就不一一举例了。重要功能做语音验证码，比如注册送现金的活动，短信验证码可以被识别
三、页面数据获取：用户平凡的刷新数据会加大服务器压力，当然谁也挡不住用户刷新是吧，但是减少主动刷新次数也是一个减小服务器压力的方法，咱不能自己坑自己吧，(Table页切换做校验，有数据就不再拉取等等)
四、前端静态资源做CDN，可以提高用户访问速度，减少服务器压力
五、用户输入做SQL注入，javascript脚本注入
六、用到的Ajax请求：做ajax加拦截器，通过消息头过滤掉非ajax的地址栏访问，（谁然不一定能全部拦截，但是拦掉一部分小白还是可以得，总不能是个人就能攻击吧）
七、用户输入数据校验，输入文字长度，数字输入大小，int 、long等数据类型合理使用，(积分兑换的时候用户只有1积分，你让他输入兑换积分，你输入21000000000，int 接收的时候，超出了范围成了负数1永远大于负数)，还有一点很重要，你的任何校验都不要依靠前端，毕竟前端是为用户的体验而生的，为了自己的安全还是多写点后台校验吧，
八、异常捕获：不要将异常信息抛给用户，首先不美观，其次这些错误信息中可能含有SQL错误，通过这些sql可以了解到你的数据库结构
九、前端数据获取的时候减少不必要字段输出，java面向对象，表数据面向对象，本来页面只需要两个数据，结果你返回了一个实体，前端可已查看到你数据库表结构，多看几个页面那么你的数据库设计就给了人家了呢
十、用户信息加密传输，一定不要把重要数据留在客户端，泄密重要信息的责任是要你承担的哦
十一、 现在越来越多人使用阿里云服务器，做客户项目的时候服务器是客户购买的，当然阿里云账户客户也有，你的配置文件不加密客户就能看见你的系统配置，结合上面的搞搞你的数据库，那你的产品还有什么秘密，至于代码，你觉得他值钱么
十二、 前端JS 脚本 和页面分离，压缩或加密，不要你的团队幸幸苦苦开发的唯美的页面和效果，被人家一个ctrl+s拿去回家研究了，何况你的js中还有大量的逻辑
十三、 线程安全:
1、synchronized同步 （有序性、可见性），
2、使用生产者消费者模式，(唤醒notify()，等待wait())
3、volatile同步（可见性，非有序性，只在无基础数据的赋值操作，直接操作主内存，减少主内存复制到工作内存的cpu消耗）
十四、 数据库读写分离的时候要注意个别业务读也要读在主库上（避免主从同步失败或延时）
I. 什么是网站性能优化，为什么要优化
网络搜索一个问题时有至少都有几十万条数据，如果不做优化，都没人会看到你的网站，你说这种情况下网站能带来什么效益呢?
J. 网站性能优化
这个要看你网站的主题还有你的目的啊，才能对症下药，是吧，不能直接根据域名判断吧。优化建议，推荐到www.jqqnet.com，看看，希望能帮点忙给你