Am 03.01.13 18:48, schrieb Jeff Rogers:
>
> Does it make sense to have 2 different information-gathering commands,
> tho? Why not consolidate all these functions into "ns_info", giving
> appropriate subcommands -server and/or -pool flags as necessary?
well, we have as well ns_conn and ns_thread providing introspection
about different kind of objects, so ns_server seems natural (one might
argue for a ns_pool cmd in naviserver). Pushing all these into ns_info
is problematic. Furthermore, the some of the commands for
ns_server/ns_conn/ns_thread might be used as well for setting such
values, which would not appear natural via ns_info. Last but not least,
backward compatibility speaks as well for ns_server.
btw, we have now
ns_server ?-server s? ?-pool p? maxthreads ?value?
ns_server ?-server s? ?-pool p? minthreads ?value?
to query/change the thread configuration at runtime. Now, one can have a
watchdog listening the wealth-indicators of naviserver and adjust these
parameters without reboot. This improves the situation until we have
really good autoscaling.
The new queue-lenght based thread calculation work quite well for
creating additional threads, but not for keeping the number of threads
sufficiently long on the higher value. If there are already e.g. 10
connection threads running and one starts due to a peak #11 (even with a
long timeout or connsperthread), it is quite likely that some of the
other threads come to the end of its life-cycle soon and the number
falls back to 10. We might do better (i.e. less nervous) based on e.g.
exponentially smoothed queue length/times (or idle threads), but this
requires as well some fiddling around with the parameters.
>
> As for the pool subcommands, do the existing subcommands handle any
> new data points that may be available? For example, if there were
> nested pools you would want parents and children, or if they were
> dynamic you would want to know when they were created. Or more
> concretely, can they provide info on how many connections in the pool
> are being handled with background delivery?
we have now all "statistics" values on the server level, so there is
still something to do. we should as well push the locking to the pool
level, some of the locks are still for the full nsd (these locks are
relatively infrequent and sort-timed, this is not urgent).
-gustaf
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
