| Author |
 Topic  |
|
Nathan
Help Moderator
USA
7664 Posts |
 Posted - 03 April 2002 : 20:30:24
|
Gremlin, mod-writers like me don't have a query analyser.
(Well, ok, not like me. I cry when I have to add another query anyway.  )
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's |
 |
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 03 April 2002 : 20:38:52
|
The problem is mainly when your an admin, as a user you get a lot fewer queeries any way. It is a rather meaningless value, just because a page performs 300 queeries does not make it slow, it could perform 1 queery and take 0 mins to return. If a the queeries are repeated over and over (which sometimes they are) they are cached any way.
|
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 03 April 2002 : 20:45:08
|
quote:
when you are calling several hundred on a page, quite afew.
Isn't the point to have it called as few times as possible?
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 03 April 2002 : 20:46:52
|
Ok, now I am going to shut up and eat my humble pie.
Richard you have already added an abstract layer for the sql to deal with TOP and LIMIT, we could merely pass all queeries through this and do the count in there if you wish, plus you would need to set the counter to 0 in inc_header
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 03 April 2002 : 21:09:19
|
quote:
Gremlin, mod-writers like me don't have a query analyser.
(Well, ok, not like me. I cry when I have to add another query anyway. )
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's
Which Is why I'm offering to help out.
that little play around we had with Active.asp the other week taught me one lesson, and this is how I think it got so bad on that one page.
What we all have a tendancy to do I think is write small functions which perform certain simple tasks that we use regularly (which is exactly what functions should be used for) however whats happened over time is that you end up building functions which recurse into other functions so you end up with
Function A which performs one database call, calls Function B to get a paramter for its own DB call which adds another call to the DB, sometimes then a 3rd function is called to get another paramter which leaves us with yet another DB call.
So with all this nested function calling going on, without really realising it your adding 3 or 4 DB calls to a page which could have actually been achived with a single query without using the functions.
The only way to avoid this is to perhaps limit functions so that they are non-DB related, and force the coders to write SQL only when in fact they need to do a call from the DB, OR alternatively setup all the common variables at the start of each page so that you only call the DB once for this commonly used info like M_NAME, MEMBER_ID etc etc.
I've started doing the later on a few pages and its helped considerably, of course there is an impact doing it this way as well, but for now I'm personally happy to wear the small extra overhead doing it this way vs the saving of 50-60 calls on most pages. Even with MOD's installed I think I'm down to a maximum of 8 calls to the DB per page generation.
One MOD I noticed that benefited from this was the Avatar MOD, the version I ran called the DB to get the height/width information from the DB every time an avatar was displayed, I just moved this into the App Variables and that saved upwards of 25 calls per page (relative to the number of replies per page you display)
www.daoc-halo.com |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 03 April 2002 : 21:16:33
|
quote:
One MOD I noticed that benefited from this was the Avatar MOD, the version I ran called the DB to get the height/width information from the DB every time an avatar was displayed, I just moved this into the App Variables and that saved upwards of 25 calls per page (relative to the number of replies per page you display)
The only explination for why it was done that way that I could come up with is to insure compatability with all versions of snitz.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 03 April 2002 : 21:26:17
|
Gremlin,
a lot of the function issues you mention have been fixed in 3.4, I have spent a lot of time going through inc_fuctions and split it up into 6 smaller includes, amalgamated several functions into a single function and removed all the calls which fetch the member id as it is already done in inc_header, so should never need to be set again. There have been some significant improvements, but we still acnot tweak it as much as you, as we have to think of everyone elses situation, and for many, executing 100 queeries is a lot less impeding on their server than storing the information in strings or session variables, so some ideas will have to be implemented specifically by users rather than as a general overhaul.
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 03 April 2002 : 21:26:39
|
No explanation needed, its a great mod, just a small exmaple though of how easy it is to get additional calls happening from the DB. You could just setup 2 variables in each page with the info you need rather than the multiple calls.
www.daoc-halo.com |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 03 April 2002 : 21:44:55
|
absolutely, I think I eliminated over 70 calls to getmemberNumber which were unnecessesary.
|
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 03 April 2002 : 22:04:54
|
Sounds like you've done some great work on 3.4, I guess the thing to make sure now is that we all don't end up slipping back into the routine of calling functions where not required :)
www.daoc-halo.com |
|
|
|
snaayk
Senior Member
USA
1061 Posts |
Posted - 04 April 2002 : 00:49:04
|
Don't get me wrong, I like the idea of knowing how many queries are run. Especially since I would probably rape the code and use it on all pages on the site. What I am sayong is that a regular user will not care how many queries were made on a given page (unless its a tech site)
If it were to add overhead would it be worth it??
hmm...the last thing I need is some visitor of my site telling me I need to optimize my code... 
|
|
|
|
Podge
Support Moderator
Ireland
3775 Posts |
Posted - 04 April 2002 : 14:20:15
|
As far as counting queries goes its not really a measure of performance as each query is less/more expensive than the next (cpu wise), the only thing it will do is point out a page that has excessive queries when you know it should only have a few.
I can't imagine it affecting performance that much.
quote:
Richard you have already added an abstract layer for the sql to deal with TOP and LIMIT, we could merely pass all queeries through this and do the count in there if you wish, plus you would need to set the counter to 0 in inc_header
Sounds like a plan!
Podge
-----------------------
www.thehungersite.com
Click to donate free food.
Edited by - Podge on 04 April 2002 14:21:22 |
|
|
|
Aaron S.
Average Member
USA
985 Posts |
Posted - 04 April 2002 : 14:50:02
|
quote:
Sounds like you've done some great work on 3.4, I guess the thing to make sure now is that we all don't end up slipping back into the routine of calling functions where not required :)
www.daoc-halo.com
This is a situation where even the barest of documentation would help exponentially.
Even just a 1 page SDK FAQ would work. It would have a listing of commonly accessible variables, etc. That way people building MODs wouldn't need to dig threw code to try and understand what was going on, or they wouldn't just run another query to get MEMBER_ID because don't know where that value is being stored.
--Aaron
MySubs Email MOD
MOD to Smile Mgr
HotKeys MOD |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 04 April 2002 : 15:02:52
|
I have compiled a list of what functions are in which includes and a basic summary of what they do. It is not completely finished, but is high on my priority list.
|
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 04 April 2002 : 15:41:12
|
quote:
a lot of the function issues you mention have been fixed in 3.4, I have spent a lot of time going through inc_fuctions and split it up into 6 smaller includes, amalgamated several functions into a single function and removed all the calls which fetch the member id as it is already done in inc_header, so should never need to be set again.
I haven't taken a look, but I'm glad to hear that you have gone through there. When I was working on this, I split up that file into 3 files. I found there were a lot of functions that weren't needed unless someone was posting (which were only needed for post.asp and the following file).
Good to see work is being done on the base code and not just adding features. 
|
|
|
|
Topic |
|
Topic Locked
