RE: A bug with httpd-2.4.2 Win-x64
The problem reported below was only with the binaries of the Debug configuration, but disappeared in the Release configuration. So here is my temporay way out: /* line no. 680: */ #ifndef _DEBUG free(ap_module_short_names[m-module_index]); #endif Regards, Bing Guenter Knauf [mailto:fua...@apache.org] wrote on 2012年4月16日 21:06 Hi Bing, you did hit the apr list - I think this should go to the httpd list instead ... ;-) Am 16.04.2012 14:32, schrieb Bing Swen: After building the httpd-2.4.2 x64 binaries with VS2010, I encountered a runtime error in the module libhttpd.dll, which alerts that a heap corruption occurred at somewhere: file D:\_bsDev\KSE\httpd-2.4.2\server\config.c line 680: free(ap_module_short_names[m-module_index]); The free() call always led to heap corruption like this: HeapFree(_crtheap, 0, pBlock); // access error with pBlock == NULL. My temp solution is commenting off this single line to get httpd.exe run. Please verify if it is a bug.
Re: A bug with httpd-2.4.2 Win-x64
Hi Stefan, I tried many possible ways, and only found this clue for now: /* main.c, line 707 */ apr_pool_clear(pconf); == unload_module(void *data) == ap_remove_module(module *m) == free(ap_module_short_names[i] ) == HeapFree(_crtheap, 0, pBlock); /* bad pointer: pBlock */ It always happens with the Debug config of the VS2010 x64 platform setting, not with the Release version, or both of the VS2008(VS9) x64 builds. BTW, I converted the project files in this way: Apache.dsw + *.dsp == Apache(VS9).sln + *.vcproj == Apache(VS10).sln + *.vcXproj Regards, Bing Stefan Fritsch [mailto:s...@sfritsch.de] wrote on 2012年4月18日 3:29 On Tue, 17 Apr 2012, Bing Swen wrote: The problem reported below was only with the binaries of the Debug configuration, but disappeared in the Release configuration. So here is my temporay way out: /* line no. 680: */ #ifndef _DEBUG free(ap_module_short_names[m-module_index]); #endif I can't see anything wrong with that code. I fear the heap corruption happens at some other place and it is coincidence that it is detected here. Are there any additional heap consistency checks that you can switch on?
Re: Document on developing modules for 2.4 and onwards
Hi Daniel, The draft is already a great document and very useful for Httpd application developers. And I think it could be more helpful if it provides some guidelines for updating modules from 2.2.x to 2.4.x, or some way to use the new 2.4 features. Regards, Bing -邮件原件- 发件人: Daniel Gruno [mailto:rum...@cord.dk] 发送时间: 2012年4月11日 17:13 收件人: modules-...@httpd.apache.org; dev@httpd.apache.org 主题: Fwd: Document on developing modules for 2.4 and onwards As per Igor's advice, I'm forwarding this message to the dev@ and modules-dev@ lists as well: Hello all httpd document lovers, As per our nifty little STATUS document, it came to my attention that we were missing an introductory segment on how to develop simple modules for httpd 2.4, so I took the liberty of drawing up a proposal for what we could put in place for this request. The draft is located at http://httpd.apache.org/docs/trunk/developer/modguide.html and I would much appreciate it if you guys could give me some feedback on whether this will fit in as an, at least for the time being, appropriate document to describe how to develop modules for the server. I plan to expand on the subject, probably add another 10 pages or so, during the summer, as well as letting it into the 2.4 fold, provided I get positive feedback from this mailing list. So, please do read the document and tell me what you think :) Any suggestions, critique etc you might have will be warmly accepted. With regards, Daniel.
RE: Windows testers, AcceptFilter troubles solved?
William A. Rowe Jr. [mailto:wr...@rowe-clan.net]， 2012年3月17日 9:32 Ok folks, here's what we know; on some platforms the blocking behavior is not being honored and SSL is terminated due to the client's failure to provide enough bytes in time. In fact it is the fault of apr plus the socket stack for not returning without more bytes. That said, I neglected the fact that the following functions replace the passed variable with the old value, un-zeroing the value of zero! Please give this patch a whirl and let us know what you all see on various windows boxes with AcceptFilter data|connect|none against the ssl listener; Just wondering how we can test it if we can not yet (re)build the Win32/64 binaries from the source files... Cheers, Bing
RE: Windows testers, AcceptFilter troubles solved?
William A. Rowe Jr. [mailto:wr...@rowe-clan.net] wrote on 2012年3月17日 16:15 On 3/17/2012 2:54 AM, Bing Swen wrote: Just wondering how we can test it if we can not yet (re)build the Win32/64 binaries from the source files... How are you not suceeding? The delta from 2.2 is rather nominal. Please be specific, is it the missing oldschool .mak files, or some conversion to vcproj/sln files? I would like to help but I need to know where you are starting from in this over-broad universe of MS compilation choices. Sorry for not being more specific. I meant to how to patch and rebuild 2.4.1. And yes, the 2.2.22 build is just simple and working greatly so far. Bing
RE: Announcement 2.4.1
Steffen [mailto:i...@apachelounge.com] wrote on 2012年3月8日 20:29 In the httpd 2.4.1 announcement: .There is not yet a Windows binary distribution of httpd 2.4, but this is expected to be remedied soon as various dependencies graduate from beta to GA. Users reading this as that 2.4.1 is not working at all on Windows, and holding even to try it. btw, I am not aware of current versions of the dependencies that have issues: apr-1.4.6-P1 apr-util-1.4.1 apr-iconv-1.2.1 pcre-8.21 lua-5.1 libxml2-2.7.8 openssl-1.0.0g zlib-1.2.6. In fact, it works like a charm. I do have the same question (about how soon) There will ben Windows source files for us to test. Cheers, bing
答复: Windows builds available
How did you make these builds, particularly those Windows 64 bits Binaries? Can we share the directives, or can your method be integrated into the official release? Bing 发件人: Steffen [mailto:i...@apachelounge.com] 发送时间: 2012年2月29日 21:13 收件人: dev@httpd.apache.org 主题: Re: Windows builds available Yep and reported directly to me which are primarily companies using/testing the builds. On Wednesday 29/02/2012 at 14:06, Issac Goldstand wrote: On 29/02/2012 14:10, Steffen wrote: No serious 2.4 bug reports received till now, which you do not already know. All runs fine. Cool. You refer to reports from users on your forums, I assume? Issac
RE: Apache 2.4.1 Throughput compared with nginx
Some Nginx people just made a performance test with Apache 2.4.1 at http://blog.zhuzhaoyuan.com/category/c10k/ Were the Event_MPM configuration parameters somewhere close to optimal? Regards, Bing Jim Jagielski [mailto:j...@jagunet.com] wrote on 2012年2月24日 20:57 w00t!!! On Feb 23, 2012, at 5:26 PM, MATSUMOTO Ryosuke wrote: Hi all, I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1, 2.2.3) with nginx. I used httperf benchmark 0.9.0 to measure thethroughput. http://blog.matsumoto-r.jp/?p=1812 I feel bad about writing this article in Japanese in my hurry ;) Regards, -- MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/
Re: Apache 2.4.1 Throughput compared with nginx
First time to catch up with a high performance edge web server with the lowest memory footprint ?? Maybe such performance race is good for both sides... Regards, bswen -邮件原件- 发件人: Jim Jagielski [mailto:j...@jagunet.com] 发送时间: 2012年2月24日 20:57 收件人: dev@httpd.apache.org 主题: Re: Apache 2.4.1 Throughput compared with nginx w00t!!! On Feb 23, 2012, at 5:26 PM, MATSUMOTO Ryosuke wrote: Hi all, I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1, 2.2.3) with nginx. I used httperf benchmark 0.9.0 to measure thethroughput. http://blog.matsumoto-r.jp/?p=1812 I feel bad about writing this article in Japanese in my hurry ;) Regards, -- MATSUMOTO Ryosuke matsu1229 at gmail.com http://blog.matsumoto-r.jp/
Minor errors in Windows x64 build // Apache HTTP Server 2.2.22 Released
Hi, Bill, There seems to be some minor script problems to build a Win-x64 version of httpd 2.2.22. Here is a brief report for your confirmation. File httpd-2.2.22/srclib/apr-iconv/build/modules.mk.win: line 170: $(API_SOURCE)\x64\Debug\libapriconv-1.lib ... line 173: CFG_OUTPUT = x64\Debug\iconv File httpd-2.2.22/Makefile.win: line 494 - 501: copy srclib\apr-iconv\x64\$(LONG)\libapriconv-1.$(src_dll) $(inst_dll) .y ... copy srclib\apr-util\ldap\x64\$(LONG)\apr_ldap-1.$(src_dll) $(inst_dll) .y ... copy srclib\apr-util\dbd\x64\$(LONG)\apr_dbd_%d-1.$(src_dll) $(inst_dll) .y \ ... copy srclib\apr-util\dbm\x64\$(LONG)\apr_dbm_%d-1.$(src_dll) $(inst_dll) .y \ line 748: BUILD_MODE=x64 Debug line 787 - 798: $(LONG) == x64\$(LONG) Namely, we need to manually add a x64\ substring in the source paths. It seems better to change all the occurences $(LONG) to x64\$(LONG) to copy the correct x64 binary files, if all the other modules are also consistently output to their x64\Debug\ subdirectories. Regards, Bing -邮件原件- 发件人: William A. Rowe Jr. [mailto:wr...@apache.org] 发送时间: 2012年2月1日 6:35 收件人: annou...@apache.org 主题: Apache HTTP Server 2.2.22 Released Apache HTTP Server 2.2.22 Released The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.2.22 of the Apache HTTP Server (Apache). This version of Apache is principally a security and bug fix release, including the following significant security fixes: ...
答复: About Apache
Hi, 馬目, It seems you are interested in the work organization and significance of the Apache server developers for conducting some study? I took a look at your website at Tsuda College in Japan (information science institue), and found that you are using the Apache HTTP server (version 2.2.3 with CentOS). Maybe your website administrator knows the answers for most of these question... Regards, bing PKU, Beijing -邮件原件- 发件人: 馬目彩 [mailto:pks@i.softbank.jp] 发送时间: 2011年12月27日 16:08 收件人: dev@httpd.apache.org 主题: About Apache Please tell me about Apache. I have a few question. 1. What is apache software to do? 2. What is the significance of global collaboration to this project? 3. What they do? 4. Why they do it? 5. How they collaborate with others? -- 馬目 彩 津田塾大学学芸学部情報科学科
答复: Win64 2.3.16 :: build warnings
All of those warnings were int conversions, should be easy to fix. bswen 发件人: Steffen [mailto:i...@apachelounge.com] 发送时间: 2011年12月18日 3:30 收件人: dev@httpd.apache.org 主题: Win64 2.3.16 :: build warnings Here the Win64 warnings attached. Quite a lot, 442. Btw. Windows 64 builds and runs fine with 2.3.16. Still with a low memory print. Steffen
Re: 2.3.15 on Windows
Great news. Genuine progress actually, especially in terms of memory usage and grow rate. Bing -邮件原件- 发件人: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] 发送时间: 2011年11月21日 13:01 收件人: dev@httpd.apache.org 主题: Re: 2.3.15 on Windows On 11/20/2011 2:11 PM, Steffen wrote: No issues so far, all looks fine till now, see/feel no difference over 2.2, only memory usage is quite better, ~70% less here so far and is growing not that much over time. Speed is on par with 2.2. Sound like progress, which is all we ask for version revs :)
RE: Pushing for httpd 2.4.0 GA
Steffen [mailto:i...@apachelounge.com] wrote on 发送时间: 2011年9月16日 3:46 ... Acept filter issue means in common that 2.4.0 cannot be used on Windows. Or would it better that 2.4.x only excludes Windows XP (32-bit) support, but Windows Vista and the later can be well supported? Also, official support of the Windows x64 versions of httpd-2.4.x is very important. Regards, Bing - Original Message - From: Stefan Fritsch s...@sfritsch.de To: dev@httpd.apache.org Sent: Thursday, September 15, 2011 9:09 PM Subject: Re: Pushing for httpd 2.4.0 GA On Thursday 15 September 2011, Jeff Trawick wrote: I plan on push for a GA in Oct (of this year)… The only 2 showstoppers I see as reasonable are the documentation ones and the mod_fcgid one. I plan on adding doccos for the ones that are currently lacking, but the question is what to do about mod_fcgid… What's the best way to accomplish folding mod_fcgid into 2.4? Should we copy trunk of mod_fcgid and put it into trunk of 2.4? Use some svn mojo? etc…? I think the windows accept filter issue is a real blocker. The only alternative would be to release 2.4.0 without official support for Windows. The bundling of fcgid shouldn't be a blocker IMO. Much to my disappointment I haven't had time to work on it lately, and I see that no one else has either. +1, mod_fcgid can be added in 2.4.1+
RE: Query
Sorry that I have little idea of log4cxx, so I can not help you for that topic. Bing -Original Message- From: Govinda Raju Narayan [mailto:gnara...@unidesk.com] Sent: Monday, March 16, 2009 8:41 PM To: Bing Swen Subject: RE: Query Appreciated, for quick response, Is there anyway I can use log4cxx at kernel level? Thanks Raju -Original Message- From: Bing Swen [mailto:bs...@pku.edu.cn] Sent: 16 March 2009 4:02 PM To: Govinda Raju Narayan Subject: RE: Query Govinda Raju Narayan [gnara...@unidesk.com] wrote on Monday, March 16, 2009 2:09 PM Is APR available at kernel level?, I mean Is I can use APR at driver code on both windows and Linux?. The reason is I'm looking for feasibility of using log4cxx at driver level. I think not. APR needs CRT (C Runtime) library, but no OS provides a CRT at its kernel. Bing
Re: [WIN32] Using WSAPool for Vista+
Mladen Turk mt...@apache.org wrote on 2009-2-9 17:25 Hi, Vista (Server 2008) and up comes with new winsock WSAPoll API. Now I did some experiments and it compiles the unix/pool.c by simply changing poll( ... ) to WSAPoll(...) There is also no limitation on pollset size (currently select is limited to FD_SETSIZE 1024, cause it's too slow for higher numbers). Well, the testpoll.c passes with 16K sockets. Httpd works like a charm with 10K connections. Now the problem is that to be able to use it, we would need a pollset implementation provider that will dynamically switch back to select in case winsock doesn't defines WSAPoll. That makes me think we can have that generic, allowing different pollset providers for non-windows platforms as well (If it makes sense of course), eg. something like we have for proc_mutex. (apr_proc_mutex_unix_lock_methods_t would actually become apr_poll_methods_t allowing choosing different poll providers, again where it makes sense) As I've learned , WSAPoll was designed to behave just like the Unix poll(), but it seems to have got counterpart performance of Linux epoll. Some Windows port of Nginx has used WSAPoll to simulate its ngx_poll_module.c on Windows 6.x (Vista and 2008), and seems to achieve the same performance improvement. Though like poll(), this is just a single-threading I/O model, and thus it should be less efficient than the IOCP (completion port) API. It's not uncommon for a single online game or IM server that uses IOCP to handle 100K+ (slow long-duration) connections with quite a few (4~8) threads. But there seems no reason not to use WSAPoll to implement apr_pollset_t (when _WIN32_WINNT = 0x0600), at least for such performance gain. That could also benefit httpd a lot, e.g., the worker MPM of httpd using apr_pollset_t will be easily ported to Windows 6+, and possibly has the same (or much better?) network I/O performance than the current Windows MPM version winnt_mpm, which currently uses a suboptimal ICOP scheme. Bing School of EECS Peking University
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote .dsw+.dsp lets us provide everyone with a makefiles and Makefile.win that works ***everywhere***. If you insist on a GUI, there is one extra step for Visual Studio 2002 (.NET) - Visual Studio 2008 users. But would you like that we provide you a Visual Studio 2008 project that VS 2005 users can't even load - due to the fact that the MS VS team insists on breaking the project description layout on every successive release? As I said before, it's a non-trivial problem, and if you want to vent please be our guest, and vent at the source of the problem, not we. I think most of us already have an idea of the source of the problem, and so please don't treat it as just complaining. One of the good things of open source is that it gives people patience and an open mind. As someone pointed early, it's probably time to move forward. If we continue to seriously think Win32/64 as an important platform for Apache (which was part of the reasons that shaped httpd 2.0), the time to say goodbye to those old Microsoft C 1995/98 .dsp stuff seems to have come. Here we probably shouldn't say much on MS's self compatibility policies. The reality is not that ideal; Even VS 2008 project files need to co-exist with VS 2005 and prior (though upgrading is usually much better). So I wonder if there is a possibility to propose a vote (or any other method) in the near future to see how many people still intend to use VS 5/6 (or perhaps Win9x) to run their Apache servers, and whether most of us would like to get rid of those dinosaurs and move forward. (As made clear sometime earlier, Windows 2008 R2 will only have 64-bit versions. The clock is ticking;-) Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Bing
Revise VC6 .dsp files -- was: [VOTE] Release Apache HTTP server 2.2.11
Jorge Schrauwen wrote on 2008年12月18日 20:10 On Thu, Dec 18, 2008 at 10:14 AM, Bing Swen bs...@pku.edu.cn wrote: Jorge Schrauwen jorge.schrau...@gmail.com wrote on 2008年12月17日, 19:07 For the early httpd-2.2.x series it has compiled on Win64. Then again it's very picky in which platform you use. Win XP x64 + VS2005/8 works best. Vista x64 is has some problems with platform SDK (not sure they are fix now). How long will they be compilable? I don't know. I think it has more to do with the makefile(s) than with the code it self. There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? Looks like you haven't run cvtdsp.pl to convert the vc6 dsp's to once that upgrade. There is a more detailed explenation here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 ~Jorge I already read your nice tutorial there, and many thanks. But I just meant whether it is possible to just revise the makefiles (VC6 .dsp files) in the official httpd Win32 release package to make the updated Win64 project files directly compilable? Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote Bing Swen wrote: There seems to be a bug in the project updating functions of VS2005/08: embedded \ char's in the .rc files always made a fatal error to the resource compiler (rc.exe), e.g., ... LONG_NAME=Apache HTTP Server ... If all the inner \ are replaced with \' (namely, quot; to apos;), then the updated project files (.vcproj) will be OK to compile. Was this part of the problems with the makefile(s)? It's a bug in Visual Studio (already reported when we were meeting with the a couple Visual Studio development folks in Redmond)... the fix is pretty weird... srclib\apr\build\cvtdsp -2005 Now the resulting .dsp files can never be opened again in studio 5/6, but the quotes are shifted around for purposes of importing. So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)? Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote: bing swen wrote: So is it a good idea to maintain two sets of project files to cope with this problem: one for the old VS 5/6 .dsp files (no more x64 support), and one for VS 2005/08 .vcproj files (with direct x64 support)? No, it's a horrid idea. Sorry for this. Since 2+ years have passed (since httpd-2.2.2, the last Win-x64 compilable version), I thought of some progress even at the cost of such complexity. It's a good idea to drop to one cross-platform reference file as apr has (config.layout), and spit out whatever the heck the user wants (visual studio .dsw, .sln, eclipse, codewarrior etc etc.) One more idea: would it sound good (not that complex) to put all the makefiles and build project files, and intermediate .obj files as well, into a separated top directory to maintain the purity of the source code? e.g., httpd-2.2.x /.../* official release files */ /build /netware /linux /windows /win32/Debug/*.obj /... /x64/Release/*.* /... All the build directive files use relative paths to the source files, and we give each platform a separate subdir under /build. Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
Jim Jagielski j...@jagunet.com wrote on 2008-12-14 23:24 On Dec 13, 2008, at 9:32 AM, Ruediger Pluem wrote: 2. A number of non binding positive votes and positive feedback. 3. Binding votes: 0 -1 0 +0 8 +1 (Colm, Sander Temme, Brad, Jim, Bill, Lars, Jeff, Ruediger) So the vote has passed. I will copy the release files to the dist directory now and give the mirrors about 24 hours to catch up. I plan to announce the release officially by tomorrow evening CET. Don't forget to update the various site files, announcements, etc... as of this morning, 'http://httpd.apache.org/' and 'http://httpd.apache.org/download.cgi' still refer to 2.2.10 with smatterings of 2.2.11 around It may seem to be an out of fashion question, but I hope anyone can give a clear answer: How long will we have a compilable Windows x64 httpd-x.y.z release? Infinitely long? ;-) Bing
Re: httpd win64 binaries
Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-11-3 16:26 On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? Though we are eager to see an 'official' 64-bit Windows httpd release, but if not binaries, why shouldn't there be an x64 configured Apache.sln? It will be already great to let people have the chance to do their own x64 compilation. It was made clear that 32-bit will soon be over at the Windows server end (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx). I guess most of us still think that Windows Server remains as an important platform for Apache. So it's really time to make this little step further. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? Jorge's Win64 binaries already seem to work perfectly on mainstream Windows versions. Shouldn't it be able to improve to be offical? (I just found it can not load some modules built with VS005/Win008, though). Bing
Re: httpd win64 project sources/makefiles [was:...binaries]
Dan Poirier [EMAIL PROTECTED] wrote on 2008-11-3 21:13 William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. Re: windows, aren't there one or more ports of gcc? Would something like that be worth considering as a more stable build solution than MS's tools? There is a runtime library issue. Most GCC ports do not generate object code that can be linked with the necessary WinAPI runtime lib's. e.g, httpd needs to link to lots of MS C startup libraris to use the file system, socket API, IOCP, etc. Bing
Re: httpd win64 project sources/makefiles [was:...binaries]
Marc Noirot [EMAIL PROTECTED] wrote on 2008-11-3 22:06 William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake, which is able to target the following environments on Windows : # Borland Makefiles # MSYS Makefiles # MinGW Makefiles # NMake Makefiles # Unix Makefiles # Visual Studio 6 # Visual Studio 7 # Visual Studio 7 .NET 2003 # Visual Studio 8 2005 # Visual Studio 8 2005 Win64 # Visual Studio 9 2008 # Visual Studio 9 2008 Win64 # Watcom WMake # CodeBlocks - MinGW Makefiles # CodeBlocks - Unix Makefiles # Eclipse CDT4 - MinGW Makefiles # Eclipse CDT4 - NMake Makefiles # Eclipse CDT4 - Unix Makefiles -- Marc Noirot This seems overwhelming. So it seems possible for httpd to have a one-to-fit-all IDE project file generator? Then everyone will have a happy ending... Bing
Re: Simple MPM is in trunk
Jorge Schrauwen wrote on 2008-10-30 17:03 On Thu, Oct 30, 2008 at 5:37 AM, Bing Swen [EMAIL PROTECTED] wrote: Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; I have to admit it isn't easy to do so. But it certainly is possible! Due to lack of time on my part I've not updated the httpd wiki but you can find how to do it here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 First few times are the hardest but once you setup a nice build environment its all good. Vista + vs 2005/2008 is generally bad. XP x64 + 2005 currently works the best, although 2008 works too. If you can't be bothered with the trouble, there are unofficial binaries on there too if you want to play with it. 2. Many stock modules have no 64-bit configuration. Again it's a matter of recompiling, most windows users are spoiled and thing everything comes in nice binaries. libphp5, mod_macro, mod_jk, mod_security,... can all be recompiled for 64-bit, most are easier to do than httpd itself. Thanks for the nicely presented tutorial. I'll try to follow it and to understand what that 600+ PERL lines have fixed. So we have to get AWK, Bison, Flex and Sed to work, which are not required for a 32-bit build. And, we need a Perl Interpreter to run some magic conversions to get it built. That already made Win-x64 httpd a second-class citizen;) 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Bing
Re: Simple MPM is in trunk
Jorge Schrauwen wrote on 2008-10-30 18:46 biggest problem atm is getting the apr dbd drivers for mysql and such. (never got that to work) Personally I'd love to see the httpd project release 64-bit binaries themselves. But it's a lot of work for not much gain!* * tests with the early 2.2 branch show little to no improvements. The improvement is httpd's virtual memory -- and actually very significant: we need to map a 500+ GB index into the memory space of httpd's child process. 64-bit space is our only choice;) Well a proxy with a mem_cache would definatly benifit from it. apr dbd drivers have become a nightmare for those who tried and failed to build a Win-x64 httpd.exe after httpd-2.2.2. And we must have some source code integration with httpd itself (at least necessary for debugging), so we didn't use your unofficial binaries. It's been a shame (and frustration as well) to say that we are still using httpd-2.2.2 ... Bing
Re: Simple MPM is in trunk
Paul Querna wrote on 2008-10-28 15:12 I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ ... One of the major departures is that it doesn't use any of the functions from os/unixd/, which I believe is a good long term decision, since I would like to get the MPM working on Windows. Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. Bing School of EE CS, Peking University, Beijing 100871 http://icl.pku.edu.cn/
Re: Simple MPM is in trunk
Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; 2. Many stock modules have no 64-bit configuration. 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing
Re: [VOTE] Release Apache HTTP server 2.2.10
William A. Rowe, Jr. [EMAIL PROTECTED] wrote on 2008-10-14 23:06 Tom Donovan wrote: William A. Rowe, Jr. wrote: I noticed a few little things building 2.2.10 with VC9 on Windows: * the windows source .zip is missing most of apr-iconv - only the .mak and .dep files are present. With previous versions we included all the files for iconv (from apr-iconv-1.2.1-win32-src-r2.zip) Bugger - thanks for catching that! As this still lives in /dev/dist/, I've just replaced it with a corrected httpd-2.2.10-win32-src.zip There are another 8 projects that currently cannot be built with x64 configuration on Windows. Here is some error message: - libapriconv_ccs_modules: link to ..\Debug\libapriconv-1.lib error (should to ..\x64\Debug\libapriconv-1.lib - apr_dbd_mysql: mysql.h: No such file or directory - apr_dbd_oracle: oci.h: No such file or directory - apr_dbd_pgsql: libpq-fe.h: No such file or directory - apr_dbd_sqlite2 sqlite.h: No such file or directory - apr_dbd_sqlite3: sqlite3.h: No such file or directory (And, still, we can not yet build x64 httpd.exe ;) Bing
Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
Paul Querna [EMAIL PROTECTED] wrote on 2008-9-21 4:21 Graham Leggett wrote: I know there are likely huge problems with this, but I would like to see how far we can push the Event MPM, figure out what to do better, if there is anything, and then really dive into the 3.0 development before ApacheCon. How difficult would this be to support in the other MPMs? Windows, Worker MPM and the similar threaded MPMs could do it easily. But, IMO, I want to eliminate all of the MPMs for 2.4/3.0. I believe the MPMs as they are designed right now, are both a layer of portability, and a module that defines behavior or the model. ... Basically, one MPM to rule them all, with a configuration directive that can make it act like prefork or the event MPMs. Currently the role that MPMs play is to map a connection (with many requests, by HTTP/1.1) to a worker (a thread or process). But an optimal network i/o model needs a layer that maps a *request* to a thread, so that a worker thread (or process) will not have to be tied up entirely with a single connection during the whole life time of the connection. Instead, a worker can be scheduled to handle different connections, which helps both reducing the number of workers and the performance of request handling (especially on slow connections). Such a layer should unify the upper interface of Event driven i/o, Windows i/o completion port, and many other async i/o mechanisms. With luck and careful design, the current filtered i/o chain and the module API can remain the same. I hope that this would be one of the best features that 2.4+ will bring to us, as finally it will support any optimal i/o model on various platforms, and answer the doubts on Apache performance once and forever. Bing School of EE CS, Peking University, Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote on 2008年8月22日 9:03:
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change.
Another related question: We haven't been able to build httpd on 64-bit
Windows for about two and half years, since the April 2006 release of
httpd-2.2.2 (But x64 build is crucial for our application, and that's why we
are still using that aged version). Shall we have 64-bit Windows release
in the near future, say 2.2.10? (btw, we are really delighted to see that
now APR has a *clean* compile on x64 Windows.)
Bing
School of EE CS,
Peking University,
Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
Jorge Schrauwen wrote on Sunday, September 14, 2008 7:47 PM This is no true. The latest version I've been able to compile was 2.2.9 http://www.blackdot.be/?inc=apache/binaries You are however correct that it's getting more cumbersome! Vista + VS 2005/2008 is a no go. I'm using a XP x64 with VS 2005 in vmware to build it now. Also command line building is busted Using the IDE it's still possible. We have to use Visual Studio 2005 plus Windows Server 2003 R2 x64 (SP2) and Windows 2008. We couldn't build it using the IDE with the version macro _WIN32_WINNT=0x0500 or 0x0600. (However, the APR part can be compiled cleanly.) Bing
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on 2008年9月3日 7:54 Egads, no wonder they got such horrible performance. Worker (or event, maybe) seems to be the best way to go, at least based on our testing. Yes, Worker can work much better, but seems to be basically the same order of magnitute as threads on Windows (still far more less scalable in terms of concurrent connections than Nginx). Maybe you have super-optimized hardware and system? ... We run internal benchmarks often and collect a lot of performance statistics from live traffic (response times, etc.) We also, however, do not run any vendor supplied httpd build, either. RedHat's, for example, is not for production websites, IMO. So I wonder perhaps next time you guys may bother to take time to also run Nginx on your platform and tell us how it performs against your httpd build... Bing Bing Swen (孙斌) School of EE CS, Peking University, Beijing 100871 Tel：86-10-62753081 ext 102 Fax: 86-10-62759444 [EMAIL PROTECTED]
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on Tuesday, September 02, 2008 11:31 PM: sustain about 45k requests/sec on our build on a dual dual-core system with a network card that supports Linux NAPI (that made a huge difference). Without much tuning 35k is pretty easy. (Note: this was very small files, bcs it's so easy to fill the network interfaces). Apache is slow is just FUD, plain and simple... There is a little different viewpoint. According to some recent test reports comparing Apache 2.2 and Nginx 0.6/0.7 (from a blog website admin.), Apache could do as well as Nginx when there are a few connections each of which carries many many requests. The hard time for Apache came when there are many *slow connections*, each of which sends only a few small requests at large durations. In such condition, Apache could hardly respond when the no. of connections reached over 3,000 (even when there is still much free memory). By contrast, responses from Nginx kept full speed even with 10 times more connections. It seems only to slow down when it runs out free memory, but not limited by concurrent connections. (The same is true for Apache on Win.Server '08. But I guess the Linux version might not have Linux NAPI support.) Such slow connection issue happens to be the typical scenario of video, chat or blog authoring websites. No wonder they are willing to put aside their familiar Apache just for cutting off the budget. So it makes sense to concern whether Apache needs improving over this problem. If so, the only question is how;) Bing School of EE CS, Peking University, Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on Wednesday, September 03, 2008 2:07 AM I saw this comparison somewhere. It just does not seem to match what I have seen. Our little ole website has been known to take a few connections from slow clients, but we have not really seen this slow down. I'd like to see more specifics of the test. All of my numbers are from real world stuff. It seems the test (done by another guy) indeed used an everything plus the kitchen sink default Apache httpd at first, but then dropping off 3/4 of all of the default modules (maybe not that much, but only for serving static pages) seemed to have a not big help. The MPM used the default configuration (prefork on Linux and threads on Windows). [not your settings?] (FYI, NAPI is just a way which Linux handles NIC irq's better - a gross simplification, but it makes a huge difference on very busy web servers. I'm sure other OS's have something similar?) Maybe that was a big difference. (The default Linux didn't provide such feature.) But it might have limited help for greatly increasing the connection number. Bing School of EE CS, Peking University, Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote:
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change.
Dose anybody ever think of improving the runtime performance of Apache httpd
to be
somewhere close or at least comparable to that of Nginx? At this time Nginx
is only
a test version, but as far as I know here in China, its efficiency gain is
so tempting that
the 0.6.x and 0.7.x versions have dominated the flash-video websites, most
of which
are top traffic-ranked ones.
Lighttpd is another excellent example that provides far more better runtime
performance.
Although Apache is famous for its modular design and configuration
flexibility, it seems
these new comers are challenging the relevance of Apache in real use. Is
there any
chance for Apache to get much better performance while retaining its design
beauty?
To my knowledge, the one thread per connection network i/o model is a
suboptimal use
of the Windows IOCP (i/o completion port) mechanism. IOCP suggests that only
a very few
threads (no. of CPU cores) would be sufficient to handle tens of thousands
of requests.
Nginx uses an event driven i/o model, with economic memory allocation.
Apache does
have an event driven MPM for some platform (needs further development to
match).
Bing
School of EE CS,
Peking University,
Beijing 100871
