I would keep old initialization if i need speed, if performance is going to suffer with Tcl/ns_ictl approach, then for fast/busy sites we need to be able to use old(fast) way. Otherwise, the server will be limited for non-realtime or personal web sites usage only.
Zoran Vasiljevic wrote: > Hi! > > After spenging a weekend over this, I know less than > before... > > The question is how we are going to improve the Tcl > initialization so people could benefit from that better > than now? > > As of today, what we have is: > > a. > introspective script based on the "old" way as 4.0 AS > did it (init the interp by loading all Tcl files then > run a script to pull-out namespaces, variables etc and > create a script that get saved with [ns_ictl save] > and run in each new interp by [ns_ictl update]) > > b. > the ttrace way of setting Tcl traces on selected commands > and have the "things" setup by those commands record in > shared nsv arrays. Then use Tcl [unknown] to pull out the > "things" on as-needed basis from shared arrays > > Well, none of those is really good. The a. is limited in > what it "introspects". The b. is pretty complex and in some > situations it does not work as expected (although there is > no design problem there, more probably just a bug or lack a > feature). > > Now, we do have [ns_ictl trace] where one can register things > to execute at interp creation, allocation etc. > So, I tried to do a simple thing: for each script executed > during the startup of the server I create > [ns_ictl trace [list source $file]] > create-trace. > > This "mostly" works, but has two negative effects: > 1. all scripts needs to be re-adjusted as they are going to > be sourced more than once (for each new interp) > 2. in case 1000's of files are needed for the startup this may > pose significant delay in interp creation > > I think that old AS approach is the worst as it is really limited. > The Tcl-trace based approach is better but is known to have some > problems (I do not know which ones), yet, it is pretty powerful > and has some other nice side-effects (less memory footprint). > Lastly, the [ns_ictl trace] is simplest to understand and deploy > (this is also very important) but requires rewriting of existing > scripts and most probably needs somekind of caching to speedup > the load process when 1000's of startup files are involved. > > For me, the Tcl-trace or ns_ictl trace are the way to go. > Looking at those two, the latter is more appealing since of the > simplicity, but it may hit us hard speedwise. OTOH, the former > is faster and uses far less resources but is pretty complex in > implementation (this might be done simpler, yes, yet it is always > going to be more complex than ns_ictl trace). > > Now, what you all think? Should we do something there or should > we just stay with the old AS introspective script? > > Cheers > Zoran > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
