provando a collegarsi alla pagina che presenta i ristoranti di milano
ottnego il seguente errore
[HttpException (0x80004005): Timeout della richiesta.]
http://www.gustoinrete.com/lombardia...ti-milano.aspx
purtroppo la query è pesantina e i dati vengono presentati utilizzando un datagrid (non il massimo della leggerezza)
è possibile risolvere il problema ?
Che DB usi ?
Cerca di ottimizzare la query creando indici opportuni . . .
Se usi il ViewState cerca un modo per limitarlo . . .
Cmq quale è la parte che impiega molto a esser processata ?
Serve qualche info in + . . .
Se lo scopo di un utente è quello di cercare un ristorante a Milano per mangiare,... sicuramente muore di fame prima di avere le informazioni che cerca.
E' difficile dire dove sta il problema. Subito subito ti dico di togliere il viewstate perchè è enorme e non serve un accidente di niente.
Io, se avessi (e ho avuto) problemi simili, comincerei a crearmi una paginetta vuota e comincerei a collaudare pezzo per pezzo.
Per essere chiari, prima collaudo la query, senza mettere altro, datagrid o altro, ma solo un misuratore di tempo per vedere quanto tempo ci vuole per cavarne fuori i dati. E' chiaro che se ci mette la morte di un cristiano per fame
Allora aggiungo magari un DataGrid etc etc.
ps. il problema potrebbe anche essere nella parte client se usi javascript in maniera non ottimale (almeno, questo era il mio caso)
ps. il problema potrebbe essere in Access, se lo usi con query un po' più complicati del normale.
Pietro
Esatto , access è una ciofeca . . .
Se hai molti visitatori levalo immediatamente perchè con 10 utenti connessi simultaneamente le performance crollano
Se ti può essere utile quì trovi i limiti di Access:
http://www.databasedev.co.uk/access_specifications.html
Purtroppo la mia esperienza è che, diverse volte, ad esempio per esigenze di estrema portabilità o perchè ci si deve appoggiare su un database esistente e non modificabile, si deve sviluppare in access e non si può, appunto, scegliere.
Se questi limiti possano davvero incidere sulla tua applicazione solo una calcolatrice te lo può dire.
Se invece non hai limiti sulla scelta del database, bhè, scegliendo SQL avresti innumerevoli vantaggi.
Io però, prima di rifare tutto, proverei a postare un po di codice fossi in te perchè ho in giro più di un'applicazione che con 5/600 accessi univoci al giorno su db access non sono mai crollate nemmeno in prestazioni.
Credo che tu debba arrivare a numeri a 4 zeri per avere un crash o un crollo di prestazioni come quello della pagina che hai linkato ...per me il 'problema' è nel codice.
ringrazio tutti i partecipanti
allora per cominciare il db è mySQL
ho provato a modificare la pagina tolto il datagrid inserito un repeater e ho pure eliminato il viewstate!
prestazioni migliorate... ma ci impiega una vita ugualmente !!
ecco la query
SELECT DISTINCT t1.id AS RID,t1.nome,t1.indirizzoREG,t1.indirizzoPROV,t1.in dirizzoCOMUNE FROM tbR AS t1 LEFT JOIN tbrelazioneristtip AS t2 ON t1.id = t2.idr WHERE t1.indirizzoCOMUNE = "& idcomune &" AND t2.idtipologia = "& idtipologia &" ORDER BY t1.nome ASC LIMIT 0, 50
avviso che è lentina anche se effettuata direttamente sul db con phpMyAdmin
considerate che la tab rist contiene 26.000 records e quella che gestisce le relazioni circa 35.000
nella pagina che vi postato inoltre per ciascun record vengono effettuate altre query per vedere se il rist ha commenti, valutazioni e foto
Query facilissima
Crea 2 bei indici non clustered su :
indirizzoCOMUNE
idtipologia
In questo modo :
Devi lanciarli uno alla volta in php come query normali.codice:CREATE INDEX IX_indirizzoCOMUNE ON tbR ( indirizzoCOMUNE ) CREATE INDEX IX_idtipologia ON tbrelazioneristtip ( idtipologia )
Vedrai come le performance migliorareno al 100%
Fammi sapere mi raccomando
perfetto ma l'utilizzo di indici non comporta dei rallentamenti quando vado a fare un INSERT o UPDATE ?
Non in maniera preoccupante. Un database con 35000 righe è un database ridicolmente piccolo. Ovviamente senza indici una select diventa lentissima. Pensa che io in azienda lavoro con tabelle che hanno mediamente 5 milioni di righe, e con gli indici messi correttamente la velocità è discreta.
Vai tranquilloOriginariamente inviato da brutusin
perfetto ma l'utilizzo di indici non comporta dei rallentamenti quando vado a fare un INSERT o UPDATE ?
Per le query di insert/update vai tranquillo , non avrai problemi . . .
L'unica cosa è che l'indice può perdere di efficacia col tempo e con le operazioni su quella tabella . . .
Quindi ogni 3/4 mesi se vedi che le performance calano , distruggilo e ricrealo uguale
In questo modo eviti la frammentazione etc. . .
Permessi di invio
Rispondi quotando