php - putobject - s3client

¿La mejor manera de cargar clases php en EC2-InstanceStore, EBS o S3?

Question

¿Cuál es la mejor forma de cargar clases PHP en EC2 en el siguiente escenario (los # son para fines ilustrativos)? -> 100 instancias EC2 ejecutando Apache y APC -> 100 clases php cargadas por solicitud (a través de __autoload) -> 100 cambios de código por día entre las clases (muchas de las clases contienen código generado automáticamente que se actualiza periódicamente a través de cron).

Por lo que veo, hay 3 formas de cargar los archivos de la clase php en 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

Incluso con APC habilitado en las instancias de apache, no puedo deshabilitar fstat en APC debido a que no estoy seguro de cómo manejar la invalidación de las clases en caché en las 100 instancias de apache más de 100 veces al día (cuando el código cambia). Como resultado, si cada carga de clase generará una llamada al sistema de archivos, incluso si la clase fue almacenada en caché por la APC (para hacer la llamada fstat), ¿no habría una gran latencia si hubiera 100 viajes redondos por la red para hacer fstat? o leer el archivo en cada solicitud?

¿Cuál es la mejor opción (o tal vez una nueva forma que no está en la lista aquí) para cargar archivos de clase en el escenario descrito?

Answer 1

¿Has pensado en serializar el objeto y poner todo el objeto en la memoria caché de la AP o ponerlo en algo así como memcached?

Answer 2

Siempre use una instancia respaldada por EBS . Repita: utilice siempre una instancia respaldada por EBS.

Cuando se deben aplicar cambios de código, active una nueva instancia respaldada por EBS a partir de una instantánea de la actual. No lo agregue a su equilibrador de carga todavía.

Aplicar cambios de código.

Crea una nueva instantánea de EBS. Esta es su instantánea estándar dorada para la ronda actual de cambios de código.

Lanzar nuevas instancias respaldadas por EBS según sea necesario de la nueva instantánea estándar dorada.

Ejecute un script que llegue a su sitio web en la (s) nueva (s) instancia (s), que todavía no están tomando tráfico real, para calentarlos (obtenga las clases PHP cargadas en APC).

Cambie su equilibrador de carga para que las nuevas instancias estén tomando todo el tráfico en vivo.

Termine las instancias antiguas.

Todo esto puede y debe automatizarse con un script de actualización. Asegúrese e incluya la comprobación de errores en su secuencia de comandos en el camino (por ejemplo, en ocasiones no he podido iniciar una nueva instancia debido a las limitaciones de recursos en la zona de disponibilidad).

La capacidad de crear y destruir nuevas instancias según sea necesario es una de las cosas maravillosas de la nube.