Portada
mis comunidades
otras secciones
#10:
No olvidemos las consultas SQL. El problema de hoy en día que me encuentro es:
Bases de datos no optimizadas
"Programadores" sin conocimientos en BBDD relacionales
Captain Obvious tips (sql server):
1. Usa la clausula Top después de select si sabes cuantos registros te han de devolver.
2. No devuelvas * por omisión, seguramente sólo usarás un par de campos, a no ser que sea inevitable.
3. Si necesitas registro aleatorio usa order by newid() , y no inventes la rueda.
4. No guardes archivos dentro de una tabla en binario, es cargarse todo.
5. Para juntar dos tablas usa JOIN, no hagas from tabla1,tabla2! ni se te ocurra.
6. Procura tener bien indexada la tabla.
7. Haz los filtros de la consulta sobre los registros indexados
8. Utilizar siempre que sea posible las mismas consultas. La segunda vez que se ejecuta una consulta, se ahorrará mucho tiempo.
9. Las consultas que mas uses ponlas en un procedimiento almacenado, este ya esta compilado y serás más efectivo
10. Si puedes evita poner algo Like ‘%algo%’ y si campo=’algo’. Cuanto mas específico mejor.
11. Y por favor si quieres saber los registros de una tabla usa un count, no un rs.recordcount, que me encontrado cada “ingeniero” que para que….
vía un antiguo post de mi blog http://www.deambulando.com/2007/02/16/optimiza-tus-sentencias-sql/
Por cierto tampoco hablan del hardware (lo importante que es la velocidad de lectura del disco o tener memoria disponible)
Me encanta esto de optimización, bueno este era mi trabajo en casi todos los sitios
Bases de datos no optimizadas
"Programadores" sin conocimientos en BBDD relacionales
Captain Obvious tips (sql server):
1. Usa la clausula Top después de select si sabes cuantos registros te han de devolver.
2. No devuelvas * por omisión, seguramente sólo usarás un par de campos, a no ser que sea inevitable.
3. Si necesitas registro aleatorio usa order by newid() , y no inventes la rueda.
4. No guardes archivos dentro de una tabla en binario, es cargarse todo.
5. Para juntar dos tablas usa JOIN, no hagas from tabla1,tabla2! ni se te ocurra.
6. Procura tener bien indexada la tabla.
7. Haz los filtros de la consulta sobre los registros indexados
8. Utilizar siempre que sea posible las mismas consultas. La segunda vez que se ejecuta una consulta, se ahorrará mucho tiempo.
9. Las consultas que mas uses ponlas en un procedimiento almacenado, este ya esta compilado y serás más efectivo
10. Si puedes evita poner algo Like ‘%algo%’ y si campo=’algo’. Cuanto mas específico mejor.
11. Y por favor si quieres saber los registros de una tabla usa un count, no un rs.recordcount, que me encontrado cada “ingeniero” que para que….
vía un antiguo post de mi blog http://www.deambulando.com/2007/02/16/optimiza-tus-sentencias-sql/
Por cierto tampoco hablan del hardware (lo importante que es la velocidad de lectura del disco o tener memoria disponible)
Me encanta esto de optimización, bueno este era mi trabajo en casi todos los sitios
#5:
Hay algún fallo:
Also note that JPG has an option called "Progressive" mode. This option adds multiple copies of the image at lower resolution to make the image appear quickly on the screen, while progressively improving in quality. But it also increases the overall size of the image
Yo en GIMP normalmente noto lo contrario, sobretodo a partir de un factor 75 de calidad.
Y bueno, si tenéis que cuardar un dibujo como el de las bolitas, usad PNG. Si además no necesitáis transparencia, podéis usar la opción imagen->aplanar imagen (elimina el canal alfa). Eso ahorra un poquito de tamaño. Y si además de no necesitar transparencia, el dibujo no tiene muchos colores diferentes o degradados, podéis probar a guardarla en color indexado (imagen->modo-->Color indexado) no uséis difuminado de color, y dejad la opción "generar paleta óptima". Eso bajará bastante el tamaño del fichero. Y ya para rematar: si la imágen tiene poquísimos colores, podéis probar con paletas más pequeñas, por ejemplo, 32 colores o 16 en vez de 256. Si la imágen tiene pocos colores (color de fondo+2 o 3 colores más), no se notaría casi, y se reduciría más el tamaño del fichero.
Para fotos, JPEG es la mejor opción. Si la foto queréis que tenga buena calidad y usáis GIMP, podéis ir a opciones avanzadas y poner que el submuestreo de color sea 1×1,1×1,1×1, que da más calidad aunque sube un poquito el tamaño del fichero (poco).
Si se trata de una infografía, normalmente JPEG solo va bien si se deja el submuestreo como dije antes, sino, da una calidad muy pobre.
Also note that JPG has an option called "Progressive" mode. This option adds multiple copies of the image at lower resolution to make the image appear quickly on the screen, while progressively improving in quality. But it also increases the overall size of the image
Yo en GIMP normalmente noto lo contrario, sobretodo a partir de un factor 75 de calidad.
Y bueno, si tenéis que cuardar un dibujo como el de las bolitas, usad PNG. Si además no necesitáis transparencia, podéis usar la opción imagen->aplanar imagen (elimina el canal alfa). Eso ahorra un poquito de tamaño. Y si además de no necesitar transparencia, el dibujo no tiene muchos colores diferentes o degradados, podéis probar a guardarla en color indexado (imagen->modo-->Color indexado) no uséis difuminado de color, y dejad la opción "generar paleta óptima". Eso bajará bastante el tamaño del fichero. Y ya para rematar: si la imágen tiene poquísimos colores, podéis probar con paletas más pequeñas, por ejemplo, 32 colores o 16 en vez de 256. Si la imágen tiene pocos colores (color de fondo+2 o 3 colores más), no se notaría casi, y se reduciría más el tamaño del fichero.
Para fotos, JPEG es la mejor opción. Si la foto queréis que tenga buena calidad y usáis GIMP, podéis ir a opciones avanzadas y poner que el submuestreo de color sea 1×1,1×1,1×1, que da más calidad aunque sube un poquito el tamaño del fichero (poco).
Si se trata de una infografía, normalmente JPEG solo va bien si se deja el submuestreo como dije antes, sino, da una calidad muy pobre.
#21:
Lo mismo (o más) pero de yahoo http://developer.yahoo.com/performance/rules.html
#3:
La solución la tenemos en la mano. No desarrolles tu propio HTML, usa frameworks que abstraen esta traducción. Además te da la ventaja de que la tecnología la usas como bridge entre tu interfaz y el código "nativo" en este caso el HTML.
De esta manera, todas las aplicaciones desarrolladas actualmente, si quieren cambiar a html5 tendrán de "redesarrollarse" o adaptarse al nuevo lenguaje. Con tecnologías como Groovy, Grails, GWT, Google Gears, etc, te olvidas un poco del HTML (casi diría que del todo) y consigues desacoplar tu implementación de la tecnología final de presentación. Además, digamos, que es más fácil delegar en este tipo de soluciones que saberte al dedo todos los tricks para optimizar tu página.
De esta manera, todas las aplicaciones desarrolladas actualmente, si quieren cambiar a html5 tendrán de "redesarrollarse" o adaptarse al nuevo lenguaje. Con tecnologías como Groovy, Grails, GWT, Google Gears, etc, te olvidas un poco del HTML (casi diría que del todo) y consigues desacoplar tu implementación de la tecnología final de presentación. Además, digamos, que es más fácil delegar en este tipo de soluciones que saberte al dedo todos los tricks para optimizar tu página.
Comentarios
No olvidemos las consultas SQL. El problema de hoy en día que me encuentro es:
Bases de datos no optimizadas
"Programadores" sin conocimientos en BBDD relacionales
Captain Obvious tips (sql server):
1. Usa la clausula Top después de select si sabes cuantos registros te han de devolver.
2. No devuelvas * por omisión, seguramente sólo usarás un par de campos, a no ser que sea inevitable.
3. Si necesitas registro aleatorio usa order by newid() , y no inventes la rueda.
4. No guardes archivos dentro de una tabla en binario, es cargarse todo.
5. Para juntar dos tablas usa JOIN, no hagas from tabla1,tabla2! ni se te ocurra.
6. Procura tener bien indexada la tabla.
7. Haz los filtros de la consulta sobre los registros indexados
8. Utilizar siempre que sea posible las mismas consultas. La segunda vez que se ejecuta una consulta, se ahorrará mucho tiempo.
9. Las consultas que mas uses ponlas en un procedimiento almacenado, este ya esta compilado y serás más efectivo
10. Si puedes evita poner algo Like ‘%algo%’ y si campo=’algo’. Cuanto mas específico mejor.
11. Y por favor si quieres saber los registros de una tabla usa un count, no un rs.recordcount, que me encontrado cada “ingeniero” que para que….
vía un antiguo post de mi blog http://www.deambulando.com/2007/02/16/optimiza-tus-sentencias-sql/
Por cierto tampoco hablan del hardware (lo importante que es la velocidad de lectura del disco o tener memoria disponible)
Me encanta esto de optimización, bueno este era mi trabajo en casi todos los sitios
Hay algún fallo:
Also note that JPG has an option called "Progressive" mode. This option adds multiple copies of the image at lower resolution to make the image appear quickly on the screen, while progressively improving in quality. But it also increases the overall size of the image
Yo en GIMP normalmente noto lo contrario, sobretodo a partir de un factor 75 de calidad.
Y bueno, si tenéis que cuardar un dibujo como el de las bolitas, usad PNG. Si además no necesitáis transparencia, podéis usar la opción imagen->aplanar imagen (elimina el canal alfa). Eso ahorra un poquito de tamaño. Y si además de no necesitar transparencia, el dibujo no tiene muchos colores diferentes o degradados, podéis probar a guardarla en color indexado (imagen->modo-->Color indexado) no uséis difuminado de color, y dejad la opción "generar paleta óptima". Eso bajará bastante el tamaño del fichero. Y ya para rematar: si la imágen tiene poquísimos colores, podéis probar con paletas más pequeñas, por ejemplo, 32 colores o 16 en vez de 256. Si la imágen tiene pocos colores (color de fondo+2 o 3 colores más), no se notaría casi, y se reduciría más el tamaño del fichero.
Para fotos, JPEG es la mejor opción. Si la foto queréis que tenga buena calidad y usáis GIMP, podéis ir a opciones avanzadas y poner que el submuestreo de color sea 1×1,1×1,1×1, que da más calidad aunque sube un poquito el tamaño del fichero (poco).
Si se trata de una infografía, normalmente JPEG solo va bien si se deja el submuestreo como dije antes, sino, da una calidad muy pobre.
Lo mismo (o más) pero de yahoo http://developer.yahoo.com/performance/rules.html
La solución la tenemos en la mano. No desarrolles tu propio HTML, usa frameworks que abstraen esta traducción. Además te da la ventaja de que la tecnología la usas como bridge entre tu interfaz y el código "nativo" en este caso el HTML.
De esta manera, todas las aplicaciones desarrolladas actualmente, si quieren cambiar a html5 tendrán de "redesarrollarse" o adaptarse al nuevo lenguaje. Con tecnologías como Groovy, Grails, GWT, Google Gears, etc, te olvidas un poco del HTML (casi diría que del todo) y consigues desacoplar tu implementación de la tecnología final de presentación. Además, digamos, que es más fácil delegar en este tipo de soluciones que saberte al dedo todos los tricks para optimizar tu página.
#10 Yo añadiría:
- Informarse bien sobre los tres tipos de cache de mysql (key, table y query)
La query cache es la que hace que, con consultas consecutivas, de la segunda en adelante vaya más rápido.
- Usar NO_SQL_CACHE en la consulta para hacer pruebas (SELECT NO_SQL_CACHE campos FROM tabla...)
Por cierto, no sabía que se podían usar procedimientos almacenados, gracias por la info
En optimización de php fallan como escopetas de feria. Por ejemplo, se olvidan que php5 es orientado a objetos y crea referencias cuando igualas variables.
Lo que dicen aquí es simplemente incorrecto:
Don't copy variables for no reason.
Sometimes PHP novices attempt to make their code "cleaner" by copying predefined variables to variables with shorter names. What this actually results in is doubled memory consumption, and therefore, slow scripts. In the following example, imagine if a malicious user had inserted 512KB worth of characters into a textarea field. This would result in 1MB of memory being used!
BAD:
$description = _$_POST['description'];_
echo $description;
GOOD:
echo _$_POST['description'];_
#4
pruben@ruben-laptop:~$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 'evil'[1:3]
'vi'
>>>
Don't use concatenation with echo.
Many novice PHP programmers are unaware that you can pass multiple variables to the echo, separated by commas, instead of concatenating them first. Using the decimal character, shown in the first example, results in poor performance, because the PHP engine must first concatenate all of the variables together and then print, whereas in the second example, it prints them all in the order provided.
BAD:
echo 'Hello, my name is' . $firstName . $lastName . ' and I live in ' . $city;
GOOD:
echo 'Hello, my name is' , $firstName , $lastName , ' and I live in ' , $city;
#2 ¡no puede ser! vi is a subset of evil!
¡En Google usan VI! http://code.google.com/intl/es/speed/articles/optimizing-php.html
Por cierto, me encanta el "inglés for dummies" que usan la gente de Google
Por fin!!! alguien que me entiende!!!
Cuantos clientes me habran dicho que eso de optimizar paginas es una mierda, que con el ancho de banda que tenemos no vale pa nada.... que ellos quieren una pagina en flash tope guay que tenga ruidoss... en fin.
Por mi experiencia, uno de los métodos más sencillos y efectivos para optimizar una web es:
- Usar correctamente los índices en la BD.
Con un simple "clic" en el PhpMyAdmin o una simple consulta SQL, he visto reducir el tiempo de carga de una página de 4-5 segundos a menos de medio segundo.
#14 No se trata de lo que ocupe o deje de ocupar el archivo PHP. El problema está en:
- Tiempo de ejecución del PHP
- Tamaño del archivo HTML generado
El tamaño del archivo PHP no importa en el 99% de los casos. El tiempo de ejecución usando ' es menor que usando " y el tamaño de archivo HTML generado es el mismo.
Además personalmente considero que las ' son más estéticas
#11
no me refiero a Mysql los tips, pero gracias, ya que desconocía esto y ahora sólo uso MySql
en cuanto a los procedimientos , en mysql si se puede (creo no se mucho de mysql)si te dan los permisos necesarios...si puedes ese es el problema de siempre de un hosting compartido, nada como tu servidor dedicado
Son buenos consejos todos, pero mucha pompa me parece para tan poca chicha. El vídeo es muy efectista pero no es la vía más eficaz para comunicar este tipo de contenido.
Da igual como lo hagas, luego hay que cerdearlo todo para ie
Qué consejos más excelentes!
Esto definitivamente va a mis páginas favoritas...
Muchas gracias por el enlace, por ahora me he leído el de Page Speed y el de PHP para novatos y me han ayudado mucho.
En el PHP lo mejor es cerrar el php, tal que así:
...?>This is a string
#16 Este mundo está lleno de gente que no sabe lo que quiere, pero que estaría dispuesta a cruzar el infierno para conseguirlo
Muchas páginas hechas en flash, carecen de funcionalidad, escalabilidad, usabilidad (a veces el usuario tiene que esperar a que terminen las animaciones entre cada cambio de producto), y no son bien indexadas por los buscadores. Son como un batmovil muy bonito pero hecho de cartonpiedra
#10 Si realmente se producen embudos en una BDD relacional creo que es hora de hacer un cambio y saltar a BD's más escalables y no relacionales (principios de Cloud Computing). Con una buena normalización (sin pasarse, puede llegar a ser ilegible la capa de persistencia) se consigue unos milisegundos en consultas donde los índices tienen bastantes ramas.
Si bien todo eso ayuda, también hay que contar con un buen administrador de BDD que no deje que el árbol de nuestras tablas parezca la torre de Pisa.
En Java, para persistencia tienes soluciones como Hibernate, que aunque cierran bastantes optimizaciones, puedes configurar las consultas básicas, para añadir cosas como lo que dice #11, mediante los XML o usar tus propias estrategias de traducción HQL->SQL. Además utiliza EHCache, y realiza un uso bastante prudente, lo cual conseguimos aún más optimización. Sin embargo, en tablas grandes se pira un poco de madre, ya que el ORM, a lo que hay que sumarle que la profundida por defecto es 3, acaba ralentizando la consulta porque termina leyendo unas 5 o 6 tablas como mínimo (depende del sistema y la configuración).
Algún detalle más:
http://code.google.com/intl/es/speed/page-speed/docs/payload.html#CompressImages
Lo de PNGOut es sencillo te permite recomprimir una imagen PNG sin perder calidad. Eso si, tarda un poco según el tamaño de la imagen, y suele bajar un 20% aproximadamente. Si usáis Irfanview, podéis usar este programa al guardar una imagen activando una opción del guardado en PNG.
#0 #5 #10 #19 Buenísimos consejos. ¡Gracias!
Me vienen muy bien dado que trabajo con estas cosillas (soy autodidacta).
Por cierto, viendo esto → http://tinyurl.com/ltzb5z qué ganas de que se estandarize el uso de HTML 5.
#3 La solución la tenemos en la mano. No desarrolles tu propio HTML, usa frameworks que abstraen esta traducción. Además te da la ventaja de que la tecnología la usas como bridge entre tu interfaz y el código "nativo" en este caso el HTML.
¿Pero qué burrada me estás contando? ¿dejar que un framework ponga el html a su cuenta y riesgo?
De esta manera, todas las aplicaciones desarrolladas actualmente, si quieren cambiar a html5 tendrán de "redesarrollarse" o adaptarse al nuevo lenguaje. Con tecnologías como Groovy, Grails, GWT, Google Gears, etc, te olvidas un poco del HTML (casi diría que del todo) y consigues desacoplar tu implementación de la tecnología final de presentación. Además, digamos, que es más fácil delegar en este tipo de soluciones que saberte al dedo todos los tricks para optimizar tu página.
Precisamente estoy harto de los diseñadores wbe de palo que usan el dreanweaver con su html de mierda y su código de mierda.
Un ejemplo de DW: ante sme pego un tiro que diseñar con un framewrik.
Viva el notepad!
"BAD:
$output = "This is a plain string";
GOOD:
$output = 'This is a plain string';
BAD: $type = "mixed";
$output = "This is a $type string";
GOOD:
$type = 'mixed';
$output = 'This is a ' . $type .' string';"
Esto no por favor, jamás cambiaré mis " por ', solo cuando hay mucho html y no quiero poner " y olvidénse de cambiar "This is a $type string" por 'This is a ' . $type .' string', ¡ocupa más!
Meneo y a favoritos para leérmelo entero con calma (antes me lo he leído por encima, eh? ).
Viva!
#26 frameworks como GWT usan disgregadores, es decir, generan varias interfaces (de modo transparente tanto para el administrador que despliega la aplicación como para el dev) y en el punto de entrada disgrega los comportamientos de los componentes en función del UserAgent.
#29 pues sigo haciendo mis html y php a pelo. No sé tú, pero aún ningún IDE o framework me hace lo que yo quiero en css.
Pues no estaría mal que para hacer la web más rápida su navegador consumiese menos memoria
#27 a su cuenta y riesgo? Pero tú en qué época vives? Conoces lo que es el CDD? O sea, pretendes seguir haciendo llamaditas AJAX a pelo? Estructurando los paneles (div en este caso) por ti mismo?
Todos los frameworks de desarrollo web (al menos en j2ee) están abandonando ese estilo de programación porque es mucho más rentable el Component Driven Development, básicamente porque te olvidas de cómo está hecho el componente, sabes que tiene X fucionalidad y punto. Si quieres modificar la traducción tienes la capacidad de extenderlo, si necesitas saber cómo traduce tienes el código fuente.
Es mucho más sencillo trabajar como ofrece, por ejemplo GWT, donde tú trabajas con una estructura de layouts y es el GWTCompiler quién traduce eso a JS. Que al final todo serán inserciones HTML. Si quieres seguir haciendo las cosas completamente a mano te has equivocado de época. Vuelve a las tarjetas perforadas y déjate de ir de sabio.
Lo que estoy viendo es que no tienes ni idea de lo que es un framework y ni lo que es GWT, Groovy o Google Gears. Tú hablas de DreamWeaver, el cuál no es un framework, si no un IDE. Pero tú a lo tuyo. Lo dicho, si no comprendes, no llames burro a nadie, que listos sobran