Re: [AOLSERVER] Compression
Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
I have to agree with Tom. I don't think the application should be making decisions about if and when to send data compressed. I think it should be handled in the config the same as the character encoding is handled. Tom Jackson wrote: I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. begin:vcard fn:Jay J. Rohr n:Rohr;Jay email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Re: [AOLSERVER] AOLserver 4.5.0 on windows not exiting service
Hi, I don't think you lose anything -- Tcl_Finalize carefully tears everything down which is good when the code is used in an embedded system but in AOLserver as a normal process on Unix or Windows the resulting _exit doesn't care about all the work Tcl_Finalize may have done. -Jim On Apr 11, 2008, at 6:25 AM, Titi Alailima wrote: I checked out the exit code in nsmain.c and saw the following sequence: /* * Remove the pid maker file, print a final server exiting * status message and return to main. */ NsRemovePidFile(procname); StatusMsg(3); Tcl_Finalize(); return 0; The pidfile is getting removed, and the status message is showing up, so I figured it had something to do with the Tcl_Finalize. I commented that out and recompiled and the service exits fine. My question now is what do I lose by not calling Tcl_Finalize? Titi Ala'ilima Lead Architect MedTouch LLC 1100 Massachusetts Avenue Cambridge, MA 02138 617.621.8670 x309 From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Titi Alailima Sent: Thursday, April 10, 2008 3:53 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: [AOLSERVER] AOLserver 4.5.0 on windows not exiting service I’ve installed the binaries from http://www.friendlybits.com/en/inf_tec_en/win32openacs_en/ and even recompiled a couple small patches in and it runs fine. The only issue now is when I install it as a service (with –I) I can’t get the service to stop. I get this in the log file: [10/Apr/2008:15:40:01][3760.4040][-thread4040-] Notice: nsmain: AOLserver/4.5.0 stopping [10/Apr/2008:15:40:01][3760.4040][-thread4040-] Notice: driver: stopping: nssock [10/Apr/2008:15:40:01][3760.4040][-thread4040-] Notice: sched: shutdown pending [10/Apr/2008:15:40:01][3760.3728][-sched-] Notice: sched: shutdown started [10/Apr/2008:15:40:01][3760.3648][-nssock:driver-] Notice: exiting [10/Apr/2008:15:40:01][3760.3728][-sched-] Notice: sched: shutdown complete [10/Apr/2008:15:40:01][3760.4040][-thread4040-] Notice: driver: stopped: nssock [10/Apr/2008:15:40:01][3760.3828][-shutdown-] Notice: nslog: closing 'c:/Documents and Settings/Administrator/Desktop/cbinstall/log/ staging-access.log' [10/Apr/2008:15:40:01][3760.4040][-thread4040-] Notice: nsmain: AOLserver/4.5.0 exiting The nsd.exe process doesn’t ever terminate so the services manager never views the service as having stopped. If I kill the process manually, it can come back up again cleanly, but I’d like to not have to do that. Titi Ala'ilima Lead Architect MedTouch LLC 1100 Massachusetts Avenue Cambridge, MA 02138 617.621.8670 x309 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
Hey Dave, Which option would you prefer though? Thanks, --brett - Original Message From: Dave Bauer [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Friday, April 11, 2008 8:23:56 AM Subject: Re: [AOLSERVER] Compression Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On 2008.04.08, Don Baccus [EMAIL PROTECTED] wrote: AOLserver isn't a very popular webserver, but our small world includes people running large sites (you with your 10,000 sockets, in the OpenACS case university environments with 40,000 users running on our e-learning platform). It's important that the community be involved, and that changes not simply be made, announced in release notes, by fiat. Great! I agree. Lets try to come up with a list of 5 enhancements that we can all agree would be a good improvement and start working towards that. At the top of everyone's list seems to be improved documentation. What else? ... Eventually, we will settle on a list of things that we've eventually arrived at through this consensus-forming process. At that point, Don (or Tom), how do we go about actually accomplishing these tasks and completing these changes? Do we have any workable way of solving that problem? -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
I have to agree with Tom. I don't think the application should be
making decisions about if and when to send data compressed.
I think it should be handled in the config the same as the character
encoding is handled.
Tom Jackson wrote:
I thought that someone had suggested that the compression feature should be
handled without any flags, but based upon configuration parameters and
client
headers.
The main reason for this is because you would have to do the checks anyway,
does the compression library exist, can the client accept compression, etc.
Then what do you do if compression is requested and it doesn't exist?
Maybe this discussion happened over at OpenACS.org, but this is equivalent
to
an ssl layer, in general the application layer shouldn't get involved in
this
type of detail.
tom jackson
Let me clarify this a little bit. First of all, it would use the existing
scheme for ADP pages. So, this part would not change at all. It would utilize
the existing configuration. Currently, for ADP pages to be compressed, you have
to do these things:
1) turn compression on in ns_section ns/server/${servername} as such:
ns_param gzipon
2) Specify the minimum size of the data that will be compressed in the same
section:
ns_param gzipmin 1024
3) In the ADP section ns_section ns/server/${servername}/adp, turn it on for
ADP
ns_param gzipon
4) In the ADP page, if you want the page to be compressed, you just do:
ns_adp_compress 1
So, what I am proposing is that ns_return follows a similar structure. When I
proposed having a flag (#3 below), I was merely mimicking #4 above. For me
personally, I think I would have compression on all the time (meaning, have the
server decide when to compress). But, I assume since ns_adp_compress command is
in there, perhaps there is some reason why you might not want to compress
certain pages. So, I believe the way it works with ADP pages is (i.e server
logic):
1) it first checks that ns_adp_compress is set.
2) if yes, then if would check if the client supports compress
(Accept-Encoding: gzip...)
3) if yes, it would then check the size, and based on gzipmin, would decide
whether or not to compress the data
Right now, I have in my sandbox just a new command, ns_returnz, which is
exactly like ns_return, but will set the Ns_ConnSetGzipFlag flag internally,
and then the server will do the same decisions as above in 2 and 3. I think
this would be my preferred option, although if someone happens to share some
light on maybe edge cases where you might want to turn it on/off in the script.
*If* we do decide to go with a flag (similar to ns_adp_compress), I would
like to see the default to be on.
So, in summary, the server will be doing most of logic. ns_adp_compress is
there (I presume) to handle edge cases. So, really, I think my question boils
down to whether or not to have a command to set the flag.
I hope that clears things up.
On Friday 11 April 2008 08:23, Dave Bauer wrote:
Dossy,
I think the discussion is just this:
As Bret clearly stated at the beginning of the thread:
1) modify ns_return to take a flag. The optional connid parameter
makes parsing the args a little trickier.
Current:
ns_return ?connid? status type string (is connid ever used??)
New
ns_return ?connid? status type string ?gzip?
OR
ns_return ?connid? status type string ?-gzip boolean?
2) add a new command similar to the workarounds:
ns_returnz status type string
3) Expose Ns_ConnSetGzipFlag to the script level. This would be most
similar to how the ADP compression is done
I would like to see it but I don't forsee being able to write the code.
Dave
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Compression
I agree with Tom. Would be great to have this option. ~ Alex. On Fri, Apr 11, 2008 at 12:01 PM, Tom Jackson [EMAIL PROTECTED] wrote: I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On 2008.04.11, Juan José del Río (Simple Option) [EMAIL PROTECTED] wrote: Suggestions? Ok, here I go... I was going to suggest adding support for another language apart from TCL... be it Mono. That'd give support for languages such as C#, VB, Python, and faster performance. ... am I too crazy? :) In order to support a language in the core, the language runtime must have these two non-negotiable properties: 1) Fully thread-safe 2) Embeddable Otherwise, the best you can do is execute code in the other language in a nsproxy outside of the nsd process space. This is why I started work on nsjsapi, support for in-process server-side JavaScript in AOLserver. SpiderMonkey, the JavaScript runtime, has both of those properties I listed above. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. Some things to think about ... -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On Fri, Apr 11, 2008 at 09:13:38PM +0200, Juan Jos? del R?o (Simple Option) wrote: Suggestions? Ok, here I go... I was going to suggest adding support for another language apart from TCL... be it Mono. That'd give support for languages such as C#, VB, Python, and faster performance. ... am I too crazy? :) Crazy, no. But I think the onus will be on you to actually add full support for whatever this other not-Tcl not-C language is that you're interested in. AFAIK, doing so is feasible, but so far, everyone interested in such support seems to have hacked at it for a while, and then lost interest and quit. See also: http://panoptic.com/wiki/aolserver/Languages Languages people have done that level of work for seem to include at least: Python, Standard ML, Objective Caml, Scheme, Ruby, and Perl. Vlad Seryakov wrote the OCaml module and apparently was using it for something real. The guys who did the ML support wrote up a nice paper on their use of AOLserver years ago, but I don't know if they've really used it much since then. Ah, probably not, as they apparently moved to Apache in Feb. 2007. I don't think the guy who was adding it ever actually used the Python support much, and the Scheme and Perl modules were definitely very early alpha development only. Probably the same for Ruby. People out there are probably using AOLservers Java and PHP modules for real, but more for integration with other existing code and libraries, NOT so much for new web development per se with AOLserver. If you want to add C# support, well, no one is stopping you... -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. I agree that smarter caching will definitely improve things. However, I think it depends on the use case for the web app. For example, my web app is an internal tool...and there are small number of users, hence not many request/sec. However, I am doing DB queries heavily with big payloads and my server is sitting in a remote office with a small pipe to the main office. So, in my case, gzipping definitely makes sense. I did some subjective tests, and for my case, compression seems to help. I have also been reading this book High Performance Web Sites, by Steve Souders (good book BTW), and he advocates compression. He's an engineer at Yahoo, and they did some detailed studies on this. Here is a cheat sheet for those who are interested: http://developer.yahoo.com/performance/rules.html However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). IMHO, I think the cost vs response time savings will lessen more in the future, so the benefits of compression will become more so. This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. It would be great if the core server would handle this ;) Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. At the very least, ns_returnz could be a wrapper for what ns_return would do after figuring out the config/compression engine, etc. But it is very unlikely that changing the ns_return API would be a good idea. You can also use a trie to hold a filter type list mapping file patterns and compression functions. The code for picking a threadpool should be easy to reuse for this. In fact, you might be able to add a new config param to the threadpool to enable compression, but the two groups might not overlap enough to help. tom jackson On Friday 11 April 2008 14:40, Brett Schwarz wrote: On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. I agree that smarter caching will definitely improve things. However, I think it depends on the use case for the web app. For example, my web app is an internal tool...and there are small number of users, hence not many request/sec. However, I am doing DB queries heavily with big payloads and my server is sitting in a remote office with a small pipe to the main office. So, in my case, gzipping definitely makes sense. I did some subjective tests, and for my case, compression seems to help. I have also been reading this book High Performance Web Sites, by Steve Souders (good book BTW), and he advocates compression. He's an engineer at Yahoo, and they did some detailed studies on this. Here is a cheat sheet for those who are interested: http://developer.yahoo.com/performance/rules.html However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). IMHO, I think the cost vs response time savings will lessen more in the future, so the benefits of compression will become more so. This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. It would be great if the core server would handle this ;) Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On 2008.04.11, Don Baccus [EMAIL PROTECTED] wrote: On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 16:25, Don Baccus wrote: On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. I agree, I'll stop confusing the issue. Please see my previous comments. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:41 PM, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. You could allow control by mime-type and size, though I'd say all but the shortest text/* files would benefit. And the Yahoo best practices page referenced earlier suggests that ALL text/* files will benefit, on average. Computers are actually quite fast these days, and while dial-up connections are becoming increasingly rare, the fact is that there are bandwidth bottlenecks that slow the pace at which bits are transmitted from your server to the user's browser. You could also have an explicit ns_returnz for those who want finer- grained control - leave compression off in your configuration file and explicitly request it if you want it. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) This is more micromanaging of delivery that's really required, IMO. Mostly you just want to make sure that only text/* or other uncompressed formats are compressed. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 16:41, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. If configuration is done using a trie, like threadpools, you will have very good control. I think the main point is that ns_return is not the place to decide this, it leads to very brittle code. Also, if I remember correctly, the ns_zlib module can be configured to only compress data which is larger than some minimum number of bytes. So even with a broad compression filter, you should be able to add parameters. For instance, look at Content-Length header, if than some amount, compress and rewrite the header and add others. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 17:00, Don Baccus wrote: You could also have an explicit ns_returnz for those who want finer- grained control - leave compression off in your configuration file and explicitly request it if you want it. Ug! Yes, this is more or less the basis of my suggestion: a separate API which would bypass the configuration setup. I think it is a dumb idea in general to use it, but it is much better than changing the ns_return API. My original suggestion to use something like ns_returnz was for testing and/or hacking. The configuration part of this code could be more difficult to get right than a simple new command. Like I said in a previous note, you could use a url pattern as a switch, but the idea of using the mime type is probably even better. In addition, it is very likely that this information will be available at the correct time, and the compression operation will always require modification of the headers, so mime type triggers seem very good. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On Fri, Apr 11, 2008 at 02:11:30PM -0700, Tom Jackson wrote: 2. The thread/shared memory/synchonization model is much better than C#, VB or Python, and is actually well documented because it is based upon the pthreads API (But it is also essentially mostly invisible at the application level). A Java 5 threads API, finally introduced some features that AOLserver has had for 'ever': http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/overview.html It is hard to say if these newer languages (C# and MONO) have these features, probably VB and Python don't: Btw, I was flipping through this book the other night, and I noticed its chapter 30, Threads and States. http://www.amazon.com/Programming-Lua-Second-Roberto-Ierusalimschy/dp/8590379825/ Programming in Lua, Second Edition, by Roberto Ierusalimschy Lua has states, which are sounds equivalent to Tcl interps, and threads, which are lightweight cooperative non-concurrent user-threads, normally used only to support Lua's coroutines. Standard Lua runs in one OS thread only, but appears to be totally thread safe. That chapter basically walks through a simple example of how to take Lua states and threads, plus the usual POSIX pthreads C API, and construct a system for running concurrent lightweight Lua processes on multiple OS threads. He never mentions it (and may have been more inspired by Erlang), but that sounds exactly like the apartment model of threading that Tcl and AOLserver have had for years and years. (At least 10 years now, probably more? I don't really know.) Note, Lua does not actually include this lightweight-process / apartment-threading support at all, but I thought it was interesting that making it work like Tcl appears so straightforward. Ierusalimschy also has a recent paper that seems to give a pretty nice overview of concerns when designing embedable and extensible scripting languages: http://www.inf.puc-rio.br/%7Eroberto/docs/jucs-c-apis.pdf Hisham Muhammad and Roberto Ierusalimschy. C APIs in extension and extensible languages. In XI Brazilian Symposium on Programming Languages, Natal, May 2007. (to appear) Unfortunately, although he compares and contrasts Lua to Perl, Python, and Ruby, he barely mentions Tcl at all. That may explain why he didn't notice that Chapter 30 of his book basically recapitulates Tcl's Threading design... (Btw, I have never actually used the language, just read about it, but Lua's big weakness appears to be its relative dearth of standard libraries.) -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On Fri, Apr 11, 2008 at 02:11:30PM -0700, Tom Jackson wrote: It is hard to say if these newer languages (C# and MONO) have these features, probably VB and Python don't: task scheduling: ns_schedule_proc, ns_job concurrent collections: nsv arrays, ns_share, static vars (config structure) atomic variables: nsv arrays synchronizers: ns_mutex, ns_cond, etc. Incidentally, those aren't so much language features, they're more features of the AOLserver/Tcl API and environment. Tcl didn't have nsv_* or ANY of the cool stuff above until Jim Davidson and crew added them to AOLserver sometime c. the mid 1990's, after all... Some languages, and especially language implementations, would no doubt be much more amenable to supporting those sorts of AOLserver derived APIs than others, of course. But if you pick an appropriate language and implementation to start with (e.g., JavaScript Spidermonkey, Lua, some Scheme systems), it's PROBABLY just a Simple Matter of Programming. :) -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Active participation (was: RE: [AOLSERVER] Minor facelift to aolserver.com)
On Friday 11 April 2008 19:31, Andrew Piskorski wrote: On Fri, Apr 11, 2008 at 02:11:30PM -0700, Tom Jackson wrote: It is hard to say if these newer languages (C# and MONO) have these features, probably VB and Python don't: task scheduling: ns_schedule_proc, ns_job concurrent collections: nsv arrays, ns_share, static vars (config structure) atomic variables: nsv arrays synchronizers: ns_mutex, ns_cond, etc. Incidentally, those aren't so much language features, they're more features of the AOLserver/Tcl API and environment. Tcl didn't have nsv_* or ANY of the cool stuff above until Jim Davidson and crew added Right, which is why talking about adding a language is somewhat the wrong question. AOLserver is more of a framework, although Java/C# also have somewhat hidden frameworks for concurrency/memory management. You can't just add a language to AOLserver, because most languages don't provide the same high level framework. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
- Original Message From: Tom Jackson [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Friday, April 11, 2008 5:14:24 PM Subject: Re: [AOLSERVER] Compression On Friday 11 April 2008 16:41, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. If configuration is done using a trie, like threadpools, you will have very good control. I think the main point is that ns_return is not the place to decide this, it leads to very brittle code. Also, if I remember correctly, the ns_zlib module can be configured to only compress data which is larger than some minimum number of bytes. So even with a broad compression filter, you should be able to add parameters. For instance, look at Content-Length header, if than some amount, compress and rewrite the header and add others. Yes, see my earlier post...there is the gzipmin param that controls the minimum length to compress. The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): http://httpd.apache.org/docs/2.0/mod/mod_deflate.html Amoung other things, you can specify the mime type and browser type to decide on compression as well. Ultimately, here is what I would like to see: 1) config param to enable compression (this is already there) 2) config param to set the minimum size (this is already there) 3) config param for file/mime type to compress. Note that this would take care of the *.adp and *tcl pages as well. 4) Have a command (ns_compress) that could override gzip setting per request/page Or, have a separate command (ns_returnz) that does the over riding. Logic would be: 1) check if compression is enabled globally (#1 above) 2) check file type/mime type to see if compression is enabled 3) check content length to see if gzipmin 4) Override the above if ns_compress is set I think this gives a good control over what you end up compressing. If you are in a high bandwidth, high requests/sec, you might turn off compression, or have gzipmin at a high level. If you are at the other end of the spectrum (me), you will most likely be compressing most things. BTW, one thing I left out in an earlier post. For those interested in the Yahoo performance tips, and for those that use Firefox...there's an extension called YSlow that you can add that will test a web page's response against the 10 performance tips I referred to earlier. It's actually very useful. Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): I just want to remind folks that Apache's design is config-driven by necessity, not by intentional design. In the Apache world, server-based modules are _only_ actionable at configuration time. When you implement gzip compression in PHP, for example, I believe PHP handles all the compression itself--it doesn't communicate back to mod_deflate to handle it. In AOLserver, we DO have the benefit of being able to interact with the server from application code. This allows us to design and implement things better than in Apache, where everything has to be done at config. time or entirely within the application code. I do hope folks keep this difference in mind when trying to design the implementation for AOLserver. I hope it will result in a better solution than what's currently available in Apache. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
