2

Closed

Performance of retrieving a list of workflow

description

I'm experiencing some performance problems @home. I just want to understand why and if is it possible to find a solution.
Actually:
How many connection have we for retrieving a list of workflows ?
How many SELECT have we ?
Are they parallel or sequential ?
Closed Jun 24, 2009 at 3:38 PM by Mezzetti
solved

comments

thegood85 wrote Jun 1, 2009 at 12:52 PM

The problem is very simple: you don't have the database in your local computer.

The problem you are experiencing won't appear in a normal setup, because nobody is so crazy to put the database of a dynamic site inside the same network.

Going deeply,
1) I don't know the number of connection
2) I don't know the number of queries sent to the db
3) I don't know if they are sequential or parallel.

Simply because that depends on the implementation given by storage.

I can only say that, as we need part of the data of every workflow stored, we do a simple iteration on an entityset.
It could be 1 or N queries, they could be sequential or parallel, it may need 1 or N connections.
It depends on how smart is the implementation.

thegood85 wrote Jun 1, 2009 at 12:54 PM

nobody is so crazy to put the database of a dynamic site inside the same network.

Typing error: nobody is so crazy to put the database of a dynamic site outside the same network.

Mezzetti wrote Jun 1, 2009 at 1:10 PM

I don't know who write this code but
even if there is only one connection
even if db server is in my local network
we have ONE select foreach workflow-name to retrieve.

This means to multiply every user action * 100...

Pitta wrote Jun 1, 2009 at 3:22 PM

Perdonate se non scrivo in giargianese, già non ci si capisce in itaGliano dal vivo, figuriamoci qui.
Partiamo dal presupposto che il server è un rottame, la rete è ingolfata già di suo, se poi fate le prove con quelle ridicole connessioni wifi
della fuckoltà fate prima a farvi dettare i byte in esadecimale a telefono dal sistemista.
Eseguire il progetto in locale con un database remoto non è proprio il massimo, ma del resto, se qualcuno non si è ancora degnato
ad allestire un webserver sulla stessa macchina dove gira MSSQL non vedo alternative...
Detto questo, in quelle rarissime volte in cui mi è capitato di vedere del codice + "alto", ho constatato in più di un'occasione un uso distorto di alcuni metodi dello storage, spesso frutto di workaround, che ingolfano il DB con un numero abnorme di query, si tratta principalmente di [nested] loop (JOIN artigianali) o , nel caso specifico, di preloading inutile di dati: non so se le cose sono cambiate ma l'ultima volta per restituire una semplice lista di workflow name (lista di stringhe, esiste un medoto storage che lo fa) si chiedeva al DB TUTTI gli oggetti workflow con tanto di deserializzazione.
Per quanto riguarda il numero di connessioni al DB, questa è sempre e soltanto una per ogni istanza dello storage manager che viene chiusa e aperta secondo le specifiche di LINQ e gli altri giocattoli .NET che, come è giusto e sacrosanto che sia, ignoro.
La concorrenza/serializzabilità sono gestite dal DBMS stesso.
Ovviamente, come già detto in passato, instanziare uno storage manager nuovo per ogni metodo non è una buona idea.

wrote Jun 1, 2009 at 3:25 PM

wrote Jun 24, 2009 at 3:38 PM

wrote Jan 31, 2013 at 9:28 PM

wrote May 8, 2013 at 4:53 PM