|Summary:||[PATCH] Implementation of Asynchronous processing support in MPM-WINNT and CORE that doesn't block worker threads|
|Product:||Apache httpd-2||Reporter:||Thangaraj AntonyCrouse <thangaraj>|
|Component:||mpm_winnt||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|OS:||Windows Server 2003|
|Bug Depends on:|
|Attachments:||Patch to provide Async processing support in Apache Core, MPM Winnt and mod_isapi modules|
Description Thangaraj AntonyCrouse 2011-04-04 14:23:25 UTC
Created attachment 26853 [details] Patch to provide Async processing support in Apache Core, MPM Winnt and mod_isapi modules Implementation of Asynchronous processing support in MPM-WINNT and CORE that doesn't block worker threads (true async file transfers in Core and ISAPI HSE_PENDING_STATUS support) Problem: Apache Http Server by design does not support asynchronous processing model as IIS, i.e., HTTP requests that take longer duration such as large file downloads and Content generators such as mod_Isapi doing HSE_STATUS_PENDING operations will block worker threads until operations are completed. The provided fix is to make Apache web server mpm_WinNT core utilize Windows API (TransmitFile, IO Completion port) to relinquish worker threads efficiently and thereby increasing the servers scalability significantly. Reproduction steps: 1. Host Apache such that you can download large files greater than 10MB over http. 2. Download more than 20 files simultaneously, you can see that worker threads used for download operations switch between Kernel and User mode frequently and thereby consuming more CPU resources unnecessarily for long duration. Solution: Enhanced Apache (core, mpm_winnt) request processing pipeline such that HTTP requests are either processed in asynchronous fashion (if possible) or in default/synchronous mode. This includes an additiont to APR 1.4.2 network API. Testing Done: Tested this enhancement and found Apache to be stable/robust (less memory and CPU usage). Test enviornment: Windows 2003 or 2008 Module configuration: mpm_winnt, mod_isapi.so, mod_ssl.so, mod_fcgid.so, mod_dir.so, mod_authz_host.so, mod_env.so, mod_expires.so, mod_headers.so, mod_log_config.so, and mod_mime.so. ThreadsPerChild: 30 or more Test case 1: Download more than 30 files of more than 10MB in size, and check whether worker threads are able to handle more than 30 requests in parallel. Test case 2: Use Isapi extension that utilizes HSE_STATUS_PENDING server support function, and check whether threads are not getting blocked. Enhancement details: Apache core HTTP pipeline is enhanced as follows: 1)Dispatch stage: HTTP connection listening thread accepts and dispatches incoming HTTP requests to Apache worker threads, this stage is enhanced to dispatch asynchronous operation completion notifications (refer below) as well. 2)Execution stage: Worker threads processes incoming requests as follows. a. If incoming requests are deemed to take longer duration, such requests are executed in asynchronous fashion, i.e., i. File download requests: Apache core is enhanced to probe into HTTP request and identify whether the URI requested involves large data transfer or not (magnitude configurable via httpd.conf, currently set as >=10MB). If magnitude is large enough, asynchronous contexts are setup, file transfer operation is delegated to Windows kernel and worker thread is relinquished back to Apache. When transfer operation is done, completion notification is signaled from kernel to Apache dispatch stage. ii. Long operations: Apache mod_isapi module is enhanced to relinquish worker thread if ISAPI extensions hint about extended operation (HSE_STATUS_PENDING). ISAPI extensions later notify mod_isapi once the extended asynchronous operation is done (HSE_REQ_DONE_WITH_SESSION), and mod_isapi module signals completion notification such that Apache dispatch stage gets notified. c. If incoming requests cannot be possibly (no hints available) or optimally executed in asynchronous mode, such requests are immediately executed by worker threads in blocking fashion. d. If incoming request is an asynchronous completion notification, worker thread cleans up resources used for asynchronous processing in blocking fashion. -- Author: L.Thangaraj AntonyCrouse
Comment 1 Johannes Roith 2011-05-09 10:35:57 UTC
Are there any plans to merge this patch into the official 2.2. branch? Could it be modified to support chunked encoding? This would make it possible to write a module to connect to some pubsub backend (e.g. Redis or RabbitMQ) and incrementally push messages data to clients (certainly mozilla) via a single long-running XmlHttpRequest.
Comment 2 William A. Rowe Jr. 2011-05-09 16:45:03 UTC
There is no chance of intra-request Async behavior being backported to 2.2 or 2.4. This is due to module author expectations by the httpd API contract. Inter-request (async behavior between requests; connect, keep-alive, linger close) can be backported, but is more likely to live in httpd 2.4. I'll spend some time reviewing this patch this coming weekend.
Comment 3 neo 2013-03-11 09:22:03 UTC
is this patch useful to httpd 2.4?
Comment 4 neo 2013-03-11 09:22:19 UTC
is this patch useful to httpd 2.4?
Comment 5 Thangaraj AntonyCrouse 2014-10-14 16:11:41 UTC
>>is this patch useful to httpd 2.4? Yes, this patch is useful for httpd 2.4 to enable intra-request Async and true Async file download capabilities.
Comment 6 William A. Rowe Jr. 2018-11-07 21:09:45 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.