目前，我们正在努力满足要求：在英国，Web服务器的首次响应必须在200毫秒之内。目前，在负载均衡器下的2个专用Web服务器和1个db服务器下，我们的速度为800毫秒。

目前该网站的客户少于5个，产品2个，类别4个，目前该网站尚无前端，它不包含样式和图像。

它也可以在Nginx和Varnish上运行。

谁能给我有关Web服务器设置的任何建议？为什么我们的进入缓慢？您有什么建议可以优化呢？需要更快地获得400％！

我咬

在英国，来自Web服务器的第一个响应必须在200毫秒内出现。
该站点目前尚无前端，它没有样式，也没有图像。

没有Varnish或FPC（或两者）的帮助，您将无法实现这些数字。我当然希望该数字也不必包含静态内容（无论何时决定添加它）-因为它几乎无法实现（几乎没有图像/ js / css）。

我们将以800ms的
速度运行它也在Nginx和Varnish 上运行

您将Varnish配置错误。

正确配置的Varnish安装将提供<100ms的页面加载时间（我们看到的时间接近<10ms）。

实际上，对于Magento，您应该期望看到这样的内容，

当客户未登录时.​​..
即 尚未创建唯一的会话（添加到购物车/愿望清单，登录等）

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

当客户登录时...
即 创建了唯一的会话（登录，购物车中的物品等）。此时，清漆可能会关闭。而且，如果您选择使用ESI（取决于反向调用），它可以保持与FPC缓存相似的页面加载时间（由于引导程序开销），或者实际上可以增加页面加载时间，而不是被取消缓存。

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

它不是调整Varnish的情况- 而是 - “您实际上根本没有缓存任何东西”。

理想的Magento服务器配置文件

没有一个，嗯，不完全是。

我们经营着超过400台服务器，所有服务器都是Magento纯粹的-大小和容量各异。而且很少有我们在一个文件上拥有的配置文件会匹配另一个文件。那是因为并非所有企业都一样。

造成瓶颈的原因有很多：

1. 大量访问者并发，会话活跃
2. “不良”爬网机器人的受害者，产生了必要的，无法估量的负载
3. 分层导航命中的比例很高
4. 大量搜索查询
5. 每小时大量交易
6. 生成不良的模板
7. 第三方扩展过多/缓慢/庞大
8. 过时的入站链接导致404次匹配的比例很高
9. 网络接口容量已达到极限
10. 大型/复杂目录（许多产品/类别/属性）

因此，对于所有范围的商店，每个商店都有不同的方法来获得最佳性能。

解决上述问题；我们会故意避免仅说明“更多/更好的硬件”

1. 使用FPC以外的FPC
2. 在网络边缘过滤/阻止不良机器人-或将所有请求重定向到Varnish，无论Cookie状态/ URL如何
3. 将股票分层导航更改为SOLR，使分层导航过滤器依赖
4. 将库存搜索更改为SOLR
5. 在主/从配置之间分配MySQL负载-仅在确保浏览负载由Varnish / FPC吸收时才执行此操作
6. 重新构建模板
7. 剥掉它们
8. 持续监控访问日志，并在交付前在Nginx / Varnish上重写URL。如果是在Nginx级别上进行，请确保Varnish正在缓存301/302重定向。
9. 将静态内容拆分为CDN，或改善连接性
10. 添加更多硬件（嗯，我们不得不在某个时候说出来）

因此，请牢记这一点-您将看到可能不会有Nginx配置文件，PHP fcgi池配置文件，MySQL配置文件或Varnish配置文件。加上硬件本身的改变；可用的内存，I / O性能（HDD和网络）和CPU-您会发现存在一些细微的变化，可以实现所需的400％性能提高-但是没有一个快速的答案可以在网上轻松找到。

您可以复制并粘贴Peer 1赞助的有关性能的Magento白皮书（我们不建议这样做）；希望这些设置不要超出您的可用内存，线程限制，TCP / IP状态，I / O容量，并导致性能不如原始Apache / mod_php配置低。

因此，让我们继续。

理想的Magento服务器堆栈

这更有可能使您更接近现实。演示这一点的一个好例子是展示如何配置专用的Magento OS MageStack

采取单独的子组件，如果正确配置，您将获得运行Magento商店的最佳/关键软件列表。值得注意的是：

防火墙，DOS过滤器，负载均衡器，Varnish，Nginx，PHP，Redis，Memcached，MySQL

所以当你问：

什么是最佳的Magento服务器设置？

您的目标到底是什么？

1. 高可用性
2. 可靠性
3. 管理简便
4. 性能
5. 可扩展性

足够的演讲，我们将如何做

为了部分反映服务器故障所给出的答案，类似的思路。您拥有3台服务器供您使用-因此首先将它们最佳定位。我们将避免使用高度可用的解决方案，因为这远远超出了此答案的范围。

多服务器配置所需的子组件为：

• 防火墙功能
• 负载均衡器
• 网络服务器
• MySQL服务器
• 普通储存

因此，我们将多用途一些系统。PCI-DSS的合规性决定了每个服务器的角色。因此，如果有5个角色和3个服务器，您将立即受到侵害。MageStack通过使用虚拟化解决了这一问题- 您可以做同样的事情。

服务器1：负载均衡器+ Web服务器
服务器2：Web服务器
服务器3：数据库服务器

没有低延迟和显着的网络带宽（> 1Gbps，<125µs），而不是具有公共存储-更好的是，您可以将存储根目录仅存储在每台计算机上，并使用ionotify或实时使用复制数据一个cron工作。同样，我们将避免使用网络文件系统（例如NFS）或复制的块设备（例如Gluster或DRBD），因为需要大量的调整和合理的网络带宽。

清漆需要尽可能靠近前部放置。但是Varnish无法解密SSL。因此，将其与SSL终止符结合在一起；Nginx，Pound，Stunnel，Stud等。Varnish中内置的负载平衡器不是很好-但是对于2台服务器的设置来说已经足够了。

Nginx + PHP-FPM很好，但是不要喝太多的Nginx助剂。它的性能几乎与传统的Apache / mod_php配置相同，这里有一些关于为什么不使用Nginx的很好的读物。Nginx很好，实际上很好，但是它肯定不是Magento商店的瓶颈-鉴于它的复杂性和缺乏本地Magento支持。大多数新手系统管理员都将从使用Apache / mod_php而不是其他任何东西中受益。与使用PHP-FPM相比，这似乎是一个过时的建议-但我们的性能测试表明，使用Nginx解决方案时，性能仅提高了7％左右- 如果配置正确，。高性能，可靠的Nginx / PHP-FPM设置所需的调优和经验非常丰富，足以使其胜过Apache / mod_php。不论您选择使用哪个电话。

数据库服务器很简单，MySQL。但是，如前所述，如果您的网站转换率很高，建议使用主/从配置。通过阅读本文可以确定是否应采用这种方法。

然后是外围后端缓存，即Memcached和Redis。在较小的商店中，将会话存储在一个Memcache实例中，将快速后端缓存存储在另一个实例中将带来良好的性能优势。我们不主张将缓存标签存储在一个缓慢的后端中-因为它导致的问题多于所给的问题。因此，使用Memcached设置时，您将不得不放弃缓存标记。相反，我们使用喜欢的配置这样。

Redis并不是Magento的本地人，但是通过Colin Mollenhour的扩展-比Memcache更好的解决方案，它支持缓存标签，会话存储甚至持久性缓存存储- 它不如Memcache易变。但是它确实有缺点。我们发现在大型生产商店（> 500个订单/小时，> 30,000个不重复/小时）中，缓存（和标签）可以很快填满，一旦达到饱和点，LRU机制就会有些失败（尽管设置不同，但会立即导致巨大的瓶颈。因此，谨慎地定期手动删除旧记录。

那么应该使用什么硬件呢？

Web服务器：最快的CPU，最多的CPU内核，2GB RAM的比率/核心
DB服务器：最快的CPU，最快的磁盘I / O，最多的RAM

因此，当多用途您的3台机器时，最佳布局是：

服务器1：SSL终结器->清漆-> Nginx / Apache> PHP
服务器2：Nginx / Apache> PHP，Redis，（MySQL Slave）
服务器3：MySQL

至于每个应用程序的具体配置。嗯，这取决于您的硬件规格，商店的复杂性，访客的类型和性质以及访客的数量。

使用该集群配置，您将走上一条美好的道路。我建议为Redis添加专用的缓存主机；选择一个具有较高CPU能力和大量RAM（〜64 GB）的设备。

这是我用于高可用性，容错，分布式和负载平衡的LEMP群集的配置的完整列表。它包括app/etc/local.xml，core_config_data表和MySQL，php-fpm，nginx和Redis的配置。全部运行64位Ubuntu 12.04 LTS。这些配置包括许多优化而没有缺点。

强调

• 管理员用户：46
• 类别：2,450（最大的类别有2,400个产品）
• 产品实体：101,000
• 组合产品：484
• 产品关系：54,000
• 有库存和已启用的可配置产品：10,100
• CMS区块：3,100
• CMS页面：1,400

2013年8月的流量：

• 每月浏览量4000万
• 230万独立访客
• 每月结账46,000次
• 89％的美国游客

网络主机

冗余，高可用性的硬件防火墙和硬件负载平衡器后面有10台主机。大多数静态资产都已转移到CDN。

• 全站平均响应时间：282毫秒
• FPC平均响应：48毫秒
• 平均负载：0.6到1.0（在测试中，平均负载达到约5.0时性能下降35％）
• 双Intel Xeon CPU E3-1230 V2 @ 3.30GHz（每个4核）
• 32 GB DDR3 1333 MHz RAM

模组

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = models
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = production
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

缓存主机

有两台主机在具有自动故障转移功能的主从配置中运行Redis。三个Redis实例（会话，后端和FPC）用于增加吞吐量并提供对持久性行为的微调。

• 每秒3,000个命令
• 平均响应时间0.7毫秒
• 平均负载为1.0到1.5
• 四核Intel Xeon CPU E5-2620 0 @ 2.00GHz（每个6核）
• 128 GB缓冲DDR3 1333 MHz RAM
• 机械磁盘，RAID 1，硬件控制器

数据库主机

有两台主机在具有热故障转移的主从配置中运行MySQL 5.6.11。

• 每秒1,500个命令
• 平均响应时间1.1毫秒
• 平均负载0.1（主）和0.4（从）
• 四核Intel Xeon CPU E7-2860 @ 2.27GHz（每个10核）
• 128 GB缓冲DDR3 1333 MHz RAM
• SSD，RAID 1 + 0，硬件控制器
• 带有tcmalloc的MySQL 5.6.11

Magento的另一个必须具备的服务器提示是使用OPcache安装PHP 5.4或5.5 。PHP 5.4比5.3快得多（http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/）。

我想添加另一个重要提示，即当未由清漆缓存且默认情况下未启用时（未将购物车页面加载时间从6sc更改为1.5sc），提高了magento页面的速度。

在/etc/mysql/my.conf中激活mysql查询缓存

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type启用它，缓存大小是内存中缓存使用的值，缓存限制是要缓存的查询结果的最大大小

使用我们当前的配置，我们将在400毫秒内收到初始响应，并在2秒内完成文档的建立（使用5mbps的标准连接）。我们的首页大小为1mb。

我们的设置基于AWS，如下所示：我们有一个ec2实例，其中的负载均衡器连接到RDS数据库（具有故障转移）。我们还实现了带有Redis缓存后端的全页缓存，用于缓存存储和会话存储。

平均而言，我们每天有300-400位访客，但是启用了Redis缓存后，我们在保持速度和降低成本的同时最小化了ec2资源的使用。

我们有一个负载平衡器的原因是，如果极有可能我们遇到了当前设置无法处理的流量高峰，则ec2会设置为自动启动新实例。