Como Hacer las Cosas sean más Rapidas???? SQLSERVER + ASP

richardinj · #1 (**permalink**) 09/11/2005, 13:43

Hola amigos.. tengo que hacer consultas a un BD que consta de 25 Millones de registros.... en una pagina tendre hasta 4 consultas diferentes...

Como puedo hacer para que el servidor no se sature y que el proceso sea muy veloz.. de que depden esto???

Como hacer que ASP sea mas rapido en dar sus respuestas...liberbar menoeria.. no se dben ver trucos.. como le hace google?? con su lenguage (no recuedo cual es)...es veloz y maneja mas de 8 mil millones de registros...???? creo que hay una metodologia....

ya tengo algo obtimo como es usar INNER Join... pero me gustaria saber si hay mas altenativas para hacer mas rapido el proceso...

Dejen Ideas y Sugerencias

Un Abrazo...

Dorita · #2 (**permalink**) 09/11/2005, 14:31

Hola richardinj, bueno yo ocupo actualmente asp con sql server y trabajo actualmente con mas de 13000 registros...una de los mejores cambios que hice para acelerar el proceso de carga de la página fue cambiar los recordset normales por getrows, donde tambien puedes paginar resultados (busca info aqui en foros del web, hay bastante material y yo tb postee mi ejemplo). ahora, tb he escuchado que lo mejor es en ves de tener las sentencias sql en la página, hacer vistas de estas o procedimientos almacenados en sql server, pero no lo he probado hasta el momento.

otra opción es, si no ocuparás las cookies y las sesiones, especificarlo en la cabecera de la página.
Espero haberte ayudado en algo
salu2.-

monkyta · #3 (**permalink**) 09/11/2005, 16:37

Para trabajar con tablas de millones de filas hay que considerar lo sig :
Parte Fisica
1- Haber definido la Base en donde residen estas tablas con devices distintos para la data, log y area de indices no clustered.
Parte Logica
2.- Tener un indice clustered por tabla; mas uno o mas indices segun los criterios de busqueda que se usen
3.- Tener en lo posible la tabla reorganizada la data y actualizada las estadisticas
4.- Los indices que se definan no deben tener columnas que acepten nulos

Voy a mandarte esto primero ya que la sesion termina... sigo en otro para decirte mas cosas

monkyta · #4 (**permalink**) 09/11/2005, 16:43

Ahora si hay muchas tablas de codigos que uses para hacer JOIN con esta tabla grande te conviene tener cargada en memoria las tablas mas usadas.
Por otro lado en los JOIN trata de evitar las conversiones en los where y si debes hacer JOIN con tablas de codigos para sacar valores de campos como nombres de comunas, nombres de oficinas, etc te conviene hacer un case para obtener el resultado de la columna usando un select.....
Por otro lado conviene siempre usar el profiler para analizar antes las query pesadas y poder hacer los show plan del resultado de la ejecucion..... se deben evitar por todos los medios los tables scan a las tablas ya que la performance se degrada al maximo.
Por otro lado existen buffer pool a nivel del sql server que sirven para optimizar el uso de la memoria... eso lo define el dba; al igual que muchos otros parametros que se configuran para mejoras de desempeño.....

Sigo en otro... espera

monkyta · #5 (**permalink**) 09/11/2005, 16:52

Lo otro importantisimo es usar procedimientos almacenados; ya que estos una vez usados quedan en memoria por lo que su ejecucion es superior..... no le pongas opcion with recompile para optimizacion de desempeño... Ademas, el uso de proc. alm. implica una optimizacion del trafico de red ya que desde el ASP solo envias una ejecucion a un proc.... otro parametro importante a considerar es el trafico de red.
Lo otro es que debes siempre acortar las querys para no estar enviando miles y miles de filas... eso es lo mas malo (lo haces via where)
En relacion a las conexiones con SQL Server debes tratar de optimizar el pool de conexiones y por la parte de ASP siempre usa conexiones en donde permitas conectarte , hacer la operacion y desconectarte... esto se piensa que es malo pero es lo mas optimo ya que permites accesos multiusuarios y no saturas con conexiones tomadas al servidor sql...

Eso es lo que me acuerdo... ya que me toco trabajar con un join con 12 tablas en donde 1 era de 45.000.000 , 2 tablas de 12.000.000 , otras de 600.000 y otras mas chicas... y logre obtener una excelente performance... por lo que se puede

Eso puedo aportar

u_goldman · #6 (**permalink**) 09/11/2005, 17:10

Excelente aporte, deberias incluir esto en las FAQS del foro de bases de datos!

Dynk · #7 (**permalink**) 09/11/2005, 17:20

monkyta, como almacenas el resultado de una tabla en memoria?

monkyta · #8 (**permalink**) 09/11/2005, 17:23

Soy nueva en este foro ; por lo que todavia no se como funcionan las cosas.... cuando aprenda lo hare con otro aporte como este.....

monkyta · #9 (**permalink**) 09/11/2005, 17:27

Se me olvido comentarles que para optimizar mucho pero mucho mas este tipo de super querys con tablas muy grandes se usa...... el multiprocesamiento simetrico .... eso lo aportare mas adelante

richardinj · #10 (**permalink**) 09/11/2005, 17:33

Muy Bien... haré las pruebas...

Gracias.

AlZuwaga · #11 (**permalink**) 09/11/2005, 17:43

Cita:

Voy a mandarte esto primero ya que la sesion termina... sigo en otro para decirte mas cosas

Mónica (monkyta), para que no se te acabe tan pronto la sesión, podés especificar que se te recuerde al momento de hacer el login en el foro. Así, la sesión es "eterna".

Cita:

Soy nueva en este foro ; por lo que todavia no se como funcionan las cosas

A lo que u_g se refería es que además de éste mensaje, sería bueno que coloques lo mismo en el mensaje destinado a la FAQ del foro "Bases de Datos" (o de similar nombre, no lo recuerdo ahora)

Saludos

monkyta · #12 (**permalink**) 09/11/2005, 18:10

Gracias Al por decirme como mantener mi sesion activa.... estaba loca con esto ya que existieron muchas veces que no conteste de nuevo debido a que contestaba y como escribia mucho, la sesion me tiraba para afuera y se perdia todo... gracias por ese dato... pero de lo del FAQ quieres decir que debo escribir todo de nuevo o copy paste y llevarlo a esa seccion ?... me da un poquito de lata como decimos aca en Chile...
Para usar el FAQ debo escribir igual que aca ?
Existe algun procedimiento que puedo leer para entender bien como hacer esto..

monkyta · #13 (**permalink**) 09/11/2005, 18:17

Dynk para almacenar el resultado de una query puedes usar una tabla temporal que pueda ser vista por varios usuarios.... se dropea solo cuando no hay nadie usandola... ese tipo de tabla se crea con ##temporal por ejemplo.... ahora si quieres una tabla que te almacene la informacion por el tiempo que tu requieras usa una tabla temporal fija... este tipo de tabla la debes crear en la Base TEMP y no va con ningun signo # antes.....

Para generar los resultados en una temporal haces un
INSERT INTO (tu tabla temporal va aca)
SELECT xxxx .... aca va tu query

u_goldman · #14 (**permalink**) 09/11/2005, 18:24

Cita:

Existe algun procedimiento que puedo leer para entender bien como hacer esto..
Responder Con Cita

Entre mas te leo, mas me convenzo que pertences al ambiente puro de desarrollo!

tomchat · #15 (**permalink**) 09/11/2005, 19:25

SI trabajas con tantos registros, ningun metodo o codigo cambiara dastricamente los rusltados de tus búsquedas. Te recomendiendo que trabajes con mysql mas rapido y seguro, que msmysql que es muy pesado y ocupa muchos recursos...

u_goldman · #16 (**permalink**) 09/11/2005, 19:44

En realidad que yo sepa, MS SQL es mas eficiente para este tipo de cosas que MySQL, pero no me hagan mucho caso, lo he leido por ahi...porque nunca he tenido que lidiar con tantos registros, pero hasta donde se, es asi, MS SQL es mas solido que MySQL para un desarrollo de este monto.

De ahi, pues bueno, puedes optar por un PostgresSQL, o una cosa asi si en verdad es demasiado, pero MySQL, me parece que no, a ver si alguien opina lo contrario.

Salu2,

richardinj · #17 (**permalink**) 09/11/2005, 22:22

Dicen que MySQL 5.0 es mejor que SQL Server y mas rapido... será verdad?

3pies · #18 (**permalink**) 10/11/2005, 02:42

Yo alucino con vuestro nivel de conocimientos. Me quedo anonadado (para mí la mitad de las cosas de las que hablais me suenan a chino, porque a mí no hay quien me saque de access, jajajajaja).

SalU2, megaexpertos!

monkyta · #19 (**permalink**) 10/11/2005, 08:22

No u_goldman.... el desarrollo es lo que mas me apasiona; pero tambien me veras en otras secciones mas tecnicas aqui, o en otros foros que accedo; ya que he pasado por ingenieria de sistemas y me manejo muy bien con plataformas novell, microsoft, unix; asi como tambien como dba de varios motores aparte del ms sql server.... lo que pasa es que me encanta la informatica... eso es

3pies · #20 (**permalink**) 10/11/2005, 10:25

Monkyta, que no me entere yo que nos abandonas, einghhhhhh!!!!!.
¡¡¡Quiero verte aquí, día sí, y día también!!!

Aquí se pasa lista, ¡¡¡que lo sepas!!!.

Maravillado me quedo...

monkyta · #21 (**permalink**) 10/11/2005, 16:19

3pies eres muy amable y me has hecho reir mucho ... prometo que mientras tenga tiempo voy a ayudar o asesorar a quien lo necesite

saludos

richardinj · #22 (**permalink**) 10/11/2005, 17:34

Es raro ver una chica de sistemas que le guste la informatica y programar... en mi facultad la mayoria de mujeres no le gusta programar y mas se meten en cargos administrativos y gerenciales, mas no administran tecnologias de informacion... a diferencia de mis compañeros que ellos si tiene cargos de administradores de TI y algunos son gerentes de sistemas... pero en mujeres es muy raro... bien por ti MonKyTa.... eres de Peru??? de la UNI???

Ya me salio eso de los registros eran algo de 80 millones. y solo tarda 2 segundos con linea de 256Kbps... el truco esta en relacionar tablas lo maximo posible.... y un poco de AJAX...

un Abrazo.

tomchat · #23 (**permalink**) 10/11/2005, 17:59

U_goldman te digo que mysql es muy supeiror a Sql Server en muchas cosas y más si se trata de trabajar con millones de registros. Y en lo salido Sql es vulnerable a comparación de un mysql y ademas consume muchos recursos de hardware.

monkyta · #24 (**permalink**) 10/11/2005, 18:02

richardinj me alegro que hayas solucionado tu problema.

De lo otro puedo decirte que aca en mi pais (CHILE) tambien es un poco raro ver a una mujer desempeñando cargos que hacen mayoritariamente los hombres... pero lo he logrado con mucho esfuerzo y estudio....

saludos

tomchat · #25 (**permalink**) 10/11/2005, 18:04

monkyta

Me parece bien que estes en esto del desarrollo cualquier cosas aqui estoy

u_goldman · #26 (**permalink**) 10/11/2005, 18:07

monkyta: Tu esfuerzo y conocimientos se notan a km. de distancia, un placer que hayas parado por aca!

tomchat: Tienes alguna fuente confiable de esta aseveracion que estas haciendo? Seria interesante indagar en el tema, yo he investigado y en realidad me he encontrado con todo lo contrario a lo que tu dices.

Salu2,

monkyta · #27 (**permalink**) 10/11/2005, 19:05

chicos; agradezco de antemano la buena acogida que me han brindado.... de todos los foros que uso este es lejos el mejor; tanto en navegacion, interfases , rapidez, etc.... felicito a los creadores...... y lo mas importante .... me encanta encontrar gente con las que puedo hablar el mismo idioma no importando de que pais somos cada uno... es lindo eso y uds tambien

richardinj · #28 (**permalink**) 11/11/2005, 13:06

Tienes MSN???? XD