Um, esa es una gran caja para un sitio de WordPress. Incluso para un sitio de WordPress realmente grande. Tan breve respuesta, sí. Es suficiente.
- Saltar barniz.
- Use Nginx para activos estáticos. Utilice el almacenamiento en caché de Nginx (ReverseProxyCachingExample)
- El almacenamiento en caché de nginx utiliza una técnica similar al barniz. Probablemente no notará la diferencia de rendimiento. Notará la diferencia al determinar los mejores tiempos de caché, la mejor caducidad de caché, etc. Intente configurar sus tiempos de caché en 1 segundo. Significará que su servidor solo necesitará manejar 1 req / seg ya que la mayoría de HTTP GET será de la caché. Nginx es realmente inteligente, cuando se invalida el caché, puede servir los datos obsoletos mientras se actualiza el caché desde WordPress / PHP.
- Salta Apache.
- Use PHP-FPM, haga que nginx le hable a través de un socket Unix. Te ahorras la RAM de apache. Se ahorra el TCP / IP de arriba (sí, todavía hay algo cuando se habla con localhost) de proxy a localhost. (PHPFcgiExample)
- Base de datos, ¿tiene más de 2 GB de publicaciones en el blog? Si no, realmente no importa si está en la misma caja. Suponiendo WordPress + MySQL, incluso puede hacer que PHP se conecte al socket unix de mysql. Nuevamente guardando la sobrecarga de TCP.
- Hecho. Ve a servir 2000 + / req / seg ahora. 🙂
Editar
Oh, me perdí el cpanel requiere. Pero un rápido google reveló: Instalar php-fpm para Cpanel
- ¿Cuáles son las desventajas de ejecutar una aplicación web en Solaris?
- Cómo reemplazar un servidor de archivos
- ¿Qué son exactamente los servidores que usan los hackers?
- ¿Qué tan importante es donde se encuentra el servidor de alojamiento?
- Estoy trabajando en una prueba de concepto para la aplicación que combina soluciones de almacenamiento en la nube para las que se suscribió y las presenta como una sola unidad: las opciones incluyen la configuración como RAID + algunas otras ideas. ¿Lo suficientemente interesante como para proceder como un proyecto nocturno o no?
