提升nfd服务器的读性能

㈠ 如何优化RAID控制器提升存储性能

许多参数都与缓存和缓存利用率，以及众所周知的RAID
关于RAID级别与性能有关的文章已经很多，这里就不再重复了，主要谈一下RAID的调优，如果你想通过配置RAID优化存储性能，不管是安装在PC服务器上的RAID控制器，还是高端企业级存储阵列，阅读本文之后，你将有清晰的方向。
首先我们来看看RAID控制器的种类，目前我们常见的有以下三种：
1、企业级“Active/Active”：这种控制器允许你从任何主机向任何LUN写入数据，不会造成性能下降，它通常具备很大的镜像缓存(一般会超过32GB)，这种控制器支持热插播硬盘，正常运行时间很长，现在与控制器通信一般是走光纤通道(FC)或以太网光纤通道(FCoE)。
2、中端“主动/被动”：这种控制器对于每个LUN来说都有两个侧面，一个主动侧面，它是主要路径，一个被动侧面，用于故障转移，你通常需要在主要和故障转移侧之间分割LUN，平均划分你的系统，缓存可以在控制器上镜像，但这种控制器的弹性没有企业级控制器好。
3、RAID主机卡：这种卡插入到PCIe插槽，通过SAS或SATA数据线连接到硬盘，它没有独立的处理器，而企业级和中端控制器都有，它们支持的硬盘数量也没有前两种控制器多，此外，要想故障转移到另一个控制器也是不可能的，你系统的弹性完全取决于你的PCIe插槽和控制器卡。
RAID缓存调整和配置
可以从三个方面调整RAID缓存：
调整缓存，读优先，写在后。
调整缓存块大小。
调整缓存镜像(对于中端控制器来说特别重要)。
读优先，写在后：你可能会认为这样调整后不会产生实质性效果，但事实证明不是你想象的那样，如果读优先，它会认为数据是连续的，这样可以为数据分配连续的地址空间，RAID控制器不知道文件系统或数据的拓扑结构，它只知道连续块地址。如果你的文件系统分配单元小于RAID条带尺寸，如果同时有多个文件写入，这些文件将会在这些RAID条带上变成碎片。
例如，如果文件系统分配尺寸是64KB，RAID 5
8+1条带大小是512KB，同时有多个文件写入，RAID控制器做得最多的事情就是读取你请求的数据，在这里是64KB，也可能是另一个64KB，如果你连续读，直到读完整个条带，这就是读优先，另一方面，如果你只读一个64KB的块，条带中剩余部分的数据来自其它文件，那么读优先只有害处，只有RAID条带大小和文件系统分配单元相匹配时，实施读优先才会获得很好的性能。
写在后：将块读入缓存以便写入内容，当数据命中缓存时向写入程序发送一个响应，这里的关键是数据在RAID条带上必须是对齐的，如果没有对齐，RAID必须完成“读-修改-写入”(读入条带数据，修改成新数据，再写入条带)，这样的后果是开销大，延迟严重，RAID缓存的目的本来就是为了隐藏写入磁盘的延迟，当数据命中缓存时接收确认。调整写在后通常需要针对读优先指定需要分配多少缓存空间，此外还需要指定可读或写的最小缓存块大小。
调整RAID缓存块大小
缓存块大小是可以读入缓存的最小数据量，例如，在一块磁盘上的一个RAID分配单元可能是32KB，你可能会认为该磁盘的所有I/O单元都是32KB，但如果缓存块大小是4KB，那对该磁盘的最小读或写大小应该是4KB，而不是32KB，它是今天磁盘扇区大小的8倍，如果你的文件系统分配单元很大，你的写入请求也很大，但缓存块大小很小，就可能会降低RAID的性能。
我所见过的大多数RAID控制器都是这样，缓存块越小速度越慢，因为它们没有足够的处理器能力管理所有的块，也许等下一代控制器上市会改变这一现状(因为处理性能将会提升)。只有在RAID分配单元中数据处于非对齐状态时，缓存块小一点更好。
想象一下以小的请求写，大的请求读，文件系统分配单元和条带大小匹配时会是什么状况，发生多个连续写操作时，文件系统不会产生严重的碎片，并且读优先将会起作用，如果读比写更大，读优先也有帮助，所有RAID控制器会认为读是连续的，因此在调整读操作时，你需要知道读和写请求大小，并确定同一时间有多少文件写入，如果同一时间只有一个文件写入，数据将很可能是连续分配的，直到文件系统产生碎片，读优先将会带来很大的好处。
另一方面，如果有多个文件写入，并且写入大小和文件系统分配单元比条带尺寸小，这时读优先的作用就很小，甚至毫无作用。归结起来就是：读优先适用于写和分配单元相等，或者当有多个文件写入时，大于RAID的条带尺寸。
调整缓存镜像
在许多中端RAID产品中，写缓存镜像是一个常见的功能，所有写入内容全部镜像到RAID控制器中，控制器处理I/O请求，将其写入控制器的另一半缓存中，如果数据在条带上是完全对齐的，有些厂商在控制器上使用一些技术绕过缓存写入请求，但在普通环境中是具有写缓存镜像的，每一次写操作都要写入到缓存，在向I/O请求发出确认前再写入到另一个缓存，写缓存镜像因此通常会降低性能，因为写入其它缓存存在延迟，并会占用一定的带宽，每个缓存必须镜像到其它缓存，因此缓存空间利用率会下降一半。
如果厂商提供了读或写缓存调整参数，可以根据负载和可靠性考虑进行微调。我经常听到的一个问题是用户到底应不应该使用写缓存镜像，这要根据你对数据可靠性的需要而定。假设你正在写一个文件，将数据写入一个没有写缓存镜像系统的缓存，如果这个时候整个控制器出现故障(从缓存到磁盘)，你的应用程序会被告知写入成功，但数据却没有来得及写入磁盘。虽然这种事故发生的几率非常小，但仍然是可能发生的，我就有幸见过一次。
如果你对同一个文件再执行一个写入操作，你可能会遭遇I/O错误，大多数RAID这个时候会意识到它们不能从缓存写入到磁盘，因此会暴露错误，有的RAID控制器会故障转移到可以工作的一侧，你的操作得以成功完成，但实际上已经有一个文件已经丢失了，但你的应用程序却不知道，如果文件少写入了内容，这可能会引发后续一系列的连锁反应，这也是为什么写缓存镜像默认启用的原因。调整写缓存镜像需要指定为写入操作保留多少缓存空间，写缓存镜像开关应该开启，如果控制器损坏，想要找出损坏的数据或缺少的数据几乎是不可能的。
其实只要掌握一点RAID控制器的常识，调整它就不难了。我们需要记住的是，如果同时有多个文件写入，文件系统分配单元很小时，读优先是没有用的，最糟糕的一个例子就是Windows上的NTFS。

㈡ 服务器性能不足怎么办

升级服务器 或者减少程序代码的运行

㈢ 怎样提高IIS服务器性能，加快服务器速度

1、应该分配和释放多个对象

你应该尽量避免过量分配内存，因为内存分配可能是代价高昂的。释放内存块可能更昂贵，因为大多数分配算符总是企图连接临近的已释放的内存块成为更大的块。直到Windows NT? 4.0 service pack 4.0，在多线程处理中，系统堆通常都运行得很糟。堆被一个全局锁保护，并且在多处理器系统上是不可扩展的。

2.不应该考虑使用处理器高速缓存

大多数人都知道由虚拟内存子系统导致的hard 页错误代价很高，最好避免。但是许多人认为其他内存访问方法没有什么区别。自从80486以后，这一观点就不对了。现代的CPUs比RAM要快得多，RAM至少需要两级内存缓存 ，高速L1 缓存能保存8KB数据和8KB指令，而较慢的L2 缓存能保存几百KB的数据和代码，这些数据和代码混合在一起。L1 缓存中内存区域的一个引用需要一个时钟周期，L2 缓存的引用需要4到7个时钟周期，而主内存的引用需要许多个处理器时钟周期。后一数字不久将会超过100个时钟周期。在许多方面，缓存像一个小型的，高速的，虚拟内存系统。

至于和缓存有关的基本内存单元不是字节而是缓存列。Pentium 缓存列有32个字节宽。Alpha 缓存列有64个字节宽。这意味着在L1 缓存中只有512个slot给代码和数据。如果多个数据一起使用（时间位置）而并不存储在一起（空间位置），性能会很差。数组的空间位置很好，而相互连接的列表和其他基于指针的数据结构的位置往往很差。

把数据打包到同一个缓存列中通常会有利于提高性能，但是它也会破坏多处理器系统的性能。内存子系统很难协调处理器间的缓存。如果一个被所有处理器使用的只读数据，和一个由一个处理器使用并频繁更新的数据共享一个缓存 列，那么缓存将会花费很长时间更新这个缓存列的拷贝。这个Ping-Pong高速游戏通常被称为"缓存 sloshing"。如果只读数据在一个不同的缓存 列中，就可以避免sloshing。

对代码进行空间优化比进行速度优化效率更高。代码越少，代码所占的页也越少，这样需要的运行设置和产生的页错误也会更少，同时占据的缓存 列也会更少。然而，某些核心函数应该进行速度优化。可以利用profiler去识别这些函数。

3.决不要缓存频繁使用的数据。

软件缓存可以被各种应用程序使用。当一个计算代价很高时，你会保存结果的一个拷贝。这是一个典型的时空折中方法：牺牲一些存储空间以节省时间。如果做得好，这种方法可能非常有效。

你必须正确地进行缓存。如果缓存了错误数据，就会浪费存储空间。如果缓存得太多，其他操作可以使用的内存将会很少。如果缓存得太少，效率又会很低，因为你必须重新计算被缓存 遗漏的数据。如果将时间敏感数据缓存得时间过长，这些数据将会过时。一般，服务器更关心的是速度而不是空间，所以他们要比桌面系统进行更多的缓存。一定要定期去除不用的缓存，否则将会有运行设置问题。

4.应该创建多个线程，越多越好。

调整服务器中起作用的线程数目是很重要的。如果线程是I/O-bound的，将会花费很多时间用来等待I/O的完成-一个被阻塞的线程就是一个不做任何有用工作的线程。加入额外的线程可以增加通量，但是加入过多的线程将会降低服务器的性能，因为上下文交换将会成为一个重大的overhead。上下文交换速度应该低的原因有三个：上下文交换是单纯的overhead，对应用程序的工作没有任何益处；上下文交换用尽了宝贵的时钟周期；最糟的是，上下文交换将处理器的缓存填满了没用的数据，替换这些数据是代价高昂的。

有很多事情是依靠你的线程化结构的。每个客户端一个线程是绝对不合适的。因为对于大量用户端，它的扩展性不好。上下文交换变得难以忍受，Windows NT用尽了资源。线程池模型会工作得更好，在这种方法中一个工人线程池将处理一条请求列，因为Windows 2000提供了相应的APIs，如QueueUserWorkItem。

5.应该对数据结构使用全局锁

使数据线程安全的最简单方法是把它套上一把大锁。为简单起见，所有的东西都用同一把锁。这种方法会有一个问题：序列化。为了得到锁，每一个要处理数据的线程都必须排队等候。如果线程被一把锁阻塞，它没有在做任何有用的事。当服务器的负载较轻时，这个问题并不常见，因为一次可能只有一个线程需要锁。在负载很重的情况下，对锁的激烈争夺可能就会成为一个大问题。

设想在多车道高速公路上发生了一个意外事故，这条高速公路上的所有车辆都被转向一条狭窄的道路。如果车辆很少，这一转换对交通流的速率的影响可以忽略。如果车辆很多，当车辆慢慢并入那条单通道时，交通阻塞会延伸几英里。

有几种技术能够减少锁竞争。

· 不要过分保护，也就是说，不是非常必要不要锁住数据。只有需要时才去持有锁，而且时间不要过长。不要在大段代码周围或频繁执行的代码中没必要地使用锁，这一点很重要。

· 对数据进行分割，使它能够用一套独立的锁保护。例如，一个符号表可以按标识符的第一个字母分割，这样在修改名字以Q开头的符号的值时，就不会去读名字以H开头的符号的值。

· 使用APIs的Interlocked 系列（InterlockedIncrement，等）自动修改数据而不需要锁。

· 当数据不是经常被修改时可以使用多读者/单作者（multi-reader/single-writer）锁。你将获得更好的并发性，尽管锁操作的代价将更高并且你可能会冒饿死作者的危险。

· 在关键部分使用循环计数器。参见Windows NT 4.0 service pack 3中的SetCriticalSectionSpinCount API。

· 如果你不能得到锁，使用TryEnterCriticalSection并做一些其他的有用的工作。

高竞争导致serialization，serialization导致降低CPU的利用率，这促使用户加入更多的线程，结果事情变得更糟。

6.不必注意多处理器机器

你的代码在多处理器系统上比在单处理器系统上运行得还要糟，这可能是件令人恶心的事。一个很自然的想法是，在一个N维系统上运行N次会更好。性能很差的原因是竞争：锁竞争，总线竞争，和/或缓存列竞争。处理器都在是争夺共享资源的所有权，而不是做更多的工作。

如果你一定要编写多线程应用程序的话，你应该在多处理器盒上对你的应用程序进行强度测试和性能测试。单处理器系统通过时间分片地执行线程而提供一个并发性的假象。多处理器盒具有真正的并发性，竞争环境和竞争更容易发生。

7.应该始终使用模块化调用；他们很有趣。

利用同步模块化调用来执行I/O操作对大多数桌面应用程序来说是合适的。但是，他们不是使用服务器上的CPU（s）的好方法。I/O操作要花费上百万个时钟周期来完成，这些时钟周期本来可以被更好地利用。利用异步I/O你能得到显著提高的用户请求率和I/O通量，不过增加了额外的复杂性。

如果你有需要花费很长时间的模块化调用或I/O操作，你应该考调拨多少资源给他们。你想使用所有的线程还是有个限制？一般地，使用有限的几个线程要好些。构建一个小的线程池和队列，利用队列来安排线程的工作完成模块化调用。这样，其他线程就可以拾取和处理你的非模块化的请求。

8.不要进行测量

当你能够测量你所谈论的事情并用数字表达它时，这就表示你对他有了一定的了解；但是如果你不能用数字表达时，你的知识是贫瘠的不能令人满意的；这可能是知识的开始，但这时你简直不可能将你的思想提高到科学的水平。

- Lord Kelvin (William Thomson)

如果不测量你就不能了解应用程序的特性。你在黑暗中摸索，一半是靠猜测。如果不识别性能问题，你就不能做任何改进或做出工作量计划。

测量包括黑匣子测量和profiling。黑匣子测量的意思是收集由性能计数器（内存使用，上下文交换，CPU利用等）和外部检测工具（通量，反映时间等）所显示的数据。为了profile你的代码，你编译代码的一个工具版，然后在各种条件下运行它，并收集关于执行时间和过程调用频率的统计数据。

测量如果不用于分析的话就一点用都没有。测量将不仅告诉你有问题，而且甚至能帮助你找到问题发生在哪，但它不能告诉你为什么会有问题。对问题进行分析以便你能正确地改正他们。要从根本上解决问题而不是停留在表面现象。

当你进行改动后，要重新测量。你要知道你的改动是否有效。改动也可能会暴露其他性能问题，测量-分析-改正-再测量的循环就会重新开始。你也必须要有规律地进行测量，以便发现性能衰退问题。

9.应该使用单一用户，单一请求的测试方法。

书写ASP和ISAPI应用程序的一个通病是只用一个浏览器去测试应用程序。当他们在Internet上应用他们的程序时，他们才发现他们的应用程序不能处理高负载，并且通量和反应时间另人可怜。

用一个浏览器测试是必要的但是不够的。如果浏览器反应得不够快，你就知道你有麻烦了。但即使它在使用一个浏览器时很快，你也不知道它处理负载的能力如何。如果十几个用户同时请求会发生什么事？一百个呢？你的应用程序能容忍什么样的通量？它能提供什么样的反应时间？在轻载时这些数字会怎样？中等负载呢？重载呢？在多处理器机器上你的应用程序会如何？对你的应用程序进行强度测试，这对于找出bugs发现性能问题来说是基本的。

类似的负载测试考虑适用于所有的服务器应用程序。

10.不应使用实际环境。

人们往往只在几个特定的，人工的环境（如下benchmarks）下调整应用程序。选择和实际情况相对应的各种情况，并为针对各种操作进行优化，这一点很重要。如果你不这样做，你的用户和评论家一定会这样做，并且他们将依此来评判你的应用程序的好坏。

㈣ 如何利用Nginx的缓冲，缓存优化提升性能

反向代理的一个问题是代理大量用户时会增加服务器进程的性能冲击影响。在大多数情况下，可以很大程度上能通过利用Nginx的缓冲和缓存功能减轻。
当代理到另一台服务器，两个不同的连接速度会影响客户的体验：
从客户机到Nginx代理的连接。
从Nginx代理到后端服务器的连接。
Nginx具有优化这些连接调整其行为的能力。
如果没有缓冲，数据从代理的服务器发送并立即开始被发送到客户。如果假定客户端很快，缓冲可以关闭而尽快使数据到客户端，有了缓冲，Nginx 代理将暂时存储后端的响应，然后按需供给数据给客户端。如果客户端是缓慢的，允许Nginx服务器关闭到后端的连接。然后，它可以处理数据分配到客户端， 以任何可能的速度。
Nginx默认有缓冲设计，因为客户端往往有很大的不同的连接速度。我们可以用以下指令调节缓冲行为。可以在HTTP，server或 location位置来设置。重要的是要记住，大小size指令是针对每个请求配置的，所以增加超出你需求会影响你的性能，如果这时有许多客户端请求：
proxy_buffering：该指令控制缓冲是否启用。默认情况下，它的值是“on”。
proxy_buffers：该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置是8个缓冲区大小等于一个内存页（4K或者8K）。增加缓冲区的数目可以让你缓冲更多信息。
proxy_buffer_size：从后端服务器的响应头缓冲区大小，它包含headers，和其他部分响应是分开的。该指令设置响应部分的缓冲区大小。默认情况下，它和proxy_buffers是相同的尺寸，但因为这是用于头信息，这通常可以设置为一个较低的值。
proxy_busy_buffers_size：此指令设置标注“client-ready”缓冲区的最大尺寸。而客户端可以一次读取来自一个缓冲区的数据，缓冲被放置在队列中，批量发送到客户端。此指令控制允许是在这种状态下的缓冲空间的大小。
proxy_max_temp_file_size：这是每个请求能用磁盘上临时文件最大大小。这些当上游响应太大不能装配到缓冲区时被创建。
proxy_temp_file_write_size：这是当被代理服务器的响应过大时Nginx一次性写入临时文件的数据量。
proxy_temp_path：当上游服务器的响应过大不能存储到配置的缓冲区域时，Nginx存储临时文件硬盘路径。
正如你所看到的，Nginx提供了相当多的不同的指令来调整缓冲行为。大多数时候，你不必担心太多，但它对于调整一些值可能是有用的。可能最有用的调整是proxy_buffers和proxy_buffer_size指令。

㈤ linux怎样提升磁盘读写性能

关于页面缓存的信息，可以用
cat /proc/meminfo
看到。其中的Cached 指用于pagecache的内存大小（diskcache-SwapCache）。随着写入缓存页，Dirty 的值会增加。
一旦开始把缓存页写入硬盘,Writeback的值会增加直到写入结束。

Linux 用pdflush进程把数据从缓存页写入硬盘，查看有多少个pdflush进程
cat /proc/sys/vm/nr_pdflush_threads

pdflush的行为受/proc/sys/vm中的参数的控制
/proc/sys/vm/dirty_writeback_centisecs (default 500):
1/100秒, 多长时间唤醒pdflush将缓存页数据写入硬盘。默认5秒唤醒2个（更多个）线程。
如果wrteback的时间长于dirty_writeback_centisecs的时间，可能会出问题。

pdflush的第一件事是读取
/proc/sys/vm/dirty_expire_centiseconds (default 3000)
1/100秒。缓存页里数据的过期时间(旧数据)，在下一个周期内被写入硬盘。默认30秒是一个很长的时间。

第二件事是判断内存是否到了要写入硬盘的限额，由参数决定：
/proc/sys/vm/dirty_background_ratio (default 10)
百分值，保留过期页缓存（脏页缓存）的最大值。是以MmeFree+Cached-Mapped的值为基准的

pdflush写入硬盘看两个参数：
1 数据在页缓存中是否超出30秒，如果是，标记为脏页缓存;
2 脏页缓存是否达到工作内存的10%;

以下参数也会影响到pdflush
/proc/sys/vm/dirty_ratio (default 40)
总内存的最大百分比，系统所能拥有的最大脏页缓存的总量。超过这个值，开启pdflush写入硬盘。如果cache增长快于pdflush，那么整个系统在40%的时候遇到I/O瓶颈，所有的I/O都要等待cache被pdflush进硬盘后才能重新开始。

对于有高度写入操作的系统
dirty_background_ratio: 主要调整参数。如果需要把缓存持续的而不是一下子大量的写入硬盘，降低这个值。
dirty_ratio： 第二调整参数。

Swapping参数
/proc/sys/vm/swappiness
默认，linux倾向于从物理内存映射到硬盘缓存，保持硬盘缓存尽可能大。未用的页缓存会被放进swap区。
数值为0，将会避免使用swapping
100，将会尽量使用swapping
少用swapping会增加程序的响应速度；多用swapping将会提高系统的可用性。

如果有大量的写操作，为避免I/O的长时间等待，可以设置：
$ echo 5 > /proc/sys/vm/dirty_background_ratio
$ echo 10 > /proc/sys/vm/dirty_ratio

文件系统数据缓冲需要频繁的内存分配。加大保留内存的值能提升系统速度和稳定。小于8G的内存，保留内存为64M，大于8G的设置为256M
$ echo 65536 > /proc/sys/vm/min_free_kbytes


I/O 调度器
cat /sys/block/[disk]/queue/scheler

4中调度算法
noop anticipatory deadline [cfq]
deadline : deadline 算法保证对既定的IO请求以最小的延迟时间。
anticipatory： 有个IO发生后，如果又有进程请求IO，则产生一个默认6ms猜测时间，猜测下一个进程请求IO是干什么。这对于随机读取会造成较大的延时。
对数据库应用很糟糕，而对于Web Server等则会表现不错。
cfq: 对每个进程维护一个IO队列，各个进程发来的IO请求会被cfq以轮循方式处理，对每一个IO请求都是公平。适合离散读的应用。
noop: 对所有IO请求都用FIFO队列形式处理。默认IO不会存在性能问题。

改变调度器
$ echo deadline > /sys/block/sdX/queue/scheler
对于数据库服务器，deadline算法是推荐的。

提高调度器请求队列的
$ echo 4096 > /sys/block/sdX/queue/nr_requests

有大量的读请求，默认的请求队列应付不过来，可以提高这个值。缺点是要牺牲一定的内存。
为了增加连续读取的吞吐量，可以增加预读数据量。预读的实际值是自适应的，所以使用一个较高的值，不会降低小型随机存取的性能。
$ echo 4096 > /sys/block/sdX/queue/read_ahead_kb
如果LINUX判断一个进程在顺序读取文件，那么它会提前读取进程所需文件的数据，放在缓存中。服务器遇到磁盘写活动高峰，导致请求处理延迟非常大（超过3秒）。通过调整内核参数，将写活动的高峰分布成频繁的多次写，每次写入的数据比较少。这样可以把尖峰的写操作削平成多次写操作。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。

/proc/sys/vm/dirty_ratio

控制文件系统的写缓冲区的大小，单位是百分比，表示占系统内存的百分比，表示当写缓冲使用到系统内存多少的时候，开始向磁盘写出数据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值。

/proc/sys/vm/dirty_background_ratio

控制文件系统的pdflush进程，在何时刷新磁盘。单位是百分比，表示系统内存的百分比，pdflush用于将内存中的内容和文件系统进行同步，比如说,当一个文件在内存中进行修改,pdflush负责将它写回硬盘.每当内存中的垃圾页（dirty page）超过10%的时候,pdflush就会将这些页面备份回硬盘.增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值：

/proc/sys/vm/dirty_writeback_centisecs

控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒。如果你的系统是持续地写入动作，那么实际上还是降低这个数值比较好，这样可以把尖峰的写操作削平成多次写操作。
如果你的系统是短期地尖峰式的写操作，并且写入数据不大（几十M/次）且内存有比较多富裕，那么应该增大此数值。
该参数的设置应该小于dirty_expire_centisecs，但也不能太小，太小I/O太频繁，反而
使系统性能下降。具体可能需要在生产环境上测试。据说1:6 (dirty_expire_centisecs : dirty_writeback_centisecs )的比例比较好。

/proc/sys/vm/dirty_expire_centisecs

声明Linux内核写缓冲区里面的数据多“旧”了之后，pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 30000，也就是 30 秒的数据就算旧了，将会刷新磁盘。对于特别重载的写操作来说，这个值适当缩小也是好的，但也不能缩小太多，因为缩小太多也会导致IO提高太快。
当然，如果你的系统内存比较大，并且写入模式是间歇式的，并且每次写入的数据不大（比如几十M），那么这个值还是大些的好。

/proc/sys/vm/vfs_cache_pressure

表示内核回收用于directory和inode cache内存的倾向；缺省值100表示内核将根据pagecache和swapcache，把directory和inode cache保持在一个合理的百分比；降低该值低于100，将导致内核倾向于保留directory和inode cache；增加该值超过100，将导致内核倾向于回收directory和inode cache

/proc/sys/vm/min_free_kbytes

表示强制Linux VM最低保留多少空闲内存（Kbytes）。
缺省设置：724（512M物理内存）

/proc/sys/vm/nr_pdflush_threads

表示当前正在运行的pdflush进程数量，在I/O负载高的情况下，内核会自动增加更多的pdflush进程。

/proc/sys/vm/overcommit_memory

指定了内核针对内存分配的策略，其值可以是0、1、2。

0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。

2， 表示内核允许分配超过所有物理内存和交换空间总和的内存（参照overcommit_ratio）。

缺省设置：0

/proc/sys/vm/overcommit_ratio

如果overcommit_memory=2，可以过载内存的百分比，通过以下公式来计算系统整体可用内存。系统可分配内存=交换空间+物理内存*overcommit_ratio/100
缺省设置：50（%）

/proc/sys/vm/page-cluster

表示在写一次到swap区的时候写入的页面数量，0表示1页，1表示2页，2表示4页。
缺省设置：3（2的3次方，8页）

/proc/sys/vm/swapiness

表示系统进行交换行为的程度，数值（0-100）越高，越可能发生磁盘交换。

更改：
/etc/sysctl.conf

vm.dirty_ratio=40

sysctl -p

查看：

find /proc/sys/vm -name dirty* -print | while read name; do echo $name ;cat ${name}; done

㈥ 影响服务器性能的四个主要因素

一、处理器CPU

不管是国内服务器，还是海外服务器，它的处理器是非常重要的。就像电脑的CPU一样，这个是处理所有运算的大脑，如果没有CPU，或者CPU的配置不够好，运行1，2个项目就可能导致服务器宕机。

二、选择合适的内存

一般来说，服务器性能也取决于内存的大小。我们知道，内存的大小决定一个服务器能同时启用多少个应用程序，普通的服务器一般是4G-32G之间，对于一些高端的服务器，内存可以扩展到64GB，甚至更高。不过一般的网站服务器普通的内存大小即可，如果内存大小实在不够，可以进行扩容。

三、选择合适的硬盘类型

硬盘也有不同的类型，比如选择固态硬盘SSD，或者HDD硬盘，HDD整体上来说读取速度会比SSD要慢很多，但是价格相对来说会便宜很多，看企业的预算成本 。

四、磁盘阵列

不同的磁盘类型对数据的存储性能及可靠性也是有很大差别的，一般入门级服务器配备RAID 0或1即可，高一点配置的可以考虑RAID5 或者 RAID 10。一般来说RAID是比较常见的，尤其是Windows操作系统服务器，软件在RAID中也更受欢迎。

㈦ DDR5来了，新的内存技术对电脑性能提升有多大帮助

首先DDR5内存最先还是会在服务器上应用，而不是民用市场，短时间内DDR5内存并不会普及，所以如今够买DDR4内存仍然不算晚。

而且电脑硬件的普及需要的时间是极其漫长的，如今很多用户的电脑仍然还是DDR3内存，甚至还有DDR2的老爷机。所以就算新的内存可以提升性能，对于个人用户来说也是有些遥远的事。

但更高频的内存也有好处，比如游戏开发商在开发游戏时，需要在游戏优化上下的功夫就少了，能进一步拉近大厂游戏和小作坊游戏在优化层面上的差距。对于一些专业用户，比如特效、剪辑为主的电脑用户，高频的内存也可以带来更好的工作体验。只是这个体验的提升远远没有想象中的大。

㈧ 如何提高Linux服务器磁盘io性能

您好，很高兴为您解答。

在现有文件系统下进行优化：
linux内核和各个文件系统采用了几个优化方案来提升磁盘访问速度。但这些优化方案需要在我们的服务器设计中进行配合才能得到充分发挥。
文件系统缓存
linux内核会将大部分空闲内存交给虚拟文件系统，来作为文件缓存，叫做page cache。在内存不足时，这部分内存会采用lru算法进行淘汰。通过free命令查看内存，显示为cached的部分就是文件缓存了。

如何针对性优化：
lru并不是一个优秀淘汰算法，lru最大的优势是普适性好，在各种使用场景下都能起到一定的效果。如果能找到当前使用场景下，文件被访问的统计特征，针 对性的写一个淘汰算法，可以大幅提升文件缓存的命中率。对于http正向代理来说，一个好的淘汰算法可以用1GB内存达到lru算法100GB内存的缓存 效果。如果不打算写一个新的淘汰算法，一般不需要在应用层再搭一个文件cache程序来做缓存。

最小分配：
当文件扩大，需要分配磁盘空间时，大部分文件系统不会仅仅只分配当前需要的磁盘空间，而是会多分配一些磁盘空间。这样下次文件扩大时就可以使用已经分配好的空间，而不会频繁的去分配新空间。
例如ext3下，每次分配磁盘空间时，最小是分配8KB。
最小分配的副作用是会浪费一些磁盘空间（分配了但是又没有使用）

如何针对性优化：
我们在reiserfs下将最小分配空间从8KB改大到128K后提升了30%的磁盘io性能。如果当前使用场景下小文件很多，把预分配改大就会浪费很多 磁盘空间，所以这个数值要根据当前使用场景来设定。似乎要直接改源代码才能生效，不太记得了，09年的时候改的，有兴趣的同学自己google吧。

io访问调度：
在同时有多个io访问时，linux内核可以对这些io访问按LBA进行合并和排序，这样磁头在移动时，可以“顺便”读出移动过程中的数据。
SATA等磁盘甚至在磁盘中内置了io排序来进一步提升性能，一般需要在主板中进行配置才能启动磁盘内置io排序。linux的io排序是根据LBA进行的，但LBA是一个一维线性地址，无法完全反应出二维的圆形磁盘，所以磁盘的内置io排序能达到更好的效果。

如何针对性优化：
io访问调度能大幅提升io性能，前提是应用层同时发起了足够的io访问供linux去调度。
怎样才能从应用层同时向内核发起多个io访问呢？
方案一是用aio_read异步发起多个文件读写请求。
方案二是使用磁盘线程池同时发起多个文件读写请求。
对我们的http正向代理来说，采用16个线程读写磁盘可以将性能提升到2.5倍左右。具体开多少个线程/进程，可以根据具体使用场景来决定。

小提示：
将文件句柄设置为非阻塞时，进程还是会睡眠等待磁盘io，非阻塞对于文件读写是不生效的。在正常情况下，读文件只会引入十几毫秒睡眠，所以不太明显；而在磁盘io极大时，读文件会引起十秒以上的进程睡眠。

预读取：
linux内核可以预测我们“将来的读请求”并提前将数据读取出来。通过预读取可以减少读io的次数，并且减小读请求的延时。

如何针对性优化：
预读取的预测准确率是有限的，与其依赖预读取，不如我们直接开一个较大的缓冲区，一次性将文件读出来再慢慢处理；尽量不要开一个较小的缓冲区，循环读文件/处理文件。
虽然说“预读取”和“延迟分配”能起到类似的作用，但是我们自己扩大读写缓冲区效果要更好。

延迟分配：
当文件扩大，需要分配磁盘空间时，可以不立即进行分配，而是暂存在内存中，将多次分配磁盘空间的请求聚合在一起后，再进行一次性分配。
延迟分配的目的也是减少分配次数，从而减少文件不连续。

延迟分配的副作用有几个：
1、如果应用程序每次写数据后都通过fsync等接口进行强制刷新，延迟分配将不起作用
2、延迟分配有可能间歇性引入一个较大的磁盘IO延时（因为要一次性向磁盘写入较多数据）
只有少数新文件系统支持这个特性

如何针对性优化：
如果不是对安全性（是否允许丢失）要求极高的数据，可以直接在应用程序里缓存起来，积累到一定大小再写入，效果比文件系统的延迟分配更好。如果对安全性要求极高，建议经常用fsync强制刷新。

在线磁盘碎片整理：
Ext4提供了一款碎片整理工具，叫e4defrag，主要包含三个功能：
1、让每个文件连续存储
2、尽量让每个目录下的文件连续存储
3、通过整理空闲磁盘空间，让接下来的分配更不容易产生碎片

如何针对性优化：
“让每个目录下的文件连续存储”是一个极有价值的功能。
传统的做法是通过拼接图片来将这10张图片合并到一张大图中，再由前端将大图切成10张小图。
有了e4defrag后，可以将需连续访问的文件放在同一个文件夹下，再定期使用e4defrag进行磁盘整理。

实现自己的文件系统：
在大部分服务器上，不需要支持“修改文件”这个功能。一旦文件创建好，就不能再做修改操作，只支持读取和删除。在这个前提下，我们可以消灭所有文件碎片，把磁盘io效率提升到理论极限。

有一个公式可以衡量磁盘io的效率：
磁盘利用率 = 传输时间/（平均寻道时间+传输时间）

如若满意，请点击回答右侧【采纳答案】，如若还有问题，请点击【追问】

~ O(∩_∩)O~

㈨ 如何进行全面提高FTP服务器的安全性能呢

Windows2000系统提供了FTP服务功能，由于简单易用，服务器托管与Windows系统本身结合紧密，深受广大用户的喜爱。但使用IIS5.0 架设的FTP服务器真的安全吗？它的默认设置其实存在很多安全隐患，很容易成为黑客们的攻击目标。服务器托管如何让FTP服务器更加安全，只要稍加改造，就能做到。

一 取消匿名访问功能

默认情况下服务器托管，Windows2000系统的FTP服务器是允许匿名访问的，虽然匿名访问为用户上传、下载文件提供方便，但却存在极大的安全隐患。用户不需要申请合法的账号，就能访问FTP服务器，甚至还可以上传、下载文件，特别对于一些存储重要资料的FTP服务器，服务器托管很容易出现泄密的情况，因此建议用户取消匿名访问功能。

在Windows2000系统中，点击“开始→程序→管理工具→Internet服务管理器”，弹出管理控制台窗口。然后展开窗口左侧的本地计算机选项，就能看到IIS5.0自带的FTP服务器，下面笔者以默认FTP站点为例，介绍如何取消匿名访问功能。

右键点击“默认FTP站点”项，在右键菜单中选择“属性”，服务器托管接着弹出默认FTP站点属性对话框，切换到“安全账号”标签页，取消“允许匿名连接”前的勾选，最后点击“确定”按钮，这样用户就不能使用匿名账号访问FTP服务器了，必须拥有合法账号。

二 启用日志记录

Windows日志记录着系统运行的一切信息，但很多管理员对日志记录功能不够重视，为了节省服务器资源，禁用了FTP服务器日志记录功能，服务器托管这是万万要不得的。FTP服务器日志记录着所有用户的访问信息，如访问时间、客户机IP地址、使用的登录账号等，这些信息对于FTP服务器的稳定运行具有很重要的意义，一旦服务器出现问题，就可以查看FTP日志，找到故障所在，及时排除。因此一定要启用FTP日志记录。

在默认FTP站点属性对话框中，切换到“FTP站点”标签页，一定要确保“启用日志记录”选项被选中，这样就可以在“事件查看器”中查看FTP日志记录了。

三 正确设置用户访问权限

每个FTP用户账号都具有一定的访问权限，但对用户权限的不合理设置，也能导致FTP服务器出现安全隐患。如服务器中的CCE文件夹，只允许 CCEUSER账号对它有读、写、修改、列表的权限，禁止其他用户访问，但系统默认设置，还是允许其他用户对CCE文件夹有读和列表的权限，服务器托管因此必须重新设置该文件夹的用户访问权限。

右键点击CCE文件夹，在弹出菜单中选择“属性”，然后切换到“安全”标签页，首先删除Everyone用户账号，接着点击“添加”按钮，服务器托管将 CCEUSER账号添加到名称列表框中，然后在“权限”列表框中选中修改、读取及运行、列出文件夹目录、读取和写入选项，最后点击“确定”按钮。这样一来，CCE文件夹只有CCEUSER用户才能访问。

四 启用磁盘配额

FTP服务器磁盘空间资源是宝贵的，无限制的让用户使用，势必造成巨大的浪费，因此要对每位FTP用户使用的磁盘空间进行限制。下面笔者以CCEUSER用户为例，将其限制为只能使用100M磁盘空间。

在资源管理器窗口中，右键点击CCE文件夹所在的硬盘盘符，在弹出的菜单中选择“属性”，接着切换到“配额”标签页，选中服务器托管“启用配额管理”复选框，激活“配额”标签页中的所有配额设置选项，为了不让某些FTP用户占用过多的服务器磁盘空间，一定要选中“拒绝将磁盘空间给超过配额限制的用户”复选框。

然后在“为该卷上的新用户选择默认配额限制”框中选择“将磁盘空间限制为”单选项，接着在后面的栏中输入100，磁盘容量单位选择为“MB”，然后进行警告等级设置，在“将警告等级设置为”栏中输入“96”，容量单位也选择为“MB”，这样就完成了默认配额设置。服务器托管此外，还要选中“用户超出配额限制时记录事件”和“用户超过警告等级时记录事件”复选框，以便将配额告警事件记录到Windows日志中。

点击配额标签页下方的“配额项”按钮，打开磁盘配额项目对话框，接着点击“配额→新建配额项”，弹出选择用户对话框，选中CCEUSER用户后，点击“确定”按钮，接着在“添加新配额项”对话框中为CCEUSER用户设置配额参数，服务器托管选择“将磁盘空间限制为”单选项，在后面的栏中输入 “100”，接着在“将警告等级设置为”栏中输入“96”，它们的磁盘容量单位为“MB”，最后点击“确定”按钮，完成磁盘配额设置，这样CCEUSER 用户就只能使用100MB磁盘空间，超过96MB就会发出警告。

五 TCP/IP访问限制

为了保证FTP服务器的安全，还可以拒绝某些IP地址的访问。在默认FTP站点属性对话框中，切换到“目录安全性”标签页，选中“授权访问”单选项，然后在“以下所列除外”框中点击“添加”按钮，弹出“拒绝以下访问”对话框，这里可以拒绝单个IP地址或一组IP地址访问，服务器托管以单个IP地址为例，选中“单机”选项，然后在“IP地址”栏中输入该机器的IP地址，最后点击“确定”按钮。这样添加到列表中的IP地址都不能访问FTP服务器了。

六 合理设置组策略

通过对组策略项目的修改，也可以增强FTP服务器的安全性。在Windows2000系统中，进入到“控制面板→管理工具”，运行本地安全策略工具。

1. 审核账户登录事件

在本地安全设置窗口中，服务器托管依次展开“安全设置→本地策略→审核策略”，然后在右侧的框体中找到“审核账户登录事件”项目，双击打开该项目，在设置对话框中选中“成功”和“失败”这两项，最后点击“确定”按钮。该策略生效后，FTP用户的每次登录都会被记录到日志中。

2. 增强账号密码的复杂性

一些FTP账号的密码设置的过于简单，就有可能被“不法之徒”所破解。为了提高FTP服务器的安全性，必须强制用户设置复杂的账号密码。

在本地安全设置窗口中，服务器托管依次展开“安全设置→账户策略→密码策略”，在右侧框体中找到“密码必须符合复杂性要求”项，双击打开后，选中“已启用”单选项，最后点击“确定”按钮。

然后，打开“密码长度最小值”项，为FTP账号密码设置最短字符限制。这样以来，密码的安全性就大大增强了。

3. 账号登录限制

有些非法用户使用黑客工具，反复登录FTP服务器，来猜测账号密码。这是非常危险的，因此建议大家对账号登录次数进行限制。

依次展开“安全设置→账户策略→账户锁定策略”，服务器托管在右侧框体中找到“账户锁定阈值”项，双击打开后，设置账号登录的最大次数，如果超过此数值，账号会被自动锁定。接着打开“账户锁定时间”项，设置FTP账号被锁定的时间，账号一旦被锁定，超过这个时间值，才能重新使用。

通过服务器托管以上几步设置后，用户的FTP服务器就会更加安全，再也不用怕被非法入侵了。

㈩ Web服务器性能和站点访问性能该如何优化

今天小编要跟大家分享的文章是关于Web服务器性能和站点访问性能该如何优化?正在从web前端工作的小伙伴们来和小编一起看一看吧！

一、优化思路浅析


要优化Web服务器的性能，我们先来看看Web服务器在web页面处理上的步骤：


1、Web浏览器向一个特定的服务器发出Web页面请求;


2、Web服务器接收到web页面请求后，寻找所请求的web页面，并将所请求的Web页面传送给Web浏览器;


3、Web浏览器接收到所请求的web页面内容，并将它显示出来。


上面三个步骤都关系Web服务器，但实际Web服务器性能相关最大的是在第2步，这里Web服务器需要寻找来自浏览器所请求的Web
页面内容。


我们知道，Web页面内容有静态的，也有动态的，静态的内容，web
服务器可以直接将结果发回给浏览器，对于动态内容，则通常需要交给应用服务器先处理，由应用服务器返回结果。


当然，也有Web服务器本身可以处理动态内容的，例如IIS就可以自已解释处理ASP,ASP.NET这两种微软的动态网页脚本语言。


从上面简要的分析里，我们大致可以得到这样的结论，影响Web页面访问的影响因素会有这几个：


1、Web服务器从磁盘中读取静态页面内容的速度，也即时间;


2、Web服务器判定请求内容是静态还是动态内容的时间;


3、Web服务器转发请求给应用服务器的时间;


4、应用服务器处理(解释)动态内容所需的时间;


5、Web服务器返回Web内容给浏览器的响应时间;


6、Web服务器接收来自浏览器请求的处理性能;


7、Web访问请求数据在网络上传输的时间：包括从浏览器到服务器，和从服务器到浏览器两部分;


8、浏览器本地计算和渲染Web内容的时间，即接收内容后展现内容的时间。


上面8项很容易理解，也很直接，其实还有以下几项也是关乎Web
页面访问速度体验的因素，你可以思考下是否如此?或者说是否会影响到页面访问性能。


§Web服务器执行安全策略检查的时间，或者说性能;


§Web服务器读取日志文件、写日志内容、关闭对日志文件访问的时间，先读后写再关闭，这三步中的读与写又涉及到磁盘访问性能因素;


§同时与Web服务器连接会话的客户端数量大小，即并发访问量多大。


我们可以将上面的影响因素抽像出来，那么就是：


1、Web服务器磁盘性能;


2、Web服务器与应用服务器交互的性能;


3、应用服务器处理动态内容的性能，或者说动态内容应用处理性能;


4、客户端与Web服务器的连接速度，即网络传输性能;


5、Web浏览器解释和渲染Web内容的性能;


6、Web访问并发性能。


反映到我们进行性能优化，可以入手的角度就有：


1、增加带宽，包括服务器和客户端两边的Internet连接带宽;


2、加快动态内容的处理性能;


3、尽可能多地使用静态内容，这样Web服务器就可以无需请求应用服务器，直接将Web内容发给浏览器端，这里可以入手的方案又有：


动态内容缓存


动态内容静态化


多台服务器负载均衡同时处理大量的并发访问;


提升服务器磁盘访问性能，也即通常所说的I/O性能;


减少网页中的HTTP请求数;


更换更好性能的Web服务器;


合理部署服务器，在离客户端更近的地方部署服务器，已经证明可以明显地提升访问性能。


二、性能优化实践


经过前面小节的简要分析，相信你对优化Web服务器有一定的思路了，你可以从硬件层面、软件层面、Web代码三个层面去优化。


下面我们结合一个具体的实例来实践一回，本文所举例是一个小型的Web
站点，部分数据系假设，如有类同，纯属巧合，仅起抛砖引玉之用。在实际工作中，如果碰到大站点，你可以参考此处的分析，修改优化方案。


1.站点简介


一个社区论坛站点，采用Discuz!论坛程序构建，该程序采用主流的PHP+MySQL组成。


网站目前有近5万注册用户，绝大多数是国内的用户，活跃用户数在一半左右，每天平均PV在15~20万，独立访问IP数在8000
左右。


2.Web服务器性能优化需求


网站现部署在国外的服务器，租用虚拟主机来运营，因为访问量比较大，所以经常会收到虚拟主机服务商的流量很大的通知，要求控制下访问量。


另外，虚拟主机的服务器在美国，没有在国内租用虚拟主机的原因是国内网站在备案方面非常繁琐，在网站一开始运营时数据量和访问量都比较小，所以对性能要求不高，数据量小，所以服务器在查询处理数据时速度比较快，也让人感觉访问速度不慢，现在随着数据量和访问量的不断上升，访问速度已明显下降，到了需要改善访问性能的时候了。


基于目前该社区网站的情况，提出的优化需求是，国内访问速度需要提升一倍，目前首页加载时间需要40秒左右，希望优化后能在20
秒以内将首页加载完成。


另外提出网站数据能够每天自动备份一次，备份数据保留一个月的，以便随时恢复。


上述两点需求，其中第一条才是性能优化需求，第二条是额外的需求了。


3.性能优化方案


根据其网站的现状和优化需求，结合自己的经验，加上谷歌的搜索，同时与网站主不断确认沟通，最终得到以下性能优化方案：


由虚拟主机部署改为独立服务器部署


虚拟主机受限比较多，无法自己自定义配置Web服务器，无法配置PHP
动态缓存，而且独立服务器可以独享内存、处理器资源，不再受虚拟主机商对每个虚拟主机用户的内存和处理器资源占用限制。处理器资源和内存资源，对接受更多并发访问有直接性能提升效果。


独立服务器，我们选用Linode2048型号，2G内存，4核处理器(Linode所有VPS都是四核处理器)，80G硬盘空间，800G
网络流量。


由Windows操作系统改为Linux操作系统


网站使用的是PHP+MySQL程序，PHP在Windows下的性能，受限于IIS需要通过ISAPI形式调用PHP，所以性能不如
Linux下Apache直接通过PHP模块解释PHP，更不如Nginx与PHP-FPM
的性能，既然使用了独立服务器，操作系统也可以自己确定，Linux系统我们选用了熟悉的UbuntuLinuxServer10.04(一年前还没有
12.04)，^-^。


Web服务器采用Nginx，而不使用Apache


选用Nginx而不用Apache的原因非常直接和干脆，因为站点里有很多静态的附件文件，在处理静态内容上，Nginx性能是Apache
的差不多10倍。


在PHP解释和伪静态规则方面，Apache要比Nginx强，但这不影响我们放弃它，为缓解这一点，我们在后面对PHP
进行了动态缓存。


对PHP查询进行动态缓存，使用eAccelerator这个加速器


PHP加速器是一个为了提高PHP执行效率，从而缓存起PHP的操作码，这样PHP后面执行就不用解析转换了，可以直接调用PHP
操作码，这样速度上就提高了不少。


eAccelerator是一个开源PHP加速器，优化和动态内容缓存，提高了PHP脚本的缓存性能，使得PHP
脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。使得的PHP程序代码执效率能提高1-10
倍，这个加速还是非常明显的。


具体地，我们计划对eAccelerator进行以下设置优化：


§缓存使用物理内存来进行，不使用磁盘来缓存。我们知道内存的读写性能是硬盘的N倍，所以在内存资源可以安排情况下，强烈建议使用内存来保存
eAccelerator的缓存内容。


§缓存大小设置为32MB，这个值是操作系统默认支持最大的缓存容量。虽然可以通过修改配置文件来加大这个值，但我们觉得没有必要，所以就放弃了。


Nginx性能优化


选用了Nginx，虽然它的性能很好，但我们仍然需要对它进行性能优化，在这个案例中，我们做了以下优化：


§使用8个进程，每个进程大约需要20M内存消耗，这里一共使用了150M左右的内存。


§充分使用主服务器的CPU内核：四核，使用CPU粘性配置选项(worker_cpu_affinity)，每核处理器分配两个进程。


§开启gzip压缩功能：gzip压缩对JS,CSS,XML压缩效果非常好，能压缩一半，即减少一倍的传输时间;对图片文件，JPG
已经压缩过的，它的压缩性能要少一些。


§图片本地缓存1天：网站上的图片很多，通常一张图片上传后，不会频繁的修改，只会频繁的访问，所以将图片放在Nginx
缓存里，可以减少服务器访问加载次数，提升访问速度。


§JS、CSS文件本地缓存7
天：这两种网页文件，平时都不会去修改它，将它缓存起来，可以减少加载次数，提升访问速度。为什么这两种文件不和图片一起设置缓存有效期，是考虑了不同文件的修改频率不一样。


§Nginx日志每天切割一次：这个优化项能大大减小Nginx日志文件的大小，经过一周的查看，每天的日志文件是50M
左右，如果不是每天切割，用月切割，那一个月的日志文件就是几个G，要Web
服务器在内存里加载这么大的文件，系统本身内存不够用，就自然会用到磁盘来缓存，这就影响性能。每天50M左右，在内存上完全可以顺利加载，这样Nginx
在处理访问时，可以快速的保存访问日志。


经过上述几个优化项目，Nginx这边一共需要占用200M左右内存资源。


对PHPCGI进程性能进行优化


Nginx没有PHP模块，所以它对PHP的支持是通过PHP-FPM来实现的，PHP-FPM
是跑进程来处理并发请求，在这个案例中，我们配置了20个进程，每个进程差不多占用20M左右内存资源，一共是400M左右。


同时，PHP-FPM与Nginx交互机制，选用LinuxSocket模式而不是TCP协议端口，Socks是系统级处理模式，socks
也就是一个文件连接，而TCP协议端口，需要经过网络协议处理，性能不如前者，所以我们选择了前者。


MySQL数据库性能优化


因为网站主程序是选用他人开发的开源程序，所以对数据库查询的程序优化我们无法处理，只能从MySQL本身寻找突破口。


我们可以想像一下，对于论坛网站，通常看贴、查贴的访问量要远大于创建贴子、回复贴子的访问量，体现在MySQL
数据库上，就是读表与查询表数据的连接处理更多。


因此我们要选择对读表、查询性能更好的存储引擎，结合以前了解的知识，MySQL缺省的MyISAM
引擎就是被设计为适合处理读频率远大于写频率的环境，查询效率相当可观，而且内存占用很少，这也与我们租用低内存配置的VPS相符。


具体到MySQL配置参数的优化上，受限于服务器上内存资源本身有限，就直接采用缺省的中型环境配置文件。


内容分发网络应用


站点每天十多万的访问，上万独立IP
访问，查看先前的访问统计，访问来自国内各个地区，使用多种网络连接访问进来，为保证来自各网络的用户访问速度，同时也减少对网站服务器的请求，我们采用了CDN
来分发静态内容，这样各地的用户可以就近访问到已缓存在CDN上的文件，CDN
服务商会在静态内容第一次访问时缓存到他们全国各地的服务器上，当第二次访问时，用户实际是没有连接到网站服务器上获取文件的，而是直接从CDN
服务器上获取，可以明显的提升网站性能。


以上就是小编今天为大家分享的关于Web服务器性能和站点访问性能该如何优化的文章，希望本篇文章能够对正在从事web前端工作的小伙伴们有所帮助。想要了解更多web前端相关知识记得关注北大青鸟web培训官网。最后祝愿小伙伴们工作顺利！