A/UX is an excellent platform for Apache. For optimal performance, it's best to be running A/UX 3.1.1 on a good, fast Mac. Even so, there are some basic performance improvements you can make to allow Apache to really shine.
Note: These patches are in gzipped-tar format... If downloading from the Web doesn't work, you can try FTP to either:
(In other words, you can setup Apache on one machine to respond to both www.bigtime.com and www.lookieme.com with different default homepages for both)
You can use name-based vhosts with no changes at all to A/UX. This isn't the case for ip-based vhosts. A/UX doesn't provide the internal virtual interfaces capability required to get ip-based vhosts to work (some OSs, like Solaris or HP-UX can do this "as is"). Jim Jagielski (jim@jaguNET.com) has written an A/UX kernel module that gives A/UX the virtual interfaces required. The module is added to the kernel using the standard kconfig command and you can add as many virtual interfaces as you need.
To get around this, Jim has also written a short adb script that changes this hard-wired value from 5 to a more-reasonable value of 32 or 64 or 127 (larger values aren't possible yet).
If you don't want to bother with downloading the script, here it is:
#!/bin/ksh # # this patches the BNET module to increase the value of SOMAXCONN # (the maximum number for the backlog queue in listen()) from 5 to 32 # or 64 or 127 # # # Uncomment the size you want # #QUEUE=20 # 32 #QUEUE=40 # 64 QUEUE=7f # 127 adb -w bnet <<! solisten+0x7a?6i solisten+0x7e?x solisten+0x7e?w $QUEUE solisten+0x8a?x solisten+0x8a?w 70$QUEUE solisten+0x7a?6i $q !
% kconfig -n /unix NMBUFS=5000 ^D
The change will take effect the next time A/UX is rebooted.
We're looking into ways around this, but until then, keep this limit in mind.
sbrk: No more processes httpd: Could not move break
Apache uses shared-memory under A/UX but, unfortunately A/UX's implementation of shmget places the shared memory segment very close to the current sbrk(0) point. So what Apache tries to do is move the sbrk point further up in memory before attaching the segment to give Apache loads of memory to use and malloc as needed. The error message means that Apache couldn't move the sbrk point as far desired.
To fix this, simply edit conf.h and change the value of MOVEBREAK in the A/UX section from 0x4000000 (which is 64MB) to something smaller like 0x2000000 (32megs) and recompiling.
Even if you do get the error message, Apache will still run and it's extremely doubtful that you will have any problems at all (if you do, it will show up as Apache reporting that it is unabled to malloc memory).
© 1994-2011copy; 1994-2011, jaguNET Access Services, LLC
webmaster@jaguNET.com