在 EC2 中加载 php 类的最佳方法 - InstanceStore、EBS 或 S3? [英] Best way to load php classes in EC2 - InstanceStore, EBS or S3?

问题描述

在以下场景中，在 EC2 中加载 PHP 类的最佳方法是什么(# 用于说明目的)?-> 100 个运行 apache 和 APC 的 EC2 实例-> 每个请求加载 100 个 php 类(通过 __autoload)-> 类之间每天 100 次代码更改(许多类包含自动生成的代码，这些代码通过 cron 定期更新).

What is the best way to load PHP classes in EC2 in the following scenario (#s are for illustrative purposes)? -> 100 EC2 instances running apache and APC -> 100 php classes loaded per request (via __autoload) -> 100 code changes per day between the classes (many of the classes contain auto-generated code that are periodically updated via cron).

据我所知，有 3 种方法可以在 EC2 中加载 php 类文件:

From what I gather, there are 3 ways to load the php class files in EC2:

A. InstanceStore - The local (virtual) hard drive of an EC2 instance
-> Code must be pushed separately to each instance.
-> Fastest loading since no need to go over the network

B. EBS - A volume mounted to a particular instance
-> Code must be pushed separately to each instance.
-> Slower loading since go over the network

C. S3 - A S3 bucket can be 'mounted' to 1 or more EC2 instances
-> Code only needs to be pushed once
-> Slowest loading since go over the network

即使在 apache 实例上启用了 APC，我也无法在 APC 中禁用 fstat，因为我不确定如何处理所有 100 个 apache 实例上缓存类的失效问题，每天 100 多次(当代码更改时).因此，如果每个类加载都会生成对文件系统的调用，即使该类被 apc 缓存(执行 fstat 调用)，如果通过网络进行 100 次往返来执行 fstat，不会有巨大的延迟还是在每次请求时读取文件?

Even with APC enabled on the apache instances, I am not able to disable fstat in APC due to being unsure of how to handle the invalidation of the cached classes on all 100 apache instances 100+ times a day (when code changes). As a result, if each class load will generate a call to the filesystem even if the class was cached by apc (to do the fstat call), wouldn't there be huge latency if there were 100 round trips over the network to do fstat or read the file on every request?

在所描述的场景中加载类文件的最佳选择是什么(或者可能是此处未列出的新方法)?

What is the best option (or maybe a new way that is not list here) to load class files in the scenario described?

推荐答案

始终使用 EBS 支持的实例.重复:始终使用 EBS 支持的实例.

Always use an EBS backed instance. Repeat: Always use an EBS backed instance.

当需要应用代码更改时，从当前实例的快照启动一个新的 EBS 支持的实例.暂时不要将其添加到您的负载平衡器中.

When code changes need to be applied, spin up a new EBS backed instance from a snapshot of the current one. Do not add it to your load balancer yet.

应用代码更改.

创建一个新的 EBS 快照.这是您当前轮次代码更改的黄金标准快照.

Create a new EBS snapshot. This is your gold standard snapshot for the current round of code changes.

根据需要从新的黄金标准快照启动新的 EBS 支持的实例.

Launch new EBS-backed instances as needed from the new gold standard snapshot.

运行一个脚本，在新实例上访问您的网站，这些实例尚未占用实际流量，以预热它们(将 PHP 类加载到 APC 中).

Run a script that hits your website on the new instance(s), which are not yet taking real traffic, to warm them up (get the PHP classes loaded into APC).

切换您的负载均衡器，以便新实例获取所有实时流量.

Switch your load balancer so that the new instances are taking all live traffic.

终止旧实例.

所有这些都可以而且应该通过更新脚本自动完成.确保并在整个过程中在脚本中包含错误检查(例如，由于可用区中的资源限制，我偶尔无法启动新实例).

All of this can and should be automated with an update script. Be sure and include error checking in your script along the way (for example, I have occasionally been unable to fire up a new instance due to resource constraints in the availability zone).

根据需要创建和销毁新实例的能力是云的一大优点.

The ability to create and destroy new instances as needed is one of the wonderful things about the cloud.

这篇关于在 EC2 中加载 php 类的最佳方法 - InstanceStore、EBS 或 S3?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！