Re: [AOLSERVER] (no subject)

2013-11-26 Thread 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...

Thanks!


On Mon, Nov 25, 2013 at 1:16 PM, Jeff Rogers > 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
co

Re: [AOLSERVER] (no subject)

2013-11-25 Thread 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 

> 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!
>
>
> On Mon, Nov 25, 2013 at 1:16 PM, Jeff Rogers  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
>
>


-- 
"A scrum a day keeps the pigs at bay"
--
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


Re: [AOLSERVER] (no subject)

2013-11-25 Thread 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!


On Mon, Nov 25, 2013 at 1:16 PM, Jeff Rogers  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


Re: [AOLSERVER] (no subject)

2013-11-25 Thread 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
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk


[AOLSERVER] (no subject)

2013-11-25 Thread 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
--
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