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! [2] 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 [3] http://www.qcode.co.uk/post/121 [4] http://openacs.org/forums/message-view?message_id=4111406 [5] 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/ _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
