Thank you very much for shedding a lot of light into this.
On Friday, March 20, 2015 at 3:58:19 PM UTC+8, Gustaf Neumann wrote:
>
> > Am 20.03.15 um 07:48 schrieb Sep Ng:
>
>> what is hurting you?
>>
>
> > We have instances where we'd get a high number of concurrent users that
> the requests are getting queued, but when I look at the logs, there's a >
> lot of static files being served for each login page, let alone other pages
> being served in aolserver. So, I'm theorizing that being able to get those
> > static file requests pushed into a single thread and free up the
> connection threads would help in scalability.
>
> yes, there is a certain hope, that removing this burden from the
> connection threads will improve the situation. Another option to reduce
> queuing time is to increase the number of connection threads.
> If the bottleneck are slow sql-queries then this pooling stuff will not
> help.
>
> Right now, I do not believe sql queries are the culprit for the
sacalability issues. I have a better understanding on this now. I think
the only real issue from implementation stand point is getting the reverse
proxy setup right.
> Often the first task to determine, what the bottleneck is, can be already
> be difficult.
> NaviServer has several introspection means for monitoring. The following
> graph shows queuing times, filter and run times (you won't get
> these numbers from aolserver). The graph (from OpenACS.org) shows
> that queuing time is on that site typically around 0.1 ms, with peaks in
> the range of 16 ms. This is for example quite useful for determining the
> right number of running connection threads. naviserver allows to
> change this number dynamically without restart....
>
> [image: weekly graph]
>
>
This chart is something that would benefit us very much. NaviServer is
looking like a target I should be working towards in the future.
>
> > By the way, I've seen in previous posts of yours that the you did
> switch from aolserver to naviserver. How big was the change? What things
> did > you have to re-write/port to get them running in naviserver?
>
> We did the move of our main site 4 years ago (now we have around 50
> naviserver sites),
> but i do not have a detailed writeup of the changes. Most of our changes
> went into OpenACS (download OpenACS 5.8.1, search for NaviServer).
>
> what comes to my mind is:
> - NaviServer dropped the useless "$conn" argument from several commands
> (like old: "ns_return $conn 200 text/plain ..." -> "ns_return 200
> text/plain ..."
> - different modules (e.g. for ssl), different config file
> - more functionality built-in which was as a module under aolserver
> crypo functions (sha, md5), cache, base-64 encoding, gzip delivery
> (actually, the "ns_cache" function in naviserver usues a single
> command style (ns_cache_eval) and in aolserver subcommand style,
> but we added already a compatibility layer to the naviserver source tree
> which is sufficient for OpenACS
> - no ns_share (use nsv instead)
> - no "ns_set -persistent"
>
> We did not use the latter two, but this comes sometimes up in the mailing
> lists.
> The move was quite easy for us, but ymmv.
>
> There seems to be much work to be done and this can't be rolled out
quickly. I will have to spend more time on this when the time comes.
> -g
>
------------------------------------------------------------------------------
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
