En busca de la velocidad, por que no uso Varnish con Prestashop 1.5

[folvera6]

Hola a todos,

 

Primero y antes que nada que quede bien claro que esta es una opinión personal y no remplaza la opinión de ningún experto.

 

Comenzamos,

 

Hace algunos meses que tengo una tienda con Prestashop 1.5.4.1 esta trabaja bajo servidores privados virtuales con las siguientes características:

 

Servidor HTTP + PHP:

OS: Centos 6.4 x86_64

Tecnología: nginx 1.4.2 + php-fpm (PHP -v 5.5.1)

vCPU's: 3

RAM: 4GB

HD: 70GB SSD (PS) + 350GB en RAID10 (Backups)

Red: 1GB (Sonera)

 

Servidor BD*:

OS: Debian 7 x86_64

Tecnología: MySQL 5.6.11

vCPU's: 3

RAM: 3GB

HD: 50GB SAS (BD)

Red: 1GB (Sonera)

 

Trafico diario: 10000vu**

 

*Servidor compartido con opencart

**Visitantes únicos

 

Curiosamente el desempeño en cuestión de velocidad con Prestashop no era suficientemente bueno y en base a mi experiencia un sitio de comercio electrónico que no despliega de manera prácticamente instantánea (800ms a 1.8s) pierde potenciales compradores, el tema aqui es que despues de haber optimizado prácticamente al 100% prestashop incluso haciendo uso de CDN's como cloudfront, OnApp, MaxCDN no lograba reducir el tiempo de carga a menos de 3s es aqui cuando empezamos a analizar el uso de un proxy inverso, di con muchas alternativas, entre ellas Varnish, lo uso con servidores Apache pero nunca había necesitado hacer uso de un proxy inverso con nginx, configuré el cache de varnish con nginx y ¡oh sorpresa! el sitio cargaba mas lento de lo que pudiera imaginar e incluso dando timeouts, de inmediato pensé algo debía haber hecho mal, analice las configuraciones e incluso probé con otras aplicaciones y di con la gran sorpresa de que el problema no estaba con varnish.

 

Duré varios días probando configuraciones distintas en varnish, aunque para ser honesto nunca se me ocurrió revisar como es que funcionaba prestashop así que esos días fueron prácticamente una perdida de tiempo. Hasta hace 2 días me puse a revisar el código de prestashop y fue cuando me tope con pared ya que este esta escrito casi tan complicado como magento, así que por mas que trataba de descifrar como funcionaba la entrega de contenidos y como se hacen las peticiones para renderizar la pagina abandone la causa.

 

Lo único que pude hacer es deshabilitar varnish y dejar el tiempo de carga como estaba, lamentablemente la tasa de conversión que tengo con prestashop no es tan buena como la de mi tienda con opencart, pero también hay que ser honestos opencart no es tan completo como prestashop.

 

Cualquier comentario es bien recibido y les recuerdo que esto solo es mi humilde opinión basada en mi experiencia.

[bluecarbon]

Hola,

 

No indicas que tipo de cache estas utilizando, xcache, memcached, apc....,

 

Yo estoy utilizando apc y va muy bien..., es cierto que se fragmenta bastante, pero con 4gb que tienes de ram le puedes asignar 512 Mb exclusivamente.

[Rolige]

Como bien lo acabas de decir, quizá no sepas muy bien como es el funcionamiento interno de PS y puede ser ese el gran detalle.

Mucha de las veces no es el servidor el problema sino el software, y te comento esto porque personalmente he probado versiones de PS desde la 1.3 a la fecha todas en el mismo servidor y claro esta que no todas van igual de rapido, esto es mas que obvio que la programación del software es igual o quizá más importante que un buen servidor.

Para que tengas un buen rendimiento con PS no necesitas ir tan a fondo como el hecho de ver como se generan los tender de las plantillas sino más bien ver que es lo que se esta cargando en cada página que abres, el tamaño de las imágenes, el ripo de consultas a la base de datos, el sistema de cache como bien lo mencionadas y muchas cosas más que quizá no recuerde en este momento. Revisa los módulos que usas, revisa cuales se cargan en el header, hay muchos módulos por ahí que cargan casi todo en el header cuando esto no es necesario y todo eso genera un aumento de carga innecesaria y en algunos casos muy notable, quizá si dieras tu sitio pudiera hechar un vistazo y darte algo más de opinión.

 

Saludos.

[folvera6]

Gracias a todos por responder, para contestar al planteamiento de bluecarbon comento lo siguiente, probé con APC, memcached y xCache con la versión 1.5.4.1 pero el rendimiento caía bastante incluso el "time to first byte" subía de un de por si malo 1.2 a 2.8-2.9, fue cuando investigue si solo me ocurría a mi y di con esto:

 

http://forge.prestashop.com/browse/PSCFV-8899

http://forge.prestashop.com/browse/PSCFV-5225

http://forge.prestashop.com/browse/PSCFV-9242

 

Por esta razón opte por un proxy inverso que cacheara la información, pero el problema lo da la manera en como esta construido Prestashop.

 

Ahora respondiendo al planteamiento de COTOKO, comento, efectivamente no soy un experto de prestashop ni conozco a fondo el funcionamiento de este, pero se como identificar los módulos que puedan estar alentando la tienda para depurar, corregir y optimizar y créeme que si no lo hubiera realizado esto el sitio no cargaría en 3s que es el mejor tiempo de carga que he logrado con prestashop.

 

Pero no nos desenfoquemos del tema principal que es el uso de varnish con prestashop. Agradeceré cualquier comentario y experiencia con estos 2 sistemas.

 

¡Saludos!

[bluecarbon]

si, la cache de prestashop 1.5.4.1 no funciona, hay que actualizar los ficheros desde github, con los ficheros originales a mi también me iba lentísimo, con los nuevos va bien. También he probado varnish pero me fue imposible ajustarlo y que funcionara bien. Pero si lo consigues tendrás una web muy rápida. De momento me conformo con Nginx + apache que ya es bastante.

[Rolige]

Bueno pues en el tema del cache he entrado poco por 2 cosas, la primera es que no cuento con servidor dedicado o semi-dedicado y para cada cosa es tedioso estar hablando a soporte ademas que para algunos cache como memcached es necesario tener al menos un semi-dedicado, lo mas que he usado es el sistema de archivos y me ha ido bien.

Despues de ver los bugtracker que posteaste pues es claro que si existe un fallo en los algoritmos para procesar el cache y como te menciona bluecarbon, podrias probar con los actualizados a la fecha en github.

Cualquier cosa que te resulte para mi y quiza para varios seria muy interesante conocerla, suerte.

[OlivierJM]

Buenas amigo:

 

HD: 70GB SSD (PS) + 350GB en RAID10 (Backups)

 

Decirte que Raid 10 1+0 No es una copia de seguridad, así que realiza backups No me extiendo mas XD

 

Lo segundo comentarte que con lo que tienes de server no se trata de configurar o no un sistema cache, etc... es sin cache y volaria

 

Se puede deber al numero de productos = revisión de base de datos (Segun cantidad, tipo, imagenes, descripciones = modo de trabajo base de datos) + (optimización de la base de datos)

 

Empieza por los siguientes puntos: ¿Para que utilizas un servidor proxi? No entendí la funcionalidad, de echo yo en todos los VPS deshabilito el que trae Plesk de serie (ngnix)

 

Vamos al lió:

 

1- Actualiza el servidor

2- Reinicia Apache y Mysql después de actualizar

3- Revisa y optimiza base de datos (Si es necesario cambia de modo de tablas)

4- Analiza trafico y optimiza Apache para evitar cuellos de botella

5- Configura PHP

6- Configura Apache

 

Un saludo y suerte

 

PDT: Desde Shell escribe: php -v

 

PHP 5.3.10-1ubuntu3.7 with Suhosin-Patch (cli) (built: Jul 15 2013 18:10:56)

Copyright © 1997-2012 The PHP Group

Zend Engine v2.3.0, Copyright © 1998-2012 Zend Technologies

with the ionCube PHP Loader v4.0.14, Copyright © 2002-2011, by ionCube Ltd ., and

with XCache v1.3.2, Copyright © 2005-2011, by mOo

Edited August 15, 2013 by OlivierJM (see edit history)

[nadie]

Tema movido a la sección de:

 

Instalación, configuración y actualización

[folvera6]

Hola OlivierJM,

 

El sistema RAID 1+0 o 10, se tiene como sistema de almacenamiento fijo no como espejos del disco principal, que a través de operaciones programadas cada hora se guarda una imagen del sitio hasta un máximo de 5 de esta manera se elimina un sobre uso de CPU para aprovecharlo en servir contenido, esto sobre todo en horas pico, es muy útil.

 

Con respecto al cache no concuerdo mucho con lo que comentas ya que cuando hay mas de 10000 usuarios conectados simultáneamente con sus respectivas peticiones el servidor debe tener un rendimiento óptimo y el cache de eso se encarga.

 

Las bases de datos son optimizadas cada cierto tiempo se eliminan datos innecesarios y productos que no se tienen en stock desde hace tiempo, usamos InnoDB debido a que MyISAM no seria una opción viable debido al tipo de peticiones. En un tiempo hice pruebas con MariaDB pero no llegue a mucho.

 

El servidor proxy se utiliza como sistema de cacheo, en este caso optamos por varnish y del cual puedes ver la información de como funciona en su sitio, ahí esta toda la información que requieres.

 

El servidor esta mas que actualizado, usamos Centos 6.4.

 

No usamos Apache por 2 razones muy importantes:

1. La manera como funciona Apache (por lo menos la 2.2+) no es la óptima para un sistema como prestashop debido a como gestiona los recursos del sistema lo hace inviable para una tienda de tamaño medio a grande.
   
2. Vulnerable de fabrica a DoS tan simples como Slowloris, aunque estos pueden ser mitigados con algunas pequeñas configuraciones terminas perdiendo rendimiento y usando mas recursos.
   

Con respecto a los cuellos de botella son mitigados por el sistema de buffers de nginx pero curiosamente en ciertas horas del día y solo con prestashop el tiempo de respuesta sube a 5 o 6 segundos antes de cachear.

 

PHP esta configurado y funcionando usamos actualmente PHP-FPM versión 5.5.1.

 

Como te comentaba no usamos apache por la razones que te expuse arriba.

 

Gracias por tu comentario OlivierJM.

Edited August 15, 2013 by folvera6 (see edit history)

[OlivierJM]

Bueno Folvera6, quizas se trate de un problema con la escritura en disco debido al elevado IO de escritura lectura en el disco principal, ya que creo que indicas que solo dispones de un disco no, o me equivoco?

 

Pensaba que trabajabas con el Raid 10 por temas de rendimiento, pero veo que lo empleas para copias de seguridad . Es una solución que no e contemplado nunca.

 

Dentro de mi experiencia con Prestashop, comentarte que es el Windows de los Open E-Comerce, suelta los datos como quiere sin seguir un orden logico, hay va esooooo y a correr.

 

Pues entre todo ese caos, e comprobado que la principal prioridad de rendimiento en Prestashop es la base de datos, y en la gran mayoria optamos por MyIsam ya que es la indicada para muchos accesos a los datos de escritura y lectura. En tu caso, si por la cantidad de datos o el tipo de los mismos no lo admite, pues es complicado la verdad, por que como te comento, a partir de 5.000 productos trabajar con InBD relentiza mucho.

 

En fin, como la configuracion de tu Server no es Apache, no puedo añadir nada mas, pero si aprender algo nuevo.

 

Un saludo y muchas gracias.

[Jorge Arnal]

Desde mi humilde opinión, olvida una optimización por ese lado. Lo máximo que puedes hacer es mejorar la carga de módulos instalados forzando que no se carguen en determinadas páginas donde no hagan falta. Reducirás el volumen de código cargado en cada una al imprescindible, y es lo que yo, en mi humilde experiencia, más he notado. Generarás muchos más archivos de cache en tu plantilla (css y js), pero baja considerablemente el tiempo de carga.

 

Prestashop, por mi experiencia, tiene un SERIO problema en cuanto a peticiones a la base de datos y caché de la misma. Desde la 1.4.9 no he conocido ninguna versión rápida, y eso que he pasado por todas, hiperoptimizando su carga a nivel de máquina, cache y base de datos.

 

Repito, bajo mi experiencia, prestashop va de maravilla con los productos cargados por defecto. En un negocio serio que no venda los 4 productos de Apple... Es otro cantar.

 

P.D.: ¿Cómo ves nginx vs Apache? ¿Has notado mejoría notable y solidez?

 

P.D.2: También desde mi experiencia, en un Prestashop con un volumen serio de v.u y productos, la mejor respuesta la he encontrado deshabilitando el cache APC/memcached/etc tanto a nivel del framework como de servidor. No tiene ningún sentido, pero ahí lo dejo.

 

P.D.3: para que te hagas una idea, en los estándares de Prestashop tu tiempo de carga es la hostia. Ése es el nivel que se quiere conseguir.

 

Un saludo, gracias por poner aquí tu problema, algunos nos sentimos identificados.

[OlivierJM]

Desde mi humilde opinión, olvida una optimización por ese lado. Lo máximo que puedes hacer es mejorar la carga de módulos instalados forzando que no se carguen en determinadas páginas donde no hagan falta. Reducirás el volumen de código cargado en cada una al imprescindible, y es lo que yo, en mi humilde experiencia, más he notado. Generarás muchos más archivos de cache en tu plantilla (css y js), pero baja considerablemente el tiempo de carga.

 

Prestashop, por mi experiencia, tiene un SERIO problema en cuanto a peticiones a la base de datos y caché de la misma. Desde la 1.4.9 no he conocido ninguna versión rápida, y eso que he pasado por todas, hiperoptimizando su carga a nivel de máquina, cache y base de datos.

 

Repito, bajo mi experiencia, prestashop va de maravilla con los productos cargados por defecto. En un negocio serio que no venda los 4 productos de Apple... Es otro cantar.

 

P.D.: ¿Cómo ves nginx vs Apache? ¿Has notado mejoría notable y solidez?

 

P.D.2: También desde mi experiencia, en un Prestashop con un volumen serio de v.u y productos, la mejor respuesta la he encontrado deshabilitando el cache APC/memcached/etc tanto a nivel del framework como de servidor. No tiene ningún sentido, pero ahí lo dejo.

 

P.D.3: para que te hagas una idea, en los estándares de Prestashop tu tiempo de carga es la hostia. Ése es el nivel que se quiere conseguir.

 

Un saludo, gracias por poner aquí tu problema, algunos nos sentimos identificados.

 

Gracias por tus aportaciones Jorge. Comparto contigo el tema cache y decirte que yo únicamente utilizo Xcache y según cada caso.

[Rolige]

Prestashop 1.5 a mejorado mucho en el tiempo de carga, con un promedio de 1000 artículos y cache basico de sistema de archivos aún tiene un muy buen rendimiento, el usuario aún no a mencionado el promedio de usuario y productos, pero teniendo unos 10000 productos se podría utilizar memcached y nigix, con esto debería dar un exelente rendimiento.

[OlivierJM]

Prestashop 1.5 a mejorado mucho en el tiempo de carga, con un promedio de 1000 artículos y cache basico de sistema de archivos aún tiene un muy buen rendimiento, el usuario aún no a mencionado el promedio de usuario y productos, pero teniendo unos 10000 productos se podría utilizar memcached y nigix, con esto debería dar un exelente rendimiento.

 

No si no es cuestión de productos si no de carga de trabajo por el numero de clientes

 

Tu puedes tener una tienda con 2.000 productos y 10.000 clientes por hora y veras como se cae el server o se ralentiza.

 

Yo sin poder ver los parametros y lo que indican cada una de las partes del servidor no puedo decir nada mas, y mas inclusive cuando el unico servidor que conozco al 100% es Apache. No se puede uno especializar en todo, es imposible XD

[Rolige]

No si no es cuestión de productos si no de carga de trabajo por el numero de clientes

 

Tu puedes tener una tienda con 2.000 productos y 10.000 clientes por hora y veras como se cae el server o se ralentiza.

 

Yo sin poder ver los parametros y lo que indican cada una de las partes del servidor no puedo decir nada mas, y mas inclusive cuando el unico servidor que conozco al 100% es Apache. No se puede uno especializar en todo, es imposible XD

Me interesaria saber ya que mencionas que utilizas o has utilizado xcache, bajo tu experiencia, cual a sido el maximo numero de clientes registrados y numero de visitas diarias o por hora en una tienda?

[Sergio Ruiz]

No si no es cuestión de productos si no de carga de trabajo por el numero de clientes

 

Tu puedes tener una tienda con 2.000 productos y 10.000 clientes por hora y veras como se cae el server o se ralentiza.

 

Yo sin poder ver los parametros y lo que indican cada una de las partes del servidor no puedo decir nada mas, y mas inclusive cuando el unico servidor que conozco al 100% es Apache. No se puede uno especializar en todo, es imposible XD

 

¿Has tenido experiencias con tiendas, que han tenido 10.000 visitas reales simultaneas? (Si es así, es interesante que cuentes tu experiencia de forma completa)

[OlivierJM]

Me interesaria saber ya que mencionas que utilizas o has utilizado xcache, bajo tu experiencia, cual a sido el maximo numero de clientes registrados y numero de visitas diarias o por hora en una tienda?

 

La experiencia con mas requisitos a sido la configuración de un servidor dedicado para un cliente con una media de 500 visitas diarias.

Con la configuración base el servidor se caía o tardaba un mundo en realizar las conexiones. Con solo la instalación de Xcache solucione el problema pero necesitaba mas velocidad de carga así que decidió optar por APC. Despues modifique el resto del servidor. Mas abajo pongo los resultados de lo que es capaz de aguantar.

 

 

¿Has tenido experiencias con tiendas, que han tenido 10.000 visitas reales simultaneas? (Si es así, es interesante que cuentes tu experiencia de forma completa)

 

No es necesario Sergio, hice un text que hay herramientas para todo.

 

Tras las comprobaciones mínimas de 5000 peticiones y 100 de ellas simultaneas, me dio este resultado:

 

Completed 500 requests

Completed 1000 requests

Completed 1500 requests

Completed 2000 requests

Completed 2500 requests

Completed 3000 requests

Completed 3500 requests

Completed 4000 requests

Completed 4500 requests

Completed 5000 requests

Finished 5000 requests

 

 

Server Software: Apache

Server Hostname: www.************.com

Server Port: 80

 

Document Path: /

Document Length: 0 bytes

 

Concurrency Level: 100

Time taken for tests: 487.320 seconds

Complete requests: 5000

Failed requests: 7

(Connect: 0, Receive: 0, Length: 7, Exceptions: 0)

Write errors: 0

Non-2xx responses: 5000

Total transferred: 1733694 bytes

HTML transferred: 8834 bytes

Requests per second: 10.26 [#/sec] (mean)

Time per request: 9746.392 [ms] (mean)

Time per request: 97.464 [ms] (mean, across all concurrent requests)

Transfer rate: 3.47 [Kbytes/sec] received

 

 

Connection Times (ms)

min mean[+/-sd] median max

Connect: 133 192 463.0 133 7134

Processing: 1027 9474 1128.2 9468 22098

Waiting: 1027 9474 1128.2 9467 22098

Total: 1161 9666 1195.8 9620 22232

 

Percentage of the requests served within a certain time (ms)

50% 9620

66% 9944

75% 10192

80% 10364

90% 10898

95% 11345

98% 11860

99% 12308

100% 22232 (longest request)

 

PDT.: Si me das la URL de tu web, te hago el mismo test a ver que resultado arroja

Edited August 17, 2013 by OlivierJM (see edit history)

[Paula Martinez]

Hola,

 

Me llamo Raul Martinez,

 

Veo muchas opiniones en este tema de diverso ámbito.

 

Pero me gustaría saber si folvera6 ha podido solucionar el problema.

[Sergio Ruiz]

No es necesario Sergio, hice un text que hay herramientas para todo.

 

Tras las comprobaciones mínimas de 5000 peticiones y 100 de ellas simultaneas, me dio este resultado:

 

Completed 500 requests

Completed 1000 requests

Completed 1500 requests

Completed 2000 requests

Completed 2500 requests

Completed 3000 requests

Completed 3500 requests

Completed 4000 requests

Completed 4500 requests

Completed 5000 requests

Finished 5000 requests

 

 

Server Software: Apache

Server Hostname: www.************.com

Server Port: 80

 

Document Path: /

Document Length: 0 bytes

 

Concurrency Level: 100

Time taken for tests: 487.320 seconds

Complete requests: 5000

Failed requests: 7

(Connect: 0, Receive: 0, Length: 7, Exceptions: 0)

Write errors: 0

Non-2xx responses: 5000

Total transferred: 1733694 bytes

HTML transferred: 8834 bytes

Requests per second: 10.26 [#/sec] (mean)

Time per request: 9746.392 [ms] (mean)

Time per request: 97.464 [ms] (mean, across all concurrent requests)

Transfer rate: 3.47 [Kbytes/sec] received

 

 

Connection Times (ms)

min mean[+/-sd] median max

Connect: 133 192 463.0 133 7134

Processing: 1027 9474 1128.2 9468 22098

Waiting: 1027 9474 1128.2 9467 22098

Total: 1161 9666 1195.8 9620 22232

 

Percentage of the requests served within a certain time (ms)

50% 9620

66% 9944

75% 10192

80% 10364

90% 10898

95% 11345

98% 11860

99% 12308

100% 22232 (longest request)

 

PDT.: Si me das la URL de tu web, te hago el mismo test a ver que resultado arroja

 

No hablaba de simulaciones. (Las simulaciones, también se hacerlas, hablaba en la realidad, eso ya lo hablamos por privado)

 

De todos modos, estoy de acuerdo con Raul Martinez, creo que debemos centramos en folvera6

Edited August 17, 2013 by Sergio Ruiz (see edit history)

[folvera6]

Gracias a todos por el gran interés mostrado en el tema, les comento que de momento seguimos teniendo el mismo problema con prestashop pero ahora me estan presionando para el cambio de plataforma debido a la baja tasa de conversión que hemos tenido en los 2 últimos trimestres aquí el culpable es la lentitud de carga que esta provocando prestashop, cabe resaltar que no descarté ninguna de sus recomendaciones puesto que tratamos de aplicarlas a prestashop pero no se ve una gran mejoría.

 

El tiempo de carga deseado es de 800ms a 1.2s lamentablemente estamos encima por cerca de un 50%, he ahí el gran problema.

 

Personalmente y en base a la agridulce experiencia que hemos tenido con prestashop desde hace 11 meses lo recomendaría solo para pequeños negocios debido a todo lo que se a planteado a lo largo del tema, esto no indica que en si esta plataforma sea mala si no mas bien aclaro (y desde mi punto de vista muy personal) no es la idónea para empresas.

 

Como dato nuestra tienda cuenta con 7000 productos en stock (con un incremento mensual de 100 a 120 productos), 1150 sobre pedido, y aproximadamente 60 productos mensuales sin stock que son purgados en las optimizaciones de bases de datos, los visitantes únicos al día va de los 9000 a los 13500, y los usuarios registrados desde hace 11 meses suman cerca de 70000, no suena mal, pero comparado con nuestra otra tienda que tiene el mismo rango de visitantes y productos los usuarios prácticamente se duplican y por lo menos 4 de cada 5 clientes registrados a completado por lo menos una compra en el sitio.

 

Agradezco infinitamente su interés, probablemente ya no ronde por los foros en un tiempo pero de seguro regresaré para ver como evoluciona prestashop.

 

¡Saludos!

[Rolige]

Estoy seguro que si dieras la direccion de tu tienda pudieras tener un poco mas de comentarios en base a la perspectiva de cada persona pero por las visitas que comentas dudo mucho que puedas publicar ese dato, en lo particular si sería muy interesante que al menos comentaras los métodos de posicionamiento que usaste y cual es el giro de la tienda, quizá le interese a mas de uno.

 

Saludos.

[Jorge Arnal]

Con esos datos, creo que lo que necesitáis es una solución ad hoc. Ya que manejas nginx, yo te propongo una tecnología por si no la has visto: Web2Py. Ya tiene versión estable, lo está petando en EEUU y seguro que se te ocurre una forma de implementar el carrito. Para el front y el back es un bootstrap por defecto. LLeva curro de desarrollo, pero con esos datos no sé si encontrarás CMS que se adapten.

 

Suerte, muchas gracias por tus comentarios, se agradecen experiencias con webs de alto nivel.

 

Un saludo.

[Enrique Gómez]

Con esos datos, creo que lo que necesitáis es una solución ad hoc. Ya que manejas nginx, yo te propongo una tecnología por si no la has visto: Web2Py. Ya tiene versión estable, lo está petando en EEUU y seguro que se te ocurre una forma de implementar el carrito. Para el front y el back es un bootstrap por defecto. LLeva curro de desarrollo, pero con esos datos no sé si encontrarás CMS que se adapten.

 

Suerte, muchas gracias por tus comentarios, se agradecen experiencias con webs de alto nivel.

 

Un saludo.

 

Un post muy interesante, es difícil encontrar gente con experiencia real con estas cifras. Con estos números yo me pensaría desarrollar la web a medida como dice Jorge, al final haces lo que puedes con el tema de configuración de servidores (que es un mundo por lo que veo..) pero luego no te queda más remedio que optimizar el código y las consultas a base de datos y si no tienes a algún/os experto/os desarrollador/es en Prestashop quizás te valga la pena montarte tu solución.

 

Ni que decir tiene que los resultados de optimizar código pueden ser espectaculares. Cuando desarrollas un producto como Prestahop (o cualquier otro más o menos grande) la programación orientada a objetos y un código digamos "coherente" con una forma "unificada" de trabajar es una prioridad (por mantenimiento, escalabilidad..) pero en temas de rendimiento la clave esta en las consultas SQL.

 

En general no es raro en proyectos grandes encontrarse con que necesitas p.ej traerte los productos de una categoría (por decir algo relacionado con Prestashop), entonces escoges el método de la clase que toca que se usa en varios sitios y es el "oficial". Sacas los productos, iteras por cada producto y te das cuenta que necesitas mas datos, tiras de la API que ya existe y te traes más datos. Esto evidentemente es un cuello de botella en lo referente a consultas ya que estas haciendo N consultas cuando seguramente podrías hacer una consulta inicial optimizada para tus necesidades.

 

Saludos

Edited August 20, 2013 by Enrique Gómez (see edit history)

[OlivierJM]

No se porque me da a mi que estamos buscando peces en un mar revuelto. Todavía a día de hoy nadie a preguntado por el principal tema que motiva las conexiones lentas en un server de alto rendimiento.

 

En fin, como no es cuestión ni de discos duros, ni es cuestión de server, ni es cuestión de RAM (Nadie a preguntado tan siquiera si trabaja junto al nucleo Linux) si no que la respuesta final fue cuestión de echarle la culpa a Prestashop, me quedo con la duda si con nuestros servidores dedicados y configurados para Prestashop podríamos hacer frente a tal cantidad de solicitudes a la base de datos, teniendo en cuenta que según comento son 70.000 usuarios registrados (70.000 tablas en base de datos a consultar) y 13.500 visitas simultaneas, mi pregunta es, ¿Podríamos hacernos cargo de un proyecto doblando los parámetros? es decir, 140.000 Clientes Registrados y 30.000 visitas diarias.

 

La respuesta encontrada con pruebas e incluso ataques Ddos, (Ya que estos su misión es echar abajo el servidor con peticiones) hemos llegado a la conclusión que en uno de nuestros dedicados para VPS que tiene:

 

96GB de RAM, 2TB de HD en RAID 0

Y finalmente 2 discos de 4TB en RAID 1 para copias de seguridad.

 

La conclusión obtenida en las pruebas realizadas es que:

 

Si podríamos realizar dicho trabajo de 140.000 Clientes en Base de Datos, 30.000 conexiones simultaneas. Eso sí, con menos RAM por servidor, unos 32GB y por supuesto un mínimo de 2 Servidores para ello. (Lo ideal 3 servidores) para responder en menos de 1.2 Segundos a 30.000 conexiones simultaneas.

 

Conclusión: Con un solo servidor no se puede realizar de ninguna forma dicho trabajo(menos de 1.2 Segundos a 30.000 conexiones simultaneas). Al menos nosotros con nuestros servidores no hemos podido hacerlo.

 

Un saludo

[Rolige]

Hay que ser honestos y aceptar en que el software también es pieza fundamental para un buen desempeño, prestashop cada vez más va mejorando el rendimiento y esta última versión 1.5.5 es quizá la mejor de todas al día de hoy respecto al tema de desempeño, claro que también es fundamental un server de características robustas, como bien lo dices sería más conveniente para este tema que el señor divida un poco las cargas y haga sus respectivas pruebas, hay que entender que a medida que un sitio incrementa sus visitas pues también será necesario aumentar el hardware.