Mejorar rendimiento: VPS vs. alojamiento separado, ¿cuál elegir?

  • Autor Autor TerraNode.net
  • Fecha de inicio Fecha de inicio
"El sistema esta hecho tengo entendido en laravel con vue", son bases sólidas pero eso no basta. Claramente tu problema es uno de mal diseño de las tablas. Te sugiero saques una copia de tu DB, como bien dicen aquí su tamaño es ridículo para asumir que ese sea el problema, y comienza a indexar los campos relacionados; fácilmente puedes replicarlo en localhost y comenzar a reparar la pobre implementación de quien sea que te haya hecho el sistema.
Nunca subestimes la estupidez de la gente. Te pongo 2 ejemplos de problemas reales que tuve que arreglar recientemente:
a. Escenario: Magento 2, el programador había escrito un plugin para hacer algo que Magento ya hacía, y su código colisionaba con el de Magento. Antes de escribir 1 línea de código asegúrate que sea algo que requiera programación y no configuración.
b. Escenario: WordPress, tenían un plugin que no funcionaba y me llamaron para arreglarlo. Lo que sigue es real. Como no tenía acceso directo al source él intermediaba, el directorio en cuestión contenía 2 archivos con el mismo nombre, llamémosle plugin.php y plugin.html, el último era obviamente el view. Cuando le dije que buscara "'add_shortcode(' o 'add_shortcode (' en el código" me respondió: "no existe!". "imposible! Busca de nuevo...", "no hay" insistió, repliqué, "pásame el código por Telegram..." y esto es cierto, lo que recibí fue el archivo plugin.html!!!
 

Despues de que varios por aca me han comentado que al parecer el problema radica en el sistema me preocupa un poco debido a que con este programador tengo 3 clientes a los cuales les he hecho sistemas, el mas antiguo (6 meses) es este que esta teniendo estos problemas.

Lo más preocupante es que este cliente siempre me pide mas cosas para su sistema y temo que a la larga colapse no solamente porque pide más recursos como esta sucediendo ahora, sino que no pueda ser escalable
 
Amigo deberías ponerte manos a la obra, ya sabes que el lío va por el lado de indexar las tablas. Saca 1 copia de tu DB, arranca tu PhpMyAdmin y haz cosas
 
arnego2 dijo:
creo que son 35 mensual, no anual.
Hacer clic para expandir...
Si, lo contemplé a 35 mensuales pero no sabemos que tipo de hosting use él, yo tomé uno de auction de Hetzner que suelen oscilar ese precio a menos que optimice y pueda ir por un Cloud para empezar escalando a necesidad
 
Berker dijo:
Si, lo contemplé a 35 mensuales pero no sabemos que tipo de hosting use él, yo tomé uno de auction de Hetzner que suelen oscilar ese precio a menos que optimice y pueda ir por un Cloud para empezar escalando a necesidad
Hacer clic para expandir...
Yo soy proveedor de hosting en mi pais, ahora lo tenemos en un hosting con 8gb de ram y 6 core, pero igual no es 100% dedicado para el sistema todo ese recurso, asi que estaba por migrarlo a un vps con 16 de ram y 12 Core....pero según sus comentarios voy a revisar los querys para optimizarlo y que no tenga un excesivo consumo sino a cada momento pedirá más y más potencia
 
Si estás brindando servicio de hosting es totalmente definitivo que le hagas una optimización a la base de datos pero también te sugerirías cuantos recursos te consume el script que estés empleando, tiene finalidad estilo API?
 
Lo que pasa es que una cosa es crear un sistema, y que funcione. Y otra totalmente diferente es optimizarlo.

Llegara un punto que no sera viable dicho sistema por el alto consumo monetario.
 
el dato necesario es la estructura de las tablas, los indices y la consulta
el dato de que son 23K no dice mucho para ayudar
 
Definitivamente es un problema de querys e incluso podría ser también de diseño y normalización de la BD.
Por ejemplo, mira mi servicio de API que busca en más de 14 millones de registros por código (osea un where) https://consultaruc.win/api/ruc/10453658371
lo hace en menos de 2 segundos
 
Compañero parece ser que la base de datos está mal diseñada y las queries tampoco deben estar optimizadas, 23.000 registros no es una cantidad de datos que deberían colapsar la base de datos. Yo en lugar de buscar un escalamiento vertical primero optaría por revisar el diseño de la base de datos y optimizar las consultas.
 
Optimicé una base de datos, sin tocar el php, consultas de 40 a 65 segundos ahora se resuelven en 0.04 segundos.....
varios cientos de miles de filas
 
¿Y como termina la historia o sigue en "continuará..."?
Si quieres me mandas un MP a ver si puedo ayudar
 
Solucionaste?
 
Pues como Update de este caso:

* Validé en conjunto con un cuñado que se dedica a la programación, pero algo puntual, asi que me ayudó y se le hizo un cambio para que no presente las 23k ordenes de una, sino que vaya mostrando de 100 en 100 a medida vaya necesitando el cliente, el sistema se puso mucho más rápido, pero al cliente no le gustó 😕.

Indicaba que necesitaba ver las 23k a la vez, por más que se le explicó que sería lo mismo, solo que no se cargarían a la vez todas, el indicó que lo quería como antes...cabe destacar que hicimos esta mejora para que el sienta el sistema mucho mejor, pero no se dejó ayudar en este sentido, asi que alli quedó como estaba.

Cabe destacar que el cliente es un poco reacio con la tecnología.
 
Te voy a enviar un MP.
 

Pero listar los 23K no debería ser problema.

 
Revisa los índices de la base de datos y las consultas, posiblemente tengas que añadir índices por los campos que mas buscas
 
Ya en casos así es mejor desistir pero a futuro podrías copiar la estructura de algún CMS bastante ligero y con eso ejecutar creaciones por encima para al menos no tener el lío de la base de datos ya que funcionaría en todo término... estuve jugando con el script que tengo y pude retraer +1M de querys al instante, pero eso sí, subió bastante lindo el consumo de recursos 🤣
 
¿El problema es la consulta o la generación del html gigante?
prueba poner masrca de tiempo para ver donde está el cuello de botella.
 
Hay que estar conectado o registrado para responder aquí.
Menú
Acceder
Registro