Am 25.11.13 23:47, schrieb Ian Harding:
That's enough to get me past this hurdle. I am not sure this is the right path...
my recommendation is to get an in depth understanding about the application specific performance implications of - the general performance characteristics (per-query response time, variance, degree of concurrency, throughput), - the application bottlenecks (database queries, database locks, mutex locks, computational expensive computations, calls to external services) and the - server environment and configuration (ranging from e.g. the linux file system to the web server configuration).
Recoding in C is just one option (which might be or might not be the right option for the best performance gain per invested effort). When the connection requests can be executed with no or little locks, the throughput can be improved nearly linearily on multi-core machines to a level determined by the number of available cores provided that neither i/o or the database are the bottleneck. If one needs to improve the per-request performance, from my experience, "modernizing" the Tcl code can lead already to substantial improvements (make sure to use constructs which are byte-compiled, brace expressions, use recent Tcl idioms such as the expand operator). Another important source for improving throughput is to exploit spooling rather than using blocking connection threads. On OpenACS.org such changes lead to a performance increase with moderate effort by a factor of 5 or 6 http://openacs.org/forums/message-view?message_id=4074774
I think we could make more money by doing less slicing and dicing of data in TCL and more in the database.
Tcl can be quite efficent on string operations, but it certainly depends on your application and on your expectations (if your requests are already in the 1 digit ms range, going to C might be the way to go). Often, performance is lost at places, where one does not look first, such as times spent on request setup (e.g. filters), templating, etc. NaviServer provides some means for better understanding where the time is spent by providing e.g. partial response times or per-thread cpu timings etc. which can be used for monitoring via tools like munin or for ex-post analysis from the access log. best regards -gustaf PS: in terms of scalability nsv are sometimes not the best choice, since the access to nsvs requires locks, and getting all keys of a large array can lead to long lock times. On low traffic sites (< 100.000 page views/day) that is probably not an issue. so it really depends on your site characteristics and type of application...
Thanks!On Mon, Nov 25, 2013 at 1:16 PM, Jeff Rogers <dv...@diphi.com <mailto:dv...@diphi.com>> wrote:Ian Harding wrote: I have a mountain of code in TCL, and I am thinking of rewriting some of it in C. In a C module I have a function that is registered to an URL. Like I said, I have a bunch of TCL code that I would like to be able to use until (if ever) it gets rewritten. I see that I can execute TCL code and get a string back via Ns_TclEval(). It seems to work, but my first attempt, foolishly, was to use a utility TCL proc that returns a db handle. I can execute it, and I get the string that represents the name of the handle, but that's not exactly the same as a C Ns_DbHandle. Is there any way to share stuff like db handles back and forth like that? The function to get a Ns_DbHandle from a handle name is NS_EXTERN int Ns_TclDbGetHandle(Tcl_Interp *interp, char *handleId, Ns_DbHandle **handle) You still have to honor the db handle lifecycle (i.e., release it at the end of a request) and sharing restrictions (don't share across threads) when you're in C code. I saw some functions for sharing an Ns_Set, but that's about it. I would appreciate any pointers for this kind of thing... I am just getting started. The header files in "include" are the definition of the public API. A lot of the functions aren't well documented separately, but most are documented in their source files. Using 'ctags' is helpful. Why are you rewriting? If it's intended for performance, make sure you are testing your performance and addressing the hotspots and not just things that look like they might be slow. There is an aolserver channel on freenode, it's quiet but there's typically a few people there. Feel free to stop by. Pretty basic pointers here, but they're all I have at the moment :) -J ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
-- Univ.Prof. Dr. Gustaf Neumann WU Vienna Institute of Information Systems and New Media Welthandelsplatz 1, A-1020 Vienna, Austria
------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
