Forum OpenACS Q&A: OpenACS beta 3 / ACS Classic issues

Collapse
Posted by Roberto Mello on
Hi all,
I am seeing some issues with OpenACS beta 3/ACS Classic 3.2 that I
want to ask others and see if they've seen these issues as well:

Most of the problems I've found are in ad_abstract_url.

1) It seems that Netscape has problems with that. Many time it just
returns "document contains no data" for some reason that I don't
understand. IE seems to be fine. Anyone seen this ?

2) Sym links. ad_abstract_url makes no provision for symlinks. It
just simply returns a Internal Server Error. I think I'll fix that
and submit the fix to aD. It's really annoying not be able to use sym
links. On the other hand, it may be a good security measure 😊

3) ACS 3.2 seems to make many more queries for every request,
including the sec_sessions_* deal. What is that meant for ? Tracking
who's coming through https ? I don't even have it and I am getting
this stuff in my logs.

Now the AOLserver issues:

1) How to you tell AS 3 to map user dirs (~username) to public_html ?
I tried ns_param usermapdir "public_html" in ns/server/${servername}
but it didn't work.

2) Has anyone noticed a slow down when using nsd8x or is it my
imagination ? Does anyone know what advantages does nsd8x offer over
nsd76 ? I know Tcl 8.3 has a byte code compiler and
internationalization, but as far as programming issues go, what
advantages Tcl 8.3 offer ?

Thanks.

Collapse
Posted by Don Baccus on
Hey, Roberto, I just got back in town...

At the moment I can only help you with item #4, as I've not dug deeply  into 3.2 yet.  Kriston of the AOLserver crew claims that 8.3 is slower the 7.6, but thus far my attempts to nail down why have resulted in the usual hand-waving partial answer that seems to be typical of him.  My guess is that each .tcl page that's returned is compiled, rather than the page being compiled once and cached.  This indeed would lead you to expect slower execution times.  Supposedly 7.6 has more efficient threading (which was implemented by the AOLserver crew) but for lightly-loaded systems this shouldn't matter.  Compile times will overwhelm anything else.

There's a thread in the AOLserver discussion forums on this, check and  see if Kriston ever fully answered me when I asked the question if you want (I will myself when I catch up on e-mail, etc - my guess is that he hasn't).

Collapse
Posted by Roberto Mello on
Hi Don, nice to have you back 😊 When are you coming this way of the country ? Let me know.

About the Tcl 7.6 x 8.3 dillema, Jim Davidson posted a good response about this on the AOLserver community forums. I follow those foruns wia daily digest.  He points out advantages and disadvantages of both but gives no black and white answer. You should read it ('cause you'll understand it better than I since I am no C hacker yet 😊 and give us your feelings.

From what I understood, using the latest versions of Tcl will be better, but they (AOLserver crew and Scriptics) haven't adjusted it well enough to the point where it totally surpasses nsd 7.6. The choice basically remains to the user and his/her needs.

My home hard drive fried the other day after my fan broke in the middle of the night. Good thing I make nightly backups of important directories to an old 600 Mb drive I have laying around.

I had to reinstall my system from scratch and I went with Debian just to get familiar with it... I have to admit I am really surprised with how nice the whole system, administration and package management system work. It's just piece of cake to manage. Upgrading ? a glimpse.

This leads me to a question to Brent (or any other Debian user here): which package I need to compile AOLserver ? I seem to be missing something... libpthread ?

Collapse
Posted by Don Baccus on
OK, I went to the bboard at aolserver and checked for new responses to my question. Jim's answer indeed makes things clearer, though as he points out the answer isn't clear :)
  • Tcl scripts are recompiled every time a page is visited

    This indicates 8.3 ain't a particularly good choice for the ACS at this time, as compile overhead will more than eat up any execution savings for simple scripts. Tcl scripts are source'd, and there's no way for AOLserver to save and reuse the compiled bytecode that results.

  • A Tcl proc registered to a URL is compiled once

    Not much to add to this!

  • Tcl embedded in .adp pages is only compiled once

    Another argument in favor of using adp pages rather Tcl scripts. Apparently the adp page parser calls the compiler directly and is able to save the results.

    AOL has switched entirely to adp pages and the AOLserver folks more or less deprecate Tcl scripts, with Kriston being particularly critical of the ACS's use of them and suggesting aD rewrite their code. Fat chance :) So the supposed inability to cache bytecode for Tcl scripts may simply reflect the fact that they really would like Tcl scripts to go away.

  • adp pages don't really run faster

    The underlying string operations run slower as 8.3 correctly handles multi-byte characters, etc. The compiled bytecode runs a lot faster (after the first compile). There is more lock contention with 8.3 (for most of us probably not a serious problem, for AOL with its high load and high concurrency a problem). AOL's experience is that the slower underlying string primitives more or less balance out the gain from bytecode rather than pure interpretive execution IN THEIR ENVIRONMENT AND IN THEIR CODE.

    Jim points out that 8.3 also hits the heap in ways that causes lock contention in the heap management code, something AOLserver avoids if you use the -z ("zippy" heap management) option.

    He also points out that they find binary file I/O a boon in their download server apps.

No simple answer. For the ACS, at the moment I suspect that 7.6 wins pretty handily
Collapse
5: Debian Requirements (response to 1)
Posted by Brent Fulgham on
To successfully compile AOLserver you will need to install the various development tools (make, gcc, g++, binutils, etc.).  You will also want to have the current "unstable" version of PostgreSQL (since OpenACS won't run with PostgreSQL 6.5.3).

Please also be sure to install the "-dev" versions of the libraries.  These packages include the static libraries (for linking), header files, and other developer-related materials.

Specifically, libpthread.so should bin in libc6 packages (libc6 and libc6-dev).