Ver Mensaje Individual
  #18 (permalink)  
Antiguo 21/05/2003, 15:51
Avatar de sci-fi
sci-fi
 
Fecha de Ingreso: marzo-2002
Mensajes: 157
Antigüedad: 22 años, 1 mes
Puntos: 0
bueno la clase la había hecho entre otras cosas porque el server mysql con el que trabajo ahora (que espero poder cambiar dentro de poco) se congestiona a los mil diablos; en cambio, PHP, funciona siempre bien incluso en las horas pico, a pesar de que la memoria ram del server es bien poca, creo que 128 MB.. eso no quiere decir que mysql tenga mala performance, sino que el server está mal seteado, tiene poca ram, y entonces el server no puede con los "miles" de sitios web que deben haber metido en la bolsa

haciendo testeos con esa clase me dio siempre que el tiempo de ejecución del sql en el server mysql siempre daba más o menos arriba del 85% del total de ejecución del script (incluyendo PHP), mientras que el tiempo de PHP daba entre el 15% y generalmente siempre menos del 10%, por lo menos en este server

había visto lo de conexiones persistentes con mysql_pconnect, pero hay servers que no lo permiten (es mi caso); y he leído que no es 100% confiable... al menos con mysql 4.23... no sé cuánto será así

de todas maneras, a pesar de que el manual oficial de mysql lo recomienda, no estoy todavía convencido de que consuma menos recursos... me parece que varias conexiones lo más cortas posibles son más rápidas que una conexión persistente... supongamos que haya 100 usuarios al mismo tiempo; es más la carga conectando los 100 solamente cuando se necesita (y considerando que la persistente puede continuar, para cada usuario individual, en los "tiempos muertos" del usuario, o sea cuando este usuario no requiere datos de la bd), que 100 conexiones persistentes al mismo tiempo...? en fin, no estoy seguro de esto, además es solamente mi idea personal

con respecto a lo mysql_data_seek() eso me parece muy bueno... no tengo idea si utiliza de recursos de mysql?

gracias por los comentarios

saludos