This is an intriguing solution. If it were possible to configure ns_pools
to do that. I'm not too familiar with how this can be accomplished however.
Regards.
On Friday, March 20, 2015 at 8:54:10 PM UTC+8, Jeff Rogers wrote:
>
> Sep Ng wrote:
> > 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.
>
>
> Another thing to try out if you can distinguish static from dynamic by
> the url pattern is to use [ns_pools] to set up the server so that all
> static content is served from one threadpool and the slow dynamic pages
> from a different pool. These would still be ordinary conn threads (no
> background delivery), but it would keep the static requests from one
> user from queuing behind the dynamic pages from a different user. I
> haven't completely thought through exactly how this would work, but my
> first impression is that it would mean longer queuing times for dynamic
> requests, but more responsive servicing of static ones, so that pages
> would be slower to start but faster once they started.
>
> -J
>
>
>
> ------------------------------------------------------------------------------
>
>
> 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
> aolserv...@lists.sourceforge.net <javascript:>
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk
>
------------------------------------------------------------------------------
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
