Results 1 to 10 of 10

Thread: Ok, Let's talk aboout Process Pooling

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Feb 2009

    Lightbulb Ok, Let's talk about Process Pooling

    I have been thinking in raising this subject earlier in the past, but after reading this I decided to finally start it..

    Let's start with a few questions to DAW:

    1. When exactly a new process is started in the pool ? Just when all current process are busy, and a new request arrived ? So, the new request needs to wait the process to get fully stated in order to be processed/handled by it ?

    If the answer yes, I guess we need some enhancement on this area. This behavior does not reveals a problem for sample apps like weborder, but for sure it brings issues in real production and sensitive environments, where the response time needs to be low.

    I have been supporting and working with some webapps where the process startup up time takes between 40s to 60s. So, typically a web-request is handles in ms range, at most few seconds.. now suddenly one particular request takes more than 1min to be processed.. because it was waiting the process to get fully started in background.

    We need some kind of threshold parameter, to trigger the start of new process in the pool before-hand, so they can be fully started and ready to do their jobs when the time comes.
    A new parameter based on 'number of idle process' in the pool would be nice ... like, start a new process in the pool every time my pool has only 2 idle process. If such mechanism already exist, this must be exposed in the webapp process polling properties, so we can best tune it.. Larger webapps (the ones that takes longer to load) will require to have this threshold set to a different value. A more intelligent approach can be implemented off-course.

    2. Does the sweep process clears/removes all the overrun (above the min size) idle process from the pool in a single shot?
    I mean, suppose min is set to 5, and we have 10 process in the pool, and at the sweep cycle, it founds out that 4 are idle at that exact moment.
    Will this remove the 4 idle at once ?

    If yes, I would say this is not a smart approach, Removing all idles at once. But instead they should be cleaned/removed gradually. Again a new parameter should be exposed, so we can control the cleanup rate.
    Statistically speaking if the process has increased, there are high chances that they will be required in the next minutes again. So, removing most of the idle process, will just force then to be restarted again in a near future, leading to a unnecessary ramp-up and ramp-down cycle.

    So, we could have actually 2 new settings, one to control the sweep interval, and another to manage how aggressive it should be. Specify the number of idle process per sweep cycle.
    Ex. perform sweep every 30 min, and remove up to 2 idle per cycle !

    3. New KPIs needed. (key-performance indicators) or whatever you want to name them.
    Today we have 5 main metrics related to process pooling.
    Current Sessions ; Peak Sessions ; Current Processes ; Peak Processes and Total Processes

    Which are good, but not enough to best tune them. I would like to have other metrics like:

    • Session Requests Queued Count

    How many times a session request got queued, due lack of available process to handle the request when it arrived.
    This should count the total times every single request had to wait.. not mater the reason ... Even if it has triggered a new process to be loaded in the pool.

    • Total Queued Wait Time (in ms)

    Total time, (accumulated) that sums the time each request had to wait in queued state, before getting assigned to an idle process in the pool.
    Used together with previous metric, one could evaluate the average wait time.

    • Request Queued due Max breach. (need better wording on this, sorry my poor English)

    But, this is a sub-set of 'Session Requests Queued Count', and must count only request queued because the pool has breached the max size already, and no more process could be added to the pool.

    • Queue Length Peak

    Register the peak size for the Queue length. How much request got queued at same time ?

    • Average Response time (in ms, all tree)
    • Max Response time
    • Min Response time

    All 3, are self explanatory.

    • Process Avg Load Time (in ms)

    Informs the load time for each process. So we don't need to measure this externally..

    Other Informational stuff:
    In the "Processes" view option, provide two more metrics:

    • Process PID #: just informational stuff, to help identifying the process ID.
    • Load time : total time the process took to be loaded

    With current existing metrics, we can determine if the max pool size has been reached..
    But only that.. We don't have information like:
    How often my session are being queued ?
    How often I am breaching the max size ?
    And when this happens, how big is my queue length ?

    All these new metrics aim to help answering these questions, so we can better understand the app workload and tune the pool properties accordingly.. Specially if the new settings get implemented..

    What are your thoughts ?

    Last edited by Samuel Pizarro; 10-May-2020 at 07:08 PM.
    Samuel Pizarro

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts