[AOLSERVER] (no subject)

[Ian Harding]

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?

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.

Thanks,

Ian

[Jeff Rogers]

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
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

[Ian Harding]

That's enough to get me past this hurdle.  I am not sure this is the right path... I think we could make more money by doing less slicing and dicing of data in TCL and more in the database. 

 

Thanks!

[Jack Schmidt]

You could try nsv to manage the list of handles, but you'd need to still abide by the db handle lifecycle, but that's TCL code.

2013/11/26 Ian Harding <hardi...@gmail.com>

------------------------------------------------------------------------------
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
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

--
"A scrum a day keeps the pigs at bay"

[Gustaf Neumann]

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...

------------------------------------------------------------------------------
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
aolserv...@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