Author |
Topic |
Deleted
deleted
4116 Posts |
Posted - 27 April 2002 : 16:47:26
|
I ran a couple of simple performance benchmarks on for-us-important topics: variables, DIM'ming and Constants.
Introduction <ul> <li>Testbed: P3-733, 256MB Ram, Win 2K Adv Srv SP2, IIS 5</li> <li>I ran the scripts on the same machine using IE 5.5 SP 2</li> <li>The timer code of the forum is used to measure the execution time between the start and end of the script, so it will not include any disk I/O</li> <li>I used the Lang1033's variables (1972 vars) for this purpose.</li> <li>I ran the test 10 times and took the average. I each case the variance was not so high.</li> </ul>
I tried to determine which one is (how much) better: <ol type=1> <li>NON-DIMMED VAR'S versus DIMMED VAR'S</li> <li>VAR'S versus CONSTANTS</li> </ol id=1>
<b>COMPARISON-1 (uses files test1.asp and test2.asp)</b> I first tried to measure the effect of DIM'ming. DIM'ming of some thousands of variables also takes some execution time. As you might know, v4b03 has no DIM's. The pseudo code for the files are given below.
<b>test1.asp: 1000*(DIM+VAR-init)</b> <pre id=code><font face=courier size=2 id=code><font color=blue> timer start for i=1 to 1000 'DIM all vars, 4 vars in a line DIM strLangActive00010, strLangActive00020, strLangActive00030, strLangActive00040 ... 'assign all vars strLangActive00010 = "All Forums" '"All Forums" strLangActive00020 = "Active Topics Since " '"Active Topics Since " ... next timer stop </font id=blue></font id=code></pre id=code>
<b>test2.asp: 1000*(VAR-init only)</b> <pre id=code><font face=courier size=2 id=code><font color=blue> timer start for i=1 to 1000 'assign all vars strLangActive00010 = "All Forums" '"All Forums" strLangActive00020 = "Active Topics Since " '"Active Topics Since " ... next timer stop </font id=blue></font id=code></pre id=code>
Although I liked also to measure the <b>Const</b> case, could not run it in loop, because re-definition of a Const if forbidden. Therefore I made the second comparison.
<b>COMPARISON-2 (uses files test3.asp, test4.asp and test5.asp)</b> In this comparison I reformed the files in the first comparison and took the DIM & VAR initialization part out of the loop. I put N=1972 assignment statements into the loop.
In fact the second comparison better represents our case in version 4, where strings are defined and used (i.e. assigned). As the assignment part (loop) is the same for all tests, the difference must be because of the code outside. It can also be the case that the execution time of the "use" of the constants in the loop can be different than those of variables.
<b>test3.asp: CONST+1000*ASSIGN</b> <pre id=code><font face=courier size=2 id=code><font color=blue> timer start ' define all language strings as constants Const strLangActive00010 = "All Forums" '"All Forums" Const strLangActive00020 = "Active Topics Since " '"Active Topics Since " ... for i=1 to 1000 DIM s s = strLangActive00010 s = strLangActive00020 ... next timer stop </font id=blue></font id=code></pre id=code>
<b>test4.asp: DIM+VAR-init+1000*ASSIGN</b> <pre id=code><font face=courier size=2 id=code><font color=blue> timer start 'DIM all vars, 4 vars in a line DIM strLangActive00010, strLangActive00020, strLangActive00030, strLangActive00040 ... 'assign all vars strLangActive00010 = "All Forums" '"All Forums" strLangActive00020 = "Active Topics Since " '"Active Topics Since " ... for i=1 to 1000 s = strLangActive00010 s = strLangActive00020 ... next timer stop </font id=blue></font id=code></pre id=code>
<b>test5.asp: VAR-init+1000*ASSIGN</b> <pre id=code><font face=courier size=2 id=code><font color=blue> timer start 'assign all vars strLangActive00010 = "All Forums" '"All Forums" strLangActive00020 = "Active Topics Since " '"Active Topics Since " ... for i=1 to 1000 s = strLangActive00010 s = strLangActive00020 ... next timer stop </font id=blue></font id=code></pre id=code>
<b>TEST RESULTS</b>
<pre id=code><font face=courier size=2 id=code> <b> TEST-1 TEST-2</b> <b>AVG</b> 4.34 6.72 <b>VAR</b> 0.0017 0.0008 <b>INDEX</b> 100 155 </font id=code></pre id=code>
As you can see from the results given above, the UN-DIM'med case needs %55 more time to execute wrt the DIM'med case although there are 500 more lines of code for DIM'ming. This was an expected result
<pre id=code><font face=courier size=2 id=code> <b> TEST-3 TEST-4 TEST-5</b> <b>AVG</b> 1.99 2.87 5.89 <b>VAR</b> 0.0017 0.0019 0.0033 <b>INDEX</b> 100 144 296 </font id=code></pre id=code>
As you can see, use of constants outperformed the others. DIM'med case needs %44, UN-DIM'med case needs %196 more time to execute than the Constant case.
<b>PRELIMINARY CONCLUSION</b>
Until now, I used variables without DIM'ming. I was planning to use DIM's for v4b04, but these results seem to show us that the use of constants will be much better.
On the other hand, I feel that we have take the initial parsing time of the scripting engine also into account. In test2.asp and test5.asp, the memory for the variables are allocated during the script execution period (thus a lot higher values).
The times given above also do not take the file I/O into account (in the DIM case, there are around 500 more lines). The file sizes for test1.asp ... test5.asp are (253, 203, 270, 309, 259) KB's respectively.
I will run some "real stop-watch" tests to measure the time needed for the end user.
<font color=pink><b>Think Pink</b></font id=pink> ==> Start Internationalization Here |
|
Deleted
deleted
4116 Posts |
|
Deleted
deleted
4116 Posts |
Posted - 27 April 2002 : 18:19:10
|
I rebooted the machine and run the same tests but measured the time from F5 press to the point where the blue bar on the status window of IE disappears.
TEST RESULTS-2
TEST-1 TEST-2 AVG2 4.93 7.36 VAR2 0.0117 0.0097 INDEX2 100 149
AVG1 4.34 6.72 DIFF 0.59 0.63
TEST-3 TEST-4 TEST-5 AVG2 2.45 3.45 6.51 VAR2 0.0166 0.0113 0.0056 INDEX2 100 141 266
AVG1 1.99 2.87 5.89 DIFF 0.45 0.58 0.62
As you see there is about 0.6 sec overhead in each test compared to the results in the first post. So my final conclusion is using Const...
Think Pink ==> Start Internationalization Here< |
|
|
aecio
Junior Member
Brazil
120 Posts |
Posted - 28 April 2002 : 01:26:03
|
It is my experience that DIMed variable pages load faster. I do not have the technical explanation at hand (although I think I saw it at www.asp101.com), but since I started DIMming variables, I have had the impression that even without the Option Explicit statement, the pages load faster.
Cheers!
Visit the Healthy Planet online support community: www.xsaude.com.br/healthyplanet/" target="_blank">http://www.xsaude.com.br/healthyplanet/< |
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 28 April 2002 : 02:35:54
|
Errrm, has anyone suggested employing the application object for containing language strings? Then they would not need defined.
Nathan Bales Snitz Exchange | Do's and Dont's< |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 28 April 2002 : 07:51:13
|
Nice work bozden . That's another positive step in the quest for the best way to achieve performance in the Internationalized version of Snitz.
------------------------------------------------- Installation Guide | Do's and Dont's | MODs< |
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 28 April 2002 : 08:00:46
|
quote:
Errrm, has anyone suggested employing the application object for containing language strings? Then they would not need defined.
Nathan Bales Snitz Exchange | Do's and Dont's
I'm not sure if that is a good idea, I'm actually starting to wonder now if the High use of Application Variables isn't one of the problems thats stopping Snitz from scaling very well on high usage sites.
why I'm thinking this is becuase of "thread affinity" and "serialisation". Instead of me trying to explain this let me just paste a bit from an article I was reading last week.
-------------- An application variable lives until a web server shuts down. It also lives on a specific thread; we would say the object has thread affinity. Any script utilizing that object must live on same thread, as that object or make an expensive marshalled call to talk to that object.
Thread Affinity
Thread affinity is bad. If a request comes in it would be fast if any thread could perform the task. Thread affinity guarantees only 1 thread can service the request and if that thread is busy the task waits in line for that thread, despite other threads who may be able to service the request.
http://www.learnasp.com/advice/threads.asp explains threading fundamentals.
Serialization is an enemy of Scalability
If multiple tasks all have affinity to the same thread they become serialized, that is to say they all run in sequence. As a real-world analogy for serialization imagine you wanted to buy a meal at a fast-food cashier and the person in front of you ordered 150 sandwiches for their swim-team. You don't get your 1 sandwich until they finish their order. 6 request for 150 records from a database means the fourth request for 1 record comes after those 900 are retrieved. Without thread affinity the requests could be divided among available threads.
Conclusion: All recordsets and database access would have some level of thread affinity if one connection only is made in global.asa. The side-effect would be recordsets that were forced to specific threads and serialized requests effectively slowing a site's overall performance and for specific scripts. ---------------- Whilst this is specifically referring to defining your Connection using Application Variables, thinking it through then that must surely apply to all variable, its just a much much eviler thing for your scalability for having the Connection or Recordset stored in there.
Perhaps someone with a bit more knowledge than me can backup or add to this, I'm going to search a bit more for similar topics and see if I can't find anything more relevant myself.
www.daoc-halo.com
Edited by - Gremlin on 28 April 2002 08:05:14< |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 28 April 2002 : 08:21:17
|
Gremlin,
Your post does seem to raise an important issue and your assumption that the heavy use of App variables may lead to bad scaling from Snitz looks like a pretty reasonable one. Maybe a solution like the one for internationalization or even storing the values now in App vars in the DB could help better scaling...
------------------------------------------------- Installation Guide | Do's and Dont's | MODs< |
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 28 April 2002 : 09:13:10
|
I might actually just try grabbing the variables every page, yes it is another call to the DB, but personally I'm quite happy with the level of DB calls I have right now on most of my pages, most use less than 10 queries and I've still not looked at adding Views or SP's to try and combine some.
Was thinking something like this to just set the variables in inc_top.asp (this this will only work on IIS5+ though becuase I think thats when the Vbscript Execute statement was added)
<% Dim arrConfig, arrConfigCols, arrConfigRows, LoopCounter strConnString = "" set my_Conn = Server.CreateObject("ADODB.Connection") my_Conn.Open strConnString
'----------------- ' Column Constants '----------------- Const iC_VARIABLE = 0 Const iC_VALUE = 1
'---------------------- ' Get Variables from DB '---------------------- strSql = "SELECT C_VARIABLE, C_VALUE FROM FORUM_CONFIG_NEW " set rsConfig = Server.CreateObject("ADODB.RecordSet") set rsConfig = my_Conn.Execute(strSql)
'------------------ ' Put into an Array '------------------ if not rsConfig.EOF then arrConfig = rsConfig.GetRows() rsConfig.close() set rsConfig = nothing arrConfigCols = ubound(arrConfig,1) ' Number of Columns in RecordSet arrConfigRows = ubound(arrConfig,2) ' Number of Rows in RecordSet else arrConfigCols = 0 arrConfigRows = 0 end if
'-------------------------------------------------- ' Now use Execute to Dynamicly create the Variables '-------------------------------------------------- for LoopCounter = 0 to arrConfigRows Execute arrConfig(iC_VARIABLE,LoopCounter) & " ="" " & arrConfig(iC_VALUE,LoopCounter) & " "" " next
'------------------------------------ ' Test that Some Variables are Loaded '------------------------------------ Response.Write "Snitz Version String = " & strVersion & "<br/>" Response.Write "Copyright Notice = " & strCopyRight %>
www.daoc-halo.com< |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 28 April 2002 : 09:36:38
|
This looks like a good solution to me, and I don't think a single additional DB call will make much difference. That VB Execute statement can be a problem, though, but you can hardcode the assignments for IIS 4.0 and PWS, although that can slow down things a bit...
------------------------------------------------- Installation Guide | Do's and Dont's | MODs< |
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 28 April 2002 : 09:52:52
|
You could perhaps streamline it a little further too by looking at how the variables are named, for instance I have a single page which generates a CSS stylesheet for my from, that page only needs access to the various colour and style variables so If I rename then to perhaps strColor.... then I can change my select and reduce the data thats grabbed. Thats probably overkill for the 100 or so variables Snitz currently has, but it would add a little more flexibility/scalability.
www.daoc-halo.com< |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 28 April 2002 : 10:47:49
|
quote:
Thats probably overkill for the 100 or so variables Snitz currently has, but it would add a little more flexibility/scalability.
I agree with you. Looks like a bit overkill. And the need testing for the vars you need, depending on the page you "are on" may add a bit of an annoyance to it.
------------------------------------------------- Installation Guide | Do's and Dont's | MODs< |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
|
Deleted
deleted
4116 Posts |
|
Deleted
deleted
4116 Posts |
Posted - 28 April 2002 : 17:20:43
|
The application variables are considered at the very start, but this option was left out because it takes too much memory especially if you use more than one language. Also, as far as I know, accessing the values in application variables is much more slower than simple vbscript variables (now constants).
I remember myself trying this in my older machine a year ago (Celeron 466, 128 MB, W98, PWS), but as far as I can remember I could not get good results because the machine had a lot of disk access due to swapping...
I'll try to run such a test and show you the results...
Think Pink ==> Start Internationalization Here< |
|
|
Deleted
deleted
4116 Posts |
Posted - 28 April 2002 : 19:21:46
|
Here is the results for test 6 based on Application variables:
test6.asp: APPVAR-init+1000*ASSIGN
timer start 'assign all application vars Application("strLangActive00010") = "All Forums" '"All Forums" Application("strLangActive00020") = "Active Topics Since " '"Active Topics Since " ... for i=1 to 1000 s = Application("strLangActive00010") s = Application("strLangActive00020") ... next timer stop
TEST RESULTS-3
TEST-3 TEST-6 AVG 1.99 34.39 VAR 0.0017 0.0043 INDEX 100 1198
As you can see this case (test-6) is about 12 times slower than the best case (test-3: using Const)...
Think Pink ==> Start Internationalization Here< |
|
|
Topic |
|