Filtered by popular tag performance, 1 - 3 of 3 Postings (
all,
summary)
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 16 Oct 2016, at 12:38 PM
In order to speed up file-deliveries, one can use the background delivery methods provided by xotcl-core. The main advantage is that with background delivery the costly connection threads are just used for permission checking and locating the file, and the time-consuming spooling of the file to the client is implemented in an asynchronous background delivery thread. Therefore, connection thread are not blocked, it is possible to spool simultaneously several hundred (thousand?) files with only a few connection threads configured.
We use this in production since several years. For example today (no semester yet) we had so far 150.000 file deliveries by background delivery.
The asynchrounous background delivery requires a small patch (2 changes, one is a backport from naviserver) and the tcl thread library (by zoran). The application code is in XOTcl is only a few lines of code and is included in xotcl-core (bgdelivery-procs.tcl).
One needs the following patch to
The patch is already included in the current head version of aolserver 4.5 and in NaviServer.
With this patch and xotcl-core, one can replace
ns_returnfile 200 $mime_type $filename
by
ad_returnfile_background 200 $mime_type $filename
e.g. in cr_write_content in acs-content-repository/tcl/revision-procs.tcl to activate it and to deliver files from the content-repository (file-store) in the background.
The connection thread is only used for permission management, localization of the file and writing the the reply header, the actual delivery of the file is performed via asynchronous io without using up many resources. This can handle probably a couple of thousand concurrent file deliveries without running out of resources.
Check the files that has been served since the last reboot of your NaviServer/aolserver using this method from the developer support shell:
bgdelivery do set delivery_count
Original thread:
https://openacs.org/forums/message-view?message_id=482221
Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 16 Oct 2016, at 12:38 PM
In order to speed up file-deliveries, one can use the background delivery methods provided by xotcl-core. The main advantage is that with background delivery the costly connection threads are just used for permission checking and locating the file, and the time-consuming spooling of the file to the client is implemented in an asynchronous background delivery thread. Therefore, connection thread are not blocked, it is possible to spool simultaneously several hundred (thousand?) files with only a few connection threads configured.
We use this in production since several years. For example today (no semester yet) we had so far 150.000 file deliveries by background delivery.
The asynchrounous background delivery requires a small patch (2 changes, one is a backport from naviserver) and the tcl thread library (by zoran). The application code is in XOTcl is only a few lines of code and is included in xotcl-core (bgdelivery-procs.tcl).
One needs the following patch to
The patch is already included in the current head version of aolserver 4.5 and in NaviServer.
With this patch and xotcl-core, one can replace
ns_returnfile 200 $mime_type $filename
by
ad_returnfile_background 200 $mime_type $filename
e.g. in cr_write_content in acs-content-repository/tcl/revision-procs.tcl to activate it and to deliver files from the content-repository (file-store) in the background.
The connection thread is only used for permission management, localization of the file and writing the the reply header, the actual delivery of the file is performed via asynchronous io without using up many resources. This can handle probably a couple of thousand concurrent file deliveries without running out of resources.
Check the files that has been served since the last reboot of your NaviServer/aolserver using this method from the developer support shell:
bgdelivery do set delivery_count
Original thread:
https://openacs.org/forums/message-view?message_id=482221
Created by Gustaf Neumann, last modified by Gustaf Neumann 10 Oct 2015, at 02:42 PM
Munin is a popular web-based tool to monitor several website. Munin provides a simple plugin mechanism for adding new kinds of sources, such as e.g. the NaviServer plugins for monitoring NaviServer.
The monitoring information collected by munin can be placed at different web servers, one finds usually information about apache and friends. In general older versions of munin (before 2.0) supported only static pages, whereas newer version support as well dynamic information (with additional features such as zooming).
For static munin pages, it is the easiest to place in OpenACS sites the output directory either under the main www directory, or under the subsite admin directory (packages/acs-subsite/www/admin/).
For the cgi-setup, one has to make sure to load nscgi in the statup files of NaviServer and to point the urls to the appropriate directories. The sample setup below uses the directories of munin as provided by a standard munin setup on an Ubuntu system.
ns_section ns/server/${server}/modules
ns_param nscgi nscgi.so
ns_section "ns/server/${server}/module/nscgi"
ns_param map "GET /munin-cgi/munin-cgi-graph /var/www/cgi-bin/munin-cgi-graph"
ns_param map "GET /munin-cgi/static /etc/munin/static/"
ns_param map "GET /munin-cgi /var/www/cgi-bin/munin-cgi-html"
