Skip to content
GitLab
  1. 22 Jul, 2017 1 commit
  3. 21 Jul, 2017 1 commit
  5. 20 Jul, 2017 1 commit
  7. 19 Jul, 2017 1 commit
  9. 18 Jul, 2017 5 commits
  11. 16 Jul, 2017 13 commits
  13. 14 Jul, 2017 4 commits
  15. 13 Jul, 2017 2 commits
  17. 12 Jul, 2017 8 commits
  19. 11 Jul, 2017 4 commits
    • Evgeny Kotkov's avatar
      mpm_winnt: Advertise support for preshutdown notifications in the service, · 70c97d70
      Evgeny Kotkov authored 
      and perform shutdown in respond to SERVICE_CONTROL_PRESHUTDOWN.

The pure shutdown notification leaves a small amount of time for the service
to finish (and the allowed amount of time has been shrinking with every new
version of Windows), and handling only it increases the chance of the process
being killed by SCM, instead of gracefully shutting down.  Handling the
preshutdown control code extends this period, and increases the chances of
finishing everything properly when the machine is rebooted or shut down.

(See https://msdn.microsoft.com/en-us/library/windows/desktop/ms683241)

Please note that although the preshutdown notifications are available only
starting from Windows Vista, the code is compatible with the previous versions
of Windows, since the SCM ignores unknown SERVICE_ACCEPT codes, and will
still send an ordinary SERVICE_CONTROL_SHUTDOWN under old Windows
versions.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1801659 13f79535-47bb-0310-9956-ffa450edef68
      70c97d70
    • Evgeny Kotkov's avatar
      mpm_winnt: Remove unused values of the io_state_e enum. · 7fd5b58c
      Evgeny Kotkov authored 
      Submitted By: Ivan Zhakov <ivan {at} visualsvn.com>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1801657 13f79535-47bb-0310-9956-ffa450edef68
      7fd5b58c
    • Evgeny Kotkov's avatar
      mpm_winnt: Remove a duplicated comment in the child_main() function. · d2c26c3b
      Evgeny Kotkov authored 
      
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1801656 13f79535-47bb-0310-9956-ffa450edef68
      d2c26c3b
    • Evgeny Kotkov's avatar
      mpm_winnt: Use a LIFO stack instead of a FIFO queue to hold unused · 9db53e77
      Evgeny Kotkov authored 
      completion contexts, as that may significantly reduce the memory usage.

This simple change can have a noticeable impact on the amount of memory
consumed by the child process in various cases.  Every completion context
in the queue has an associated allocator, and every allocator has it's
ap_max_mem_free memory limit which is not given back to the operating
system.  Once the queue grows, it cannot shrink back, and every allocator
in each of the queued completion contexts keeps up to its max_free amount
of memory.  The queue can only grow when a server has to serve multiple
concurrent connections at once.

With that in mind, consider a case with a server that doesn't encounter many
concurrent connections most of the time, but has occasional spikes when
it has to serve multiple concurrent connections.  During such spikes, the
size of the completion context queue grows.

The actual difference between using LIFO and FIFO orders shows up after
such spikes, when the server is back to light load and doesn't see a lot
of concurrency.  With FIFO order, every completion context in the queue
will be used in a round-robin manner, thus using *every* available allocator
one by one and ultimately claiming up to (N * ap_max_mem_free memory) from
the OS.  With LIFO order, only the completion contexts that are close to
the top of the stack will be used and reused for subsequent connections.
Hence, only a small part of the allocators will be used, and this can
prevent all other allocators from unnecessarily acquiring memory from
the OS (and keeping it), and this reduces the overall memory footprint.

Please note that this change doesn't affect the worst case behavior, as
it's still (N * ap_max_mem_free memory), but tends to behave better in
practice, for the reasons described above.

Another thing worth considering is the new behavior when the OS decides
to swap out pages of the child process, for example, in a close-to-OOM
condition.  Handling every new connection after the swap requires the OS
to load the memory pages for the allocator from the completion context that
is used for this connection.  With FIFO order, the completion contexts are
used one by one, and this would cause page loads for every new connection.
With LIFO order, there will be almost no swapping, since the same completion
context is going to be reused for subsequent new connections.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1801655 13f79535-47bb-0310-9956-ffa450edef68
      9db53e77