La optimización de Kohana Sitios web basados en la Velocidad y la Escalabilidad

https://stackoverflow.com/questions/1260134

12-09-2019
|

Pregunta

Un sitio que he construido con Kohana se estrelló con una enorme cantidad de tráfico ayer, haciéndome dar un paso atrás y evaluar algunos de los diseños.Tengo curiosidad ¿cuáles son algunas de las técnicas estándar para la optimización de Kohana basado en las aplicaciones?

Estoy interesado en el benchmarking, así.Qué necesito para instalar Benchmark::start() y Benchmark::stop() para cada controlador-método para ver los tiempos de ejecución para todas las páginas, o soy capaz de aplicar el benchmarking a nivel mundial y rápidamente?

Me va a utilizar el Caché de biblioteca de más en el tiempo por venir, pero estoy abierto a más sugerencias de como estoy seguro de que hay mucho que yo pueda hacer que yo soy, simplemente, no es consciente de que en el momento.

Solución

Lo que voy a decir en esta respuesta no es específica a Kohana, y probablemente puede aplicar a un montón de proyectos PHP.

Aquí están algunos puntos que me vienen a la mente cuando hablamos de rendimiento, escalabilidad, PHP, ...
He usado muchas de esas ideas mientras se trabaja en varios proyectos, y la ayudó;así que, probablemente, podría servir también de ayuda.

Primero de todo, cuando se trata de actuaciones, hay muchos de los aspectos o preguntas que se van a considerar:

configuración del servidor (Apache, PHP, MySQL, otros posibles demonios, y del sistema);usted puede obtener más ayuda acerca de que en ServerFault, Supongo,
Código PHP,
Consultas de base de datos,
El uso o no de tu servidor web?
Se puede utilizar cualquier tipo de mecanismo de almacenamiento en caché?O ¿necesita siempre más que hasta la fecha los datos en la web?

El uso de un proxy inverso

La primera cosa que podría ser muy útil es el uso de un proxy inverso, como barniz, en frente de tu servidor web:deje que se caché de tantas cosas como sea posible, por lo que sólo las solicitudes que realmente necesita PHP/MySQL cálculos (y, por supuesto, algunas otras peticiones, cuando no están en la caché del proxy) hacer que Apache/PHP/MySQL.

Primero de todo, tu CSS/Javascript/Imágenes -- bien, todo lo que es estática -- probablemente no tenga que ser siempre por Apache
- Así, usted puede tener el proxy inverso de la caché de todos los.
- Servir los archivos estáticos no es la gran cosa para Apache, pero al menos se ha de trabajar para los, más será capaz de hacer con PHP.
- Recuerde:Apache servidor sólo un número finito, limitado, el número de solicitudes en un tiempo.
A continuación, tiene el proxy inverso de servir como muchos PHP en páginas como sea posible de la caché:probablemente hay algunas de las páginas que no cambian a menudo, y podría ser servido desde la caché.En lugar de utilizar algunos basada en PHP cache, ¿por qué no vamos a otro, más ligero, servidor de servir a los (y traerlos desde el PHP del servidor de tiempo en tiempo, por lo que siempre están casi hasta la fecha)?
- Por ejemplo, si usted tiene algunos feeds RSS (En general, tienden a olvidarse de esas, cuando tratando de optimizar para presentaciones) que se solicita muy a menudo, teniendo en caché durante un par de minutos podría ahorrar cientos/miles de solicitud de Apache+PHP+MySQL!
- Mismo para las páginas más visitadas de su sitio, si no cambian durante al menos un par de minutos (ejemplo:página de inicio?), entonces , no hay necesidad de perder CPU de generación de re-cada vez que un usuario solicita ellos.
Tal vez hay una diferencia entre las páginas servido para usuarios anónimos (la misma página para todos los usuarios anónimos) y las páginas que sirve para identificar a los usuarios ("Hello Mr X, usted tiene mensajes nuevos", por ejemplo)?
- Si es así, usted probablemente puede configurar el proxy inverso de la caché de la página a la que se sirve para usuarios anónimos (basado en una cookie, como la cookie de sesión, normalmente)
- Que va a decir que Apache+PHP tiene menos que se ocupan de:sólo usuarios identificados-que podría ser sólo una pequeña parte de sus usuarios.

Acerca de el uso de un proxy inverso como caché, para una aplicación de PHP, usted puede, por ejemplo, echar un vistazo a Resultados de la evaluación Muestran 400%-700% de Incremento En las Capacidades del Servidor con APC y Caché Squid.
(Sí, ellos están usando Squid, y yo estaba hablando acerca de barniz ... es sólo otra posibilidad ^^ Barniz de ser más reciente, pero más dedicado a la memoria caché)

Si lo haces lo suficientemente bien, y gestionar para detener la generación de re-demasiadas páginas una y otra vez, tal vez usted ni siquiera tiene que optimizar cualquiera de su código ;-)
Al menos, tal vez no en ningún tipo de prisa...Y siempre es mejor realizar las optimizaciones cuando no están bajo mucha presión...

Como una nota al margen:usted está diciendo en el OP:

Un sitio que he construido con Kohana se estrelló con una enorme cantidad de tráfico ayer,

Este es el tipo de repentino de la situación en la que un proxy inverso puede, literalmente, salvar el día, si su sitio web se puede lidiar con no siendo hasta la fecha por el segundo:

instalar, configurar, que siempre -- cada día normal -- ejecutar:
- Configurarlo para que no se mantenga el PHP de las páginas en caché;o sólo por una corta duración;de esta manera, usted siempre tiene datos actualizados de la muestra
Y, el día que tome un slashdot o digg efecto:
- Configurar el proxy inverso para mantener las páginas de PHP en caché;o por un largo período de tiempo;tal vez sus páginas no será hasta la fecha por el segundo, pero le permitirá a su sitio web para sobrevivir a la digg-efecto!!!!

Acerca de que, ¿Cómo puedo detectar y sobrevivir a ser "Slashdotted"? puede ser una lectura interesante.

En el PHP del lado de las cosas:

Primero de todo:utilizando un la versión más reciente de PHP?Hay regularmente mejoras en la velocidad, con nuevas versiones ;-)
Por ejemplo, echa un vistazo a Punto de referencia de PHP Ramas 3.0 a través de 5.3-CVS.

Tenga en cuenta que las actuaciones es bastante una buena razón para utilizar PHP 5.3 (He hecho algunos puntos de referencia (en francés), y los resultados son excelentes)...
Otra muy buena razón de ser, por supuesto, que con PHP 5.2 ha alcanzado el final de su vida, y no se mantiene más!

Están usando ningún código de operación (opcode cache?

Estoy pensando en APC - Alternative PHP Cache, por ejemplo (pecl, manual), cual es la solución que he visto la que más utiliza-y que se utiliza en todos los servidores en los que he trabajado.
- Vea también: Diapositivas de APC en Facebook,
- O Resultados de la evaluación Muestran 400%-700% de Incremento En las Capacidades del Servidor con APC y Caché Squid.
Realmente se puede bajar la CPU de la carga de un servidor mucho, en algunos casos (He visto la CPU de carga en algunos servidores van del 80% al 40%, con sólo instalar APC y la activación del código de operación de la caché de funcionalidad!)
Básicamente, la ejecución de un script de PHP que va en dos pasos:
- Compilación de PHP de código fuente con códigos de operación (una especie de equivalente de JAVA bytecode)
- La ejecución de los códigos de operación
- APC mantiene a aquellos en la memoria, por lo que hay menos trabajo que hacer cada vez que un script PHP/archivo, se ejecuta:sólo obtener los códigos de operación de RAM, y ejecutarlas.
Usted puede ser que necesite para echar un vistazo a APC opciones de configuración, por cierto ,
- hay muy pocos de esos, y algunos pueden tener un gran impacto en la velocidad / de la CPU de carga y facilidad de uso para usted
- Por ejemplo, la desactivación de [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat) puede ser bueno para el sistema de carga;pero significa que las modificaciones realizadas en los archivos PHP no se toman en cuenta, a menos que vaciar todo el código de operación-caché;acerca de que, para más detalles, véase, por ejemplo, A stat() O No stat()?

El uso de la caché de datos

Tanto como sea posible, es mejor evitar hacer la misma cosa una y otra vez.

La principal cosa que estoy pensando es, por supuesto, las Consultas SQL:muchas de sus páginas, probablemente, hacer las mismas preguntas, y los resultados de algunos de los que probablemente es casi siempre la misma...Lo que significa un montón de "inútil" las consultas realizadas a la base de datos, que tiene que pasar tiempo al servicio de los mismos datos una y otra vez.
Por supuesto, esto es cierto para otras cosas, como los Servicios Web de llamadas, captura de información desde otros sitios web, pesados cálculos, ...

Podría ser muy interesante para usted para identificar:

Las consultas que se ejecutan muchas veces, siempre volviendo a los mismos datos
Que otros (pesado) los cálculos se hacen un montón de tiempo, que siempre devuelve el mismo resultado

Y almacenar estos datos/resultados en algún tipo de caché, por lo que son más fáciles de obtener ... más rápido -- y usted no tiene que ir a su servidor SQL server para "nada".

Gran mecanismos de almacenamiento en caché son, por ejemplo:

APC:además el código de operación-caché del que les hablé antes, que permite almacenar datos en la memoria,
Y/o memcached (ver también), el cual es muy útil si usted literalmente muchas de datos y/o se el uso de múltiples servidores, como se distribuye.
por supuesto, usted puede pensar acerca de los archivos;y probablemente muchas otras ideas.

Estoy bastante seguro de su marco viene con algunos relacionados con la memoria caché cosas;usted probablemente ya sabe que, como dijo "Voy a ser el uso de la Caché de biblioteca de más en el tiempo por venir" en la OP ;-)

Perfiles

Ahora, una buena cosa a hacer sería el uso de la Xdebug extensión el perfil de su aplicación:a menudo permite encontrar un par de débil puntos con bastante facilidad, al menos, si hay alguna función que toma un montón de tiempo.

Configurado correctamente, se generan perfiles de archivos que pueden ser analizados con algunas herramientas gráficas, tales como:

KCachegrind:mi favorito, pero sólo funciona en Linux/KDE
Wincachegrind para windows;hace un poco menos cosas de KCacheGrind, por desgracia -- no se muestra callgraphs, normalmente.
Webgrind que se ejecuta en PHP de la web, así que funciona en cualquier lugar-pero probablemente tiene menos funciones.

Por ejemplo, aquí hay un par de capturas de pantalla de KCacheGrind:

_{(fuente: pascal-martin.fr)}

_{(fuente: pascal-martin.fr)}

(Por CIERTO, el callgraph presentado en la segunda captura de pantalla es normalmente algo que ni WinCacheGrind ni Webgrind puede hacer, si no recuerdo mal ^^ )

(Gracias @Mikushi por el comentario) Otra posibilidad que no he usado mucho es el de la xhprof extensión :también ayuda con la elaboración de perfiles, puede generar callgraphs -- pero es más ligero que el Xdebug, que significa que usted debería ser capaz de instalar en un servidor de producción.

Usted debe ser capaz de utilizar alonside XHGui, que será de ayuda para la visualización de los datos.

En el lado SQL de cosas:

Ahora que hemos hablado un poco acerca de PHP, tenga en cuenta que es más que posible que su cuello de botella no es el PHP del lado de las cosas, pero la base de datos de...

Al menos dos o tres cosas, aquí:

Usted debe determinar:
- ¿Cuáles son los más frecuentes en las consultas de la aplicación que está haciendo
- Si esos son optimizados (el uso de la derecho de los índices de, principalmente?), utilizando el EXPLAIN la instrucción, si usted está usando MySQL
  - Vea también: La optimización de SELECCIONAR y Otras Declaraciones
  - Usted puede, por ejemplo, activar log_slow_queries para obtener una lista de las solicitudes que tomar "demasiado" tiempo y comenzar con la optimización de aquellos.
- si usted podría caché de algunas de estas consultas (ver lo que he dicho antes)
Es MySQL, bien configurado?No sé mucho sobre eso, pero hay algunas opciones de configuración que podrían tener algún impacto.
- Optimizar el Servidor de MySQL podría dar algunas informaciones interesantes acerca de eso.

Aún así, las dos cosas más importantes son:

No ir a la base de datos si no es necesario: caché tanto como usted puede!
Cuando usted tiene que ir a la base de datos, el uso eficiente de las consultas:el uso de índices;y de perfil!

¿Y ahora qué?

Si usted todavía está leyendo, ¿qué otra cosa podría ser optimizado?

Bueno, todavía hay espacio para mejoras...Un par de arquitectura orientada a ideas podrían ser:

Cambiar a una arquitectura de n niveles:
- Poner MySQL en otro servidor (Nivel 2:uno de PHP;el otro para MySQL)
- El uso de varios servidores PHP (y balancear la carga de los usuarios entre esos)
- El uso de otras máquinas para los archivos estáticos, con un encendedor, servidor web, como:
  - lighttpd
  - o nginx -- esta es cada vez más y más popular, por cierto.
- Utilizar varios servidores para MySQL, varios servidores de PHP, y varios reverse-proxy delante de los
- Por supuesto:instalar memcached demonios en cualquier servidor tiene cualquier cantidad de memoria RAM libre, y utilizarlos para almacenar en caché tanto como usted puede / tiene sentido.
El uso de algo "más eficiente" que el Apache?
- Escucho más y más a menudo nginx, que se supone debe ser grande cuando se trata de PHP y de alto volumen de sitios web;Yo nunca he usado yo, pero es posible encontrar algunos interesantes artículos sobre él en la red;
  - por ejemplo, Rendimiento PHP III: Ejecución de nginx.
  - Vea también: PHP-FPM - FastCGI Administrador de Procesos, incluido con PHP >= 5.3.3, y hace maravillas con nginx.

Bueno, tal vez algunas de esas ideas son un poco excesivo en su situación ^^
Pero, aún así...¿Por qué no estudiar un poco, sólo en el caso ?;-)

¿Y qué acerca de Kohana?

Su primera pregunta fue acerca de la optimización de una aplicación que utiliza Kohana...Bueno, he publicado algunos ideas que son verdaderas para cualquier aplicación PHP...Lo que significa que son verdaderas para Kohana demasiado ;-)
(Incluso si no se concreta, a ella ^^)

Me dijo:el uso de la caché;Kohana parece apoyar algunos almacenamiento en caché de cosas (Hablado acerca del mismo, así que no hay nada nuevo aquí...)
Si hay algo que se puede hacer rápidamente, probarlo ;-)

También me dijo que no se debería hacer nada que no sea necesario;no hay nada activado por defecto en Kohana que usted no necesita?
Navegando por la red, parece que hay al menos algo acerca de filtrado XSS;¿necesita eso?

Aún así, he aquí un par de enlaces que pueden ser útiles:

Conclusión?

Y, para concluir, un simple pensamiento:

¿Cuánto va a costar a su empresa a pagar de 5 días? -- teniendo en cuenta que es una cantidad razonable de tiempo para hacer algunos grandes optimizaciones
¿Cuánto va a costar a su empresa a comprar (pagar?) un segundo servidor, y su mantenimiento?
Lo que si tiene a gran escala?
- ¿Cuánto va a costar a pasar 10 días?más?la optimización de cada posible poco de tu aplicación?
- Y cuánto por un par de servidores?

No estoy diciendo que usted no debe optimizar:definitivamente, usted debe!
Pero ir "rápido" optimizaciones que le permitan obtener grandes recompensas primero:el uso de algunos opcode cache puede ayudarle a obtener entre el 10 y el 50 por ciento de descuento en la CPU del servidor de carga...Y sólo se tarda un par de minutos para configurar ;-) Por otro lado, el gasto de 3 días para 2 por ciento...

Ah, por cierto:antes de hacer nada: poner algo de monitoreo cosas en su lugar, para que sepas de qué mejoras se han hecho, y cómo!
Sin supervisión, usted no tiene idea de que el efecto de lo que hizo...No, incluso si se trata de una optimización real o no!

Por ejemplo, usted podría usar algo como RRDtool + cactus.
Y mostrar a su jefe unos buenos gráficos con un 40% de la CPU de la carga de la gota es siempre grande ;-)

De todos modos, y para concluir: divertirse!
(Sí, la optimización es divertido!)
(Ergh, no pensé que iba a escribir mucho...Espero al menos en algunas partes de este son útiles...Y debo recordar que esta respuesta:podría ser útil que otras veces...)

Otros consejos

Utilice XDebug y o href="http://code.google.com/p/webgrind/" rel="nofollow noreferrer"> WebCacheGrind para perfilar y analizar la ejecución de código lento.

_{(fuente: jokke.dk )}
WinCacheGrind

XDebug .

Utilice una gran cantidad de almacenamiento en caché. Si las páginas son relativamente estática, entonces el proxy inverso podría ser la mejor manera de hacerlo.

Kohana está fuera de la caja muy muy rápido, excepto por el uso de objetos de bases de datos. Para citar Zombor "Usted puede reducir el uso de memoria al asegurar que está utilizando el objeto resultante de la base de datos en lugar de matrices de resultados." Esto hace una diferencia de rendimiento hugee en un sitio que está siendo cerró. No sólo se utilizan más memoria, se ralentiza la ejecución de scripts.

También - debe utilizar el almacenamiento en caché. Yo prefiero Memcache y lo uso en mis modelos como esto:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

Esto también aumentará drásticamente el rendimiento. Las dos técnicas anteriores mejoraron un rendimiento sitios en un 80%.

Si usted dio un poco más de información acerca de dónde cree que el cuello de botella es, estoy seguro de que podríamos darle algunas ideas mejores.

También puedes ver YSlow (google) para algunos otros consejos de rendimiento.

estrictamente relacionadas con Kohana (es probable que ya haya hecho esto, o no):

En el modo de producción:

Habilitar caché interna (esto sólo caché el Kohana :: find_file resultados, pero en realidad esto puede ayudar mucho.
Desactivar perfiles

Sólo mi 2 centavos:)

Estoy totalmente de acuerdo con la XDebug y respuestas de almacenamiento en caché. No mire directamente a la capa de Kohana para la optimización hasta que haya identificado sus mayores velocidad y la escala cuellos de botella.

XDebug le dirá donde usted pasa la mayor parte de su tiempo e identificar los 'puntos calientes' en el código. Mantener esta información de perfil para que pueda base y medir las mejoras de rendimiento.

problema Ejemplo y solución: Si usted encuentra que usted está construyendo objetos caros de la base de datos cada vez, que en realidad no cambian a menudo, a continuación, se puede ver en el almacenamiento en caché con memcached u otro mecanismo. Todas estas correcciones de rendimiento toman tiempo y añadir complejidad al sistema, así que asegúrese de sus cuellos de botella antes de empezar la fijación de ellos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow