Archive for the ‘Hosting’ Category
Network Monitoring – Automated Reboot System
Bring State of the Art Network Monitoring in house – save money, offer more network monitoring options and stay ahead of your servers.
From SNMP to SMTP, MySQL monitoring and web site up-time, you can bring your network monitoring solution in-house – at an affordable price and with a number of options available.
Monitor the services you need to monitor – use login’s to verify connectivity to your network services. Any network service can be checked at any interval – from every 10 seconds to every 15 minutes – whatever frequency makes you feel the most comfortable. Other network monitoring systems are based on a per unit pricing scheme – using our solution, you can monitor as many devices as you need to monitor – and you can monitor any service that is available over the network.
Automated Reboot Systems
It’s not enough to simply monitor your servers and services – what do you do in case of a server outage, a remote site’s connection down or any of the other services you have to monitor?
Being able to control the power outlets of your servers and and network devices allows the network admin to toggle a machine off and on – resolving over 98% of server service outages.
The PowerKey Pro 600 has 6 software controlled outlets – allowing you to reboot up to 6 devices at any time. Imagine having your webserver stuck at 3 am – rather than driving to the office or data center, login to the network monitoring system from your home or office and toggle the outlet remotely.
With our network monitoring tools and automatic reboot system, you can notify the on-call technician, reboot your server and be notified the services are back on-line faster than you get your pants on and into your car.
Edition.net has been run by Rustan Laine, MCSE, Apple Certified Service Technician for the past 8 years. For more info about our services, contact Rustan at 714 900-3708
Network Monitoring | Automated Reboot System
Bring State of the Art Network Monitoring in house – save money, offer more network monitoring options and stay ahead of your servers.
Monitor the services you need to monitor – use login’s to verify connectivity to your network services. Any network service can be checked at any interval – from every 10 seconds to every 15 minutes – whatever frequency makes you feel the most comfortable. Other network monitoring systems are based on a per unit pricing scheme – using our solution, you can monitor as many devices as you need to monitor – and you can monitor any service that is available over the network.
From SNMP to SMTP, MySQL monitoring and web site up-time, you can bring your network monitoring solution in-house – at an affordable price and with a number of options available.
Automated Reboot Systems
It’s not enough to simply monitor your servers and services – what do you do in case of a server outage, a remote site’s connection down or any of the other services you have to monitor?
Being able to control the power outlets of your servers and and network devices allows the network admin to toggle a machine off and on – resolving over 98% of server service outages.
The PowerKey Pro 600 has 6 software controlled outlets – allowing you to reboot up to 6 devices at any time. Imagine having your webserver stuck at 3 am – rather than driving to the office or data center, login to the network monitoring system from your home or office and toggle the outlet remotely.
With our network monitoring tools and automatic reboot system, you can notify the on-call technician, reboot your server and be notified the services are back on-line faster than you get your pants on and into your car.
For more info, http://www.edition.net/Network-Monitoring-Automated-Reboot-System
mod_ssl on a mac
Web development requires the hardware and software to accommodate a wide variety of client needs and web technologies. Apple has provided web developers with an enormously flexible development environment in Mac OS X. By including Apache, the world’s most widely used web server, along with a host of related technologies (PHP, OpenSSL, SSI, etc) Apple has provided a perfect compliment to popular tools such as BBEdit, Adobe Photoshop, and Macromedia Dreamweaver.
This tutorial will show you how to enable one of the most important technologies included with the standard installation of Apache on Mac OS X, mod_ssl. The mod_ssl module lets Apache use OpenSSL, thereby enabling cryptographically protected connections to web servers via the Secure Sockets Layer (SSL) and Transport Layer Security. Though this is not a comprehensive tutorial on system security, if you enable mod_ssl you will add a layer of security to a Mac OS X machine’s Web Sharing feature.
For more on security in Mac OS X, see An Introduction to Mac OS X Security.
Why SSL?
Adding Apache support for mod_ssl is a great development step. You will be able to test scripts and applications in the most realistic environment possible prior to deployment to a staging or production server. This will help cut development time. It also permits access to your computer that is encrypted. Web applications served off of your Macintosh will be accessible in a secure way. So passwords passed to your machine via web-based forms will be hidden from packet sniffers. Data transmitted to a browser will also be encrypted during transit. Read the rest of this entry »
Installing WordPress on Tiger
Of the many options out there, many people choose to run their own blogging software as opposed to a managed service like Blogger or TypePad. On the software side, there are many decent tools available, such as Six Apart’s Movable Type (we have a tutorial for installing MT as well). WordPress is another mature, capable and free blogging engine that is very popular with many bloggers (like its founding developer, Matt Mullenweg) and rapidly gaining in popularity across the Web. WordPress is an excellent choice for a personal or professional blog, and the price is right, too. This tutorial will show you how to install WordPress 1.5.1.3 on OS X 10.4 Tiger. Read the rest of this entry »
Mac OS X Panther Server and SSL
by Joel Rennich, mactroll@afp548.com
The purpose of this article is to give you an idea of what you can do with SSL in Mac OS X Server and how you can use that to secure as many services as possible. So, first we’ll talk some about SSL in general and how to create the certificates, then we’ll discuss what to do with those certificates. Read the rest of this entry »
Setting up an OS X development server
Okay, so this was very much a case of fumbling around in the dark until stuff worked, lot’s of Googling and breaking stuff. The end result is a dev server on OS X that is running Textpattern with clean URLs and a copy of WordPress for good measure. These notes are primarily so I don’t forget how I did it, if they are useful to someone else, great! Be warned, though, I have no idea how secure this set up is and what flaws it has, so you follow these instructions at your own risk! Also, I am using OS 10.3.9 so I don’t know if this would work on Tiger. Read the rest of this entry »
Web Services With WebObjects
Apple’s WebObjects is a comprehensive suite of tools and frameworks for quickly developing Java server applications. The release of WebObjects 5.2 allows developers to add standards-based web services to these applications, as well.
WebObjects gives you the ability to build or use web services without writing low-level SOAP, XML or WSDL documents. The WebObjects tools enable code-free generation, configuration and testing of web services from existing data assets. Because these web services can interoperate with clients written in many languages, including Java, AppleScript, and Perl, you can quickly create integrated solutions that would otherwise require a lot of coding.
This article shows you how to take an existing database and publish assets as web services, including a service description, all without writing any code.
Installation
If you don’t own your own copy of WebObjects 5.2, it is
available in a free trial version for Mac OS X version 10.2
or later at Apple
Developer Connection. Directions on how to find the
download are on the
href=”http://www.apple.com/webobjects/getting_started.html”>
WebObjects – Getting Started page. We will be working
with Mac OS X 10.3 and Xcode so you will also need the Xcode
Tools for Mac OS X, available for download at the Apple
Developer Connection web site, in the Developer Tools
section. After you download everything, install the
WebObjects_X_Developer package in the Developer
folder and restart your system. You must upgrade to
WebObjects 5.2.2 via Software Update or you can get the
manual update at the page
href=”http://docs.info.apple.com/article.html?artnum=107649″
>About the WebObjects 5.2.2 Update.
If you don’t want to build the project by hand and just want to run it, you can download the example used in this article.
The Data Model
Installing WebObjects installs a sample database in addition to the WebObjects tools. Navigate to /Library/Frameworks/JavaRealEstate.framework/Resources/ and open the RealEstate.eomodeld file. This launches EOModeler and opens the model file of a ficticious real estate database of houses in Silicon Valley. EOModeler is used to reverse-engineer databases, automatically finding all tables, columns and relationships. At runtime the WebObjects persistence engine automatically maps and generates Java objects from JDBC databases. You don’t need to write any SQL code.
The image below shows the tables found in the real estate database on the left; however, EOModeler refers to them as entities. We’re going to work with two of them, Listing and ListingAddress. On the right are the attributes (columns) of a Listing. You may quit EOModeler. We don’t need it anymore.
Building the Server Application
The model can now be used to automatically generate a web services-enabled server application. First, launch Xcode, located in /Developer/Applications. Choose File > New Project. In the New Project Assistant, select Direct to Web Services Application. Name the project Houses. Accept the defaults until you see the Choose EOModels pane. Add the RealEstate.eomodeld model file at /Library/Frameworks/JavaRealEstate.framework/Resources. In the Build and Launch Project pane, deselect “Build and launch project now” and click Finish.
In the Xcode main window, click the triangle next to Resources. Select the Properties file and edit it so it looks like this:
WOAutoOpenInBrowser=false WOPort=55555
 |
Click the Build and Run button in the Xcode toolbar to build and run the application. When you see the message Waiting for requests..., the WebObjects server application is running. |
Everything should look like the image below:
Configuring the Web Service
To customize a Direct to Web Services application you use the Web Services Assistant. It’s located in /Developer/Applications.
After you launch the Assistant, the Connect dialog appears. Enter http://localhost:55555 in the text input field and click Connect.
Most web services define a service with one or more operations, or methods. We’ll build a service HouseSearch and define an operation searchByPrice, which finds all house listings under a certain price. In addition to searching, WebObjects can generate Web service operations that let you insert, delete or update entries in a database.
In the Web Services Assistant main window, select http://localhost:55555 in the left-hand side list. Click the New Service toolbar button. Enter HouseSearch in the Service Name text field. Select Listing in the Available list of the Public Entities pane and add it by clicking the left-pointing arrow. Repeat for ListingAddress, making sure that the Enabled option is selected.
Now you add an operation to the HouseSearch Web service and define the calling arguments:
Click New Operation in the toolbar.
Enter searchByPrice in the Name text field.
Choose Listing from the Entity pop-up menu. Make sure the Type is search. Click OK.
In the main window, select askingPrice in the Available list in the Arguments pane and click the left-arrow button.
Choose “<=” from the Operator pop-up menu.
Select Return SOAP Struct.
Everything should look like the image below:
Now, define the return values for this operation:
In the Return Values pane, select askingPrice from the Available list and click the left-arrow button.
Click the triangle next to address. Select address.street and click the left-arrow button. Repeat for address.city, address.state and address.zip.
Click the Save toolbar button.
You have now defined the HouseSearch service with the searchByPrice operation that finds all houses with an asking price less than or equal to its askingPrice argument and returns an array of listings, each with their asking price and address.
Everything should look like the image below:
Testing the Service
Select searchByPrice under HouseSearch under http://localhost:55555.
Click the Test toolbar button. A test window is automatically generated with the appropriate user interface to test the searchByPrice operation.
Enter 250000 in the text input field and click Test. An empty list is returned. That is because a quarter of a million dollars won’t buy a home in Silicon Valley. Try again, entering 300000. This time three entries should be returned with their asking price and address.
See the image below:
Generating WSDL Documents
Web Services Definition Language or WSDL is an XML format for describing web services and the operations they provide.
In the test window, click the WSDL tab. The WSDL document describing the HouseSearch Web service and its searchByPrice operation appears.
The WSDL document can also be retrieved directly from the server via the URL http://localhost:55555/cgi-bin/WebObjects/Houses.woa/ws/HouseSearch?wsdl. If you want to download the WSDL document and look at it, using the curl command is a convenient way to do so. In Terminal, execute the following command:
curl 'http://localhost:55555/cgi-bin/WebObjects/Houses.woa/ws/HouseSearch?wsdl' -o mywsdl.txt
Conclusion
You have developed, configured and tested a working Web
service with WebObjects without writing any SOAP, XML or
Java code. In addition, you learned how to obtain the WSDL
description that you can publish so client applications can
be built that use the service.
For more information about web services and WebObjects,
please refer to the manual titled “Web Services”
on the WebObjects Documentation site.
Editor’s note: WebObjects can do a lot more than web
services, including dynamic Web pages and distributed Java
Client applications. To find out more about WebObjects,
visit the
href=”http://www.apple.com/WebObjects/”>Web Objects page.
Optimizing an Xserve for Web Hosting
A single Xserve is ideally suited for smaller scale Web hosting, where the task is to host a handful of moderate-traffic sites. (With a fleet of Xserves, you could host an eBay or an Apple.com, but that’s a topic for another article.) The Xserve’s Apache Web server software has a multitude of configuration options. In this article, I will go over how to set up Apache to serve multiple Web sites from the same machine—so-called “virtual hosting.” I will also look at ways to optimize the server’s setup for fast, robust Web hosting. This article assumes that you have already followed the steps in the Mac OS X Server Administrator’s Guide to start Web service. (You can find the Guide on the Mac OS X Server Manuals page.)
Hosting Multiple Domains on One Server
The out-of-the-box behavior of Apache is to have one IP address and to serve one domain. However, it is quite easy to transparently host thousands of domains on a single Xserve, and the users need never know that it’s one machine behind the scenes and not a whole farm. There are two approaches to this sort of “virtual hosting”—IP-based and name-based. With IP-based hosting, each domain name is mapped to its own individual IP address. Name-based hosting uses a little trickery so that many domains can be served from the same IP address. IP-based hosting is a little more robust—it allows for secured HTTPS transactions, which are important for Web commerce, reverse DNS, and some other features; but IP addresses are scarce, so name-based hosting, which works perfectly well, is probably preferable for most applications. Name-based hosting depends on a certain header sent by the browser, and as a result it doesn’t work with some browsers released before 1997, but that is less and less of an issue as those browsers become increasingly scarce. I will go over how to set up both kinds of virtual hosting.
IP-Based Hosting
Assuming you have already acquired the domain names and IP addresses you’ll be using, the first step in creating an IP-based hosting setup is to configure the Xserve to have multiple IP addresses on the same Ethernet card. This can be done from System Preferences on the Xserve. Open the Network Preferences pane. Select “Active Network Ports” from the Show drop-down menu. Choose the port corresponding to the Ethernet card that you want to assign multiple IP addresses to, and click “Duplicate.” Then simply change the duplicate configuration to reflect the second IP address. It is necessary also to make sure that the Subnet Mask setting for all but one of the ports is 255.255.255.255. This will prevent conflicts in the routing tables.
On a headless Xserve, the same thing can be accomplished with the IPAliases startup item. If the file /etc/IPAliases.conf doesn’t exist, create it. For each additional IP address, this file should contain one line of the form
interface:IPaddress:netmask
For example, to add the IP address 192.168.50.210 to the en0 network interface, the following line would be used:
en0:192.168.50.210:255.255.255.255
The netmask should always be 255.255.255.255.
In addition, IP aliases must be turned on, by adding to /etc/hostconfig the line
IPALIASES=-YES-
Every time the system is booted, the aliases listed in /etc/IPAliases.conf will be added. The file can contain any number of aliases.
With multiple IP addresses configured, the next step is to add DNS entries. For each domain that you want mapped to an IP address, create an A record in the DNS pointing the address to the site. In BIND, the A record might look like this:
firstdomain.com. A 10.151.90.2
All of the records for the various domains can be in the same DNS file or in different ones, depending on the preferences of your users and whether you host your own DNS or not.
Finally, tell Apache how to deal with requests for the various addresses. In Server Settings, click Web in the Internet tab. Choose “Configure Web Service” from the drop-down menu. In the Sites tab, you can add as many sites as you like, just by entering the domain name and IP address for each one. The content for each site should be placed in the folder you specify in the “Web folder” field here.
Name-Based Hosting
Setting up name-based hosting is a bit simpler. Add DNS records for each domain to be hosted, such that each domain name resolves to the same single IP address—the one associated with your Xserve. When a user’s browser makes a request for one of the domains, it will send an HTTP Host header indicating which domain it is requesting. Apache interprets this header and returns the appropriate content.
After the DNS is configured, go to Server Settings’ Internet tab, and choose “Configure Web Service” from the Web drop-down menu. Go to the Sites tab. Here you can create an entry for each site you want to serve. Give each one the same IP address but different domain names. Content will be served from the location specified in the “Web folder” field.
If desired, name-based and IP-based hosting can co-exist.
Handling A Lot Of Domains
If you are hosting quite a few domains, or adding new ones frequently, it can be inconvenient to add an entry for each one in Server Settings. The process can be automated to a degree, so that simply adding a DNS entry and creating a new directory for content on the Xserve is sufficient to launch each new domain. NOTE that this method and that of adding sites via Server Settings are mutually exclusive—new domains added in this way will not be reflected in Server Settings, and adding or editing sites in Server Settings will alter the configuration of the automatically created domains with unpredictable results. This method also precludes turning the performance cache on and off on a per-domain basis. That said, here are the basic steps.
First, configure a single site in Server Settings, with the correct IP address. The domain name you give it doesn’t matter. Save the changes.
Edit /etc/httpd/httpd.conf to uncomment the two lines beginning:
LoadModule vhost_alias_module
and
AddModule vhost_alias_module
Also, change the line
UseCanonicalName On
to
UseCanonicalName Off
Next, edit /etc/httpd/httpd_macosXserver.conf. There should be a long comment section starting with the line:
## The section below contains a block for each site (virtual host).
Below this comment section is the stanza to edit. It looks something like this:
#<RAdmin 100>NameVirtualHost 192.168.0.25:80
Listen 192.168.0.25:80
<VirtualHost 192.168.0.25:80>
#WebPerfCacheEnable Off
#SiteAutomaticallyDisabled Off
ServerName example.com
ServerAdmin webmaster@example.com
DocumentRoot "/Library/WebServer/Documents/"
DirectoryIndex index.html index.php
CustomLog "/private/var/log/httpd/access_log" "%{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"
ErrorLog "/private/var/log/httpd/error_log"
and so on.
The stanza may look somewhat different if performance caching is enabled.
There are just a few changes to make to this. First, on the ServerName line, you can place the fallback domain to which users of pre-1997 browsers will be sent. This line has to exist, but for users of modern browsers, it will be ignored.
Then modify the DocumentRoot line to look like this:
VirtualDocumentRoot /Library/WebServer/Documents/%0
and the CustomLog line to include %v :
CustomLog "/private/var/log/httpd/access_log" "%v %{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"
Save the file and restart Apache.
The VirtualDocumentRoot directive tells Apache to interpolate information from the server name, which in this case is read on the fly from the user’s browser, into the pathname. “%0” is a specifier representing the requested domain name. Thus, a browser request for http://domain-ten.com/index.html will be answered with the file at /Library/WebServer/Documents/domain-ten.com/index.html.
As a result, to host a new domain, all that has to be done is to create a new directory corresponding to the domain name in /Library/WebServer/Documents, and to place content to be served in that directory.
The various specifiers understood by the VirtualDocumentRoot directive are explained on the apache.org website. For example, if you have hundreds of domains hosted, they can be sorted into 36 directories based on their first alphanumeric character with the following directive:
VirtualDocumentRoot /Library/WebServer/Documents/%1.1/%0
A side-effect of this aliasing technique is that log data for all the virtual domains is sent to the same file. Adding the “%v” specifier to the CustomLog line prepends the name of the domain to each log line. A simple script can be used to parse this master log file into individual files for each domain, if so desired. More information on CustomLog specifiers is available on the apache.org website.
Tuning Web Server Performance
When setting up an Xserve for use as a Web server, there are a number of things you can do to improve performance. Some of these techniques improve the performance of the machine in general; others involve examining where bottlenecks may be occurring and tuning the Web server to work around them.
First, it is important to make sure the hardware is up to speed. Even a low-end Xserve has a very nice feature set, including fast disk access, fast Ethernet, and a minimum of 256MB of RAM out of the box. The RAM allotment can be increased to 2 gigs: if the Web server at full-throttle seems to be using a lot of memory, buying more RAM could speed things up considerably. In terms of hardware, there are several options that will increase reliability, including IP failover to a second server, which is described in detail in the Admin Guide, and adding an Xserve RAID for ultra-fast and reliable storage.
In addition to the hardware approaches, there are a number of software-based strategies for optimizing a Web server. I will detail some of these below.
Apple’s Performance Cache
Included in the OS X Server installation is Apple’s performance cache. This acts as an intermediary between the Apache Web server and the user: the cache stores a copy of commonly requested pages from the sites served, and, upon receiving a user request for one of these pages, sends it along. This involves much less overhead than invoking Apache each time the page is requested. Apache is still kept busy serving dynamic and less common pages. The cache can be enabled and disabled individually for each of the sites served from the machine. In general, the cache is very helpful for highish-traffic sites that consist primarily of static HTML pages. The total size of the site’s popularly requested static pages should be small enough to fit in the machine’s RAM; otherwise caching may actually slow things down. For sites with primarily dynamic content, the cache will not be helpful.
To turn the performance cache for a particular site on or off, go to the Internet tab in Server Settings and click Web. Choose “Configure Web Service,” and then select the Sites tab. Edit the site you want to change, and go to the Options tab. Check or uncheck “Enable performance cache” and save. The changes take effect when the Web server is restarted from the Web drop-down menu. Note that this cannot be done with a server configured with dynamic site addressing, as explained above.
Aspects of the behavior of the cache can be configured in the file /etc/webperfcache/webperfcache.conf. The default settings seem to work quite well, but they can be adjusted to make the cache work better with tweaked Apache settings (see below) or unusual server configurations.
Tweaking Apache
Apache has various settings which control how it handles requests. Tuning these can make a big difference in the performance of the server.
Apache’s performance can be monitored by viewing yourhosteddomain.com/server-status in a browser. Configure the <Location /server-status> section in /etc/httpd/httpd_macosXserver.conf to control who can view the status: it’s set by default to deny all but localhost.
Eliminating Unnecessary Modules
The first step in speeding up Apache is to remove any unnecessary modules. To see which modules are compiled in, do the following:
In httpd.conf, there is a section that looks like this:
#<Location /server-info># SetHandler server-info # Order deny,allow # Deny from all # Allow from .your-domain.com #</Location>
Remove the # from the beginning of each line to uncomment the directive. Change “.your-domain.com” to the actual domain(s) that you wish to access server information from, and then restart Apache.
Now http://yoursite.com/server-info should display a variety of detailed information about the server, including which modules are compiled in, and configuration information for each module.
Modules that are compiled in statically can’t be removed without recompiling the Web server. The out-of-the-box configuration of Apache on Xserve has almost every module compiled as dynamically loadable, so it is easy to turn off unnecessary ones without recompiling the Web server. Dynamic modules are loaded when Apache starts, according to the LoadModule and AddModule directives in the file /etc/httpd/httpd.conf.
The base installation of Apache that ships with OS X Server loads quite a few dynamic modules by default. Each of these takes up some memory, and some of them, such as mod_status, cause Apache to do extra work with every request. Any modules that aren’t necessary to the functioning of the sites you host should not be loaded. This can be controlled by commenting out (by prefixing a # on each line) the relevant LoadModule and AddModule directives for each module in /etc/httpd/httpd.conf. Every module has both a LoadModule and and AddModule directive—be sure to comment out both when disabling a module. Mod_include and mod_rewrite, among others, are notorious performance hogs.
Adjusting Processes
There are several directives that can be adjusted to modify how Apache handles traffic. Apache will spawn new versions of itself to handle requests. MaxClients sets the maximum number of these that will be spawned. The more of these there are, the faster Apache can handle a large number of requests—up to the limitations of the machine’s memory. The default is 500. Figure on about 1 MB of RAM for each httpd instance, and set MaxClients accordingly in Server Settings (or /etc/httpd/httpd_macosXserver.conf).
The MinSpareServers and MaxSpareServers directives, in /etc/httpd/httpd.conf, set how many spare server processes are running to handle sudden requests. StartServers sets how many are created when Apache first starts. You may want to increase StartServers and MaxSpareServers if Apache seems to be slowing down when it has to create new processes. When Apache spawns more than four child processes per second—a sign that it may need more spare servers—it logs that fact to its error log. Keep an eye on the log and tune if necessary.
MaxRequestsPerChild keeps a lid on potential memory leaks by killing off each child process after it has served a certain number of requests. The default setting on OS X Server is 100,000, which is reasonable. A setting of 0 means that Apache’s children are never killed.
The KeepAlive settings in /etc/httpd/httpd_macosXserver.conf control how each server process listens for new requests on a connection that has been established. Increasing KeepAlive requests reduces traffic from new connections, but increases server load with many Apache processes waiting around for orders.
Removing Extra Steps
Another key to speeding up Apache’s behavior is to minimize the number of things it has to do for each request. If the Web server is receiving a lot of requests, these extra tasks can bog it down tremendously.
HostnameLookups causes Apache to perform a DNS lookup for every incoming request, so it can log the domain name as well as the IP address in the access log. This should be turned off, as it is by default, if performance is an issue. The DNS lookups can be performed after the fact, on another machine, using a tool such as logresolve.
If AllowOverride is turned on, then Apache checks for the presence of .htaccess files containing overriding directives at every level of the hierarchy. This repetitive checking eats up server resources. For maximum performance, set AllowOverride None. (This is the default setting for OS X Server.)
FollowSymLinks is a directive that instructs Apache to follow symbolic links without performing an additional security check on them. If this is turned off, Apache slows down to check each symbolic link.
Finally, logging is very important for 95 percent of Web-hosting activities, but if you are not using it, turning it off will improve performance. All that file access slows things down considerably. Set TransferLog /dev/null in /etc/httpd/httpd.conf.
Temporary Adjustments
Sometimes, if you’re lucky, you have advance warning of a peak in Web traffic; say, a well-read news site is planning to link to one of the domains you host tomorrow. There are a few emergency preparations that can be made to allow for that kind of situation.
First, free up memory and CPU by offloading everything you can. If the Xserve is acting as a mail server, database server, or what-have-you, as well as a Web server, move those duties to another machine if possible. If there are other medium-traffic domains that could be hosted elsewhere temporarily, do it. Shut down unnecessary processes and cron jobs.
Second, make sure you have enough bandwidth. If you use a firewall, you may want to reconfigure its socket handling to maximize throughput.
If it is possible, making changes to the content of the
domain to be served can be very effective. Remove images, reduce
their file sizes, or simply move them to another server and
serve them from there.
Apache’s MaxClients limit is hard-coded at 2048 in OS X
Server. For peak traffic, you may want far more clients than
this. It is necessary to recompile Apache to make this change.
You will have to download the source code from the
href=”http://httpd.apache.org/download.cgi”>apache.org website. In the source file src/include/httpd.h,
change the line
#define HARD_SERVER_LIMIT 2048
to
#define HARD_SERVER_LIMIT 4096
Or whatever number seems appropriate. Note that the number given here is usually a factor of 2.
Then recompile according to the instructions in the INSTALL file included with the source.
Careful deployment of all of these tips should significantly improve the way the Xserve handles Web serving. If, after all of the above, your server simply can’t handle the load it’s getting, that’s when you should consider adding a second machine to share the burden.
Web Hosting
You don’t need to be an experienced webmaster to host your own home page, website, or Web 2.0 application with Mac OS X Server. With its intuitive administrative interface, you can immediately start up a static website or deploy even the most sophisticated of sites.
Powered by Apache.
Included in Mac OS X Server is Apache, the most widely used HTTP server on the Internet. Apache is preconfigured with default settings, so deployment is as simple as starting the Web service. Any HTML content saved to the server’s default web folder will be served over the Internet automatically. Mac OS X Server offers experienced webmasters support for using either Apache 2.2 or Apache 1.3 from within the Server Admin application.
Deploy the Web 2.0.
Everything you need to develop, deploy, and host reliable Web 2.0 applications is included. Mac OS X Server ships with a full complement of server applications and frameworks including Apache 2, Ruby on Rails, Tomcat 5, and WebObjects 5.4. For hosting enterprise-class applications, Mac OS X Server includes a 64-bit Java VM optimized for the latest generation of Intel multicore processors.
Hosting multiple websites.
Support for virtual hosting in Mac OS X Server allows you host multiple websites on a single server. Using Server Admin, you can configure each website on your server to have a different domain name (using virtual domains) and even a different IP address. In addition, each website can be configured with unique security options and separate log files for tracking and reporting.
Apache Performance
Up to 50% improvement over Tiger Server*
Leopard Server Xserve Quad Xeon
1.56x
Tiger Server Xserve Quad Xeon
Baseline
Apache performance
Be dynamic.
Apache is extremely flexible, so you can add dynamic content for a more interactive Internet solution. Dynamic content enables you to host stores, auctions, shared calendars, portal systems, polls, and other database-driven services. The robust server-side architecture in Apache supports dynamic content generated by server-side includes (SSIs), PHP, Perl, Apache modules, and custom CGIs — as well as by JavaServer Pages (JSPs) and Java Servlets.
Secure web services.
Mac OS X Server integrates OpenSSL with the Apache web server, providing support for strong 128-bit encryption and public key infrastructure (PKI) authentication using X.509 digital certificates. This high-grade security architecture protects credit card information and other confidential personal and business data transmitted during web transactions.
Best OS X Hosting
OSX Hosting Tips and Tricks
- An error has occurred; the feed is probably down. Try again later.
Blog Stats
- 9,026 hits
Apple Hot News
- Apple Updates Safari 5
- Apple Updates iMac Line
- Apple Unveils New Mac Pro With Up to 12 Processing Cores
- Apple Unveils New 27-inch LED Cinema Display
- iPhone 4 Arrives in 17 More Countries This Friday
- Statement by Apple on White iPhone 4
- Apple Reports Third Quarter Results
- iPad Available in Nine More Countries This Friday
- FY 10 Third Quarter Results Conference Call
- Letter from Apple Regarding iPhone 4
OS X hosting, Xserves, Mac Minis, G4's, G5s 