Am 20.03.15 um 05:47 schrieb Sep Ng:
Hi Gustaf! Thank you for the informative response!
I've been thinking of moving to NaviServer but I don't know enough
about the transition to make that call yet. Right now, we're on
aolserver and so, I'm trying to see what I can do on this platform. I
do not understand why the delivery doesn't work on https out of the
box and requires a reverse proxy.
bgdelivery takes the socket (file descriptor) of the current connection,
but it has no knowledge about SSL. When it hands the file descriptor to
the background delivery thread, this can write back to the client just
using plain tcl i/o. So, background delivery can certainly write to the
file-descriptor, but that won't be accepted by the client trying to
decrypt the channel.
I suspect the varied client connection is part of the problem and them
sitting on the connection threads is hurting us.
what is hurting you?
However, we do not serve big files on our server so this has me
wondering about the benefits of this change.
whatever big means. connections can "hang" also when writing a few KBs.
I'm not certain if aolserver has any facilities for asynchronous file
writing and spooling.
the writer threads are an extension of naviserver over aolserver
It seems that I will have to build everything by hand. I had hoped
that simply transferring the thread and having it ns_returnfile would
be enough to get a simple form of background delivery going but it
doesn't look like that's the case.
if your site requires https, one cant use bgdelivery without a reverse
proxy.
otherwise, everything is pre-packaged.
-g
Regards.
On Friday, March 20, 2015 at 12:03:52 PM UTC+8, Gustaf Neumann wrote:
Dear Sep,
The question whether it is worth to use asynchronous delivery boils
down to a question of usage pattern and desired scalability.
The general problem with serving (large) resources via
classical aolserver is that a connection thread is unable
to handle other threads for the time span of the delivery.
It is important to understand that the time span of the delivery
is mostly
determined by the client. A client with little processing power
connection
over e.g. a mobile phone can block a connection quite a long time. A
special instance of this is the slow-read attack [2], which is
a special denial-of-service attack.
To serve e.g. 60 concurrent files one would require 60
connection threads. Note that this can happen quite soon when
serving content with several included resources (images, css, js)
the first time to a client. When the server runs out of connection
threads, the requests are queued, which means that the
the user-perceived runtime of a request is actually queueing
time plus execution time.
Background delivery (as described in [2]) is fully integrated in
OpenACS
addresses the problem by delegating output spooling (file deliveries)
to a single thread, which can deliver easily several 100 concurrent
downloads by using Tcl's asynchronous I/O operations. Note that
this works not only for static resources, but as well dynamic
requests (e.g. generating long HTML pages from e.g. a database).
We used this approach with very good success since 2006
in large OpenACS installations (with e.g. 2000 simultaneous
active users; "simultaneous active" means here users who
requested pages within a time interval of 5 secs).
In OpenACS, one can use simply ad_returnfile_background [3]
instead of ad_returnfile to make use of background delivery.
The limitations of background delivery are that (a) it just works for
plain http, and (b) that it works for at most 1024 concurrently open
file handles. We addressed (a) by using a reverse proxy in front
of the server, which delivers the files from the backend via https.
The limitation (b) is harder, since it depends on Tcl's usage of the
select()
system call, which allows to wait for events for max. 1024 file
descriptors. Above this limit, it simply crashes. Lifting this limit
in systems like Linux is possible, but requires a privately compiled
libc and linux kernel. You might think, 1024 this is much more
one needs, but we were actually running close to this limit for
lecture casting (video streaming of university lectures).
A better approach is to use NaviServer.'s c-level support.
NaviServer provides lightweight c-implemented
writer-threads using asynchronous I/O similar to
bg-delivery, but not using select(). The writer threads
works seemless with http and https. As with bgdelivery, a single
writer thread can serve a multitude of concurrent deliveries.
When several writer threads are defined, the load is split up
between these. NaviServer can also serve streaming
HTML (multiple ns_write commands) via writer threads.
It also support static and dynamic gzip deliveries see e.g. [3]
When one uses OpenACS with NaviServer it will automatically use
writer-threads when configured. In reference [4] on can see the
difference in response time (actually the time duration spent
in connection threads) in NaviServer. OpenACS.org runs
on NaviServer since Sep 2014. A more detailed discussion
of these properties is in [5], all of this is part of NaviServer
4.99.6.
sorry for the longish reply,
-g
[1]
http://openacs.org/xowiki/Boost_your_application_performance_to_serve_large_files
<http://openacs.org/xowiki/Boost_your_application_performance_to_serve_large_files>!
[2]
http://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack
<http://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack>
[3]
http://openacs.org/api-doc/proc-view?proc=ad_returnfile_background&source_p=1
<http://openacs.org/api-doc/proc-view?proc=ad_returnfile_background&source_p=1>
[3] http://www.qcode.co.uk/post/121 <http://www.qcode.co.uk/post/121>
[4] http://openacs.org/forums/message-view?message_id=4111406
<http://openacs.org/forums/message-view?message_id=4111406>
[5]
https://next-scripting.org/xowiki/docs/misc/naviserver-connthreadqueue/index1
<https://next-scripting.org/xowiki/docs/misc/naviserver-connthreadqueue/index1>
Am 19.03.15 um 07:09 schrieb Sep Ng:
> Hi all,
>
> I've been reading up on aolserver background delivery tricks on
> OpenACS and I've seen that the patches for the static TCL
channel is
> already in 4.5.1. In the spirit of improving server
performance, I've
> been wondering if such facility is worth building on the custom
app to
> increase concurrency and scalability.
>
> Most of the time, our aolserver also has to handle incoming
requests
> for multiple jpeg, javascript libraries, and a lot of other things.
> Freeing up the connection thread sounds very useful in
improving the
> server scalability so I wanted a little bit of help on getting
this to
> work.
>
> It's been hard trying to wrap my head around using ns_conn
channel and
> what I can actually do with this static TCL thread. It seems
that I
> should be redefining ns_returnfile to use background delivery.
Could
> I use it to push a TCL proc that generates given the parameters,
the
> dynamic page to this TCL channel to free up my connections?
>
> Sep
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel
Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your
hub for all
things parallel software development, from weekly thought
leadership blogs to
news, videos, case studies, tutorials and more. Take a look and
join the
conversation now. http://goparallel.sourceforge.net/
<http://goparallel.sourceforge.net/>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk
