PHP 5.3 added a useful feature, per-directory .ini files. You can enter PHP configuration directives into a text file named “.user.ini”, upload it to your htdocs directory or any other directory of your website, and that configuration will be used for any PHP scripts in that directory or below.
For example, you may not want to display page errors to visitors of your website, but want to see them for anything in the /development/ sub-directory where you’re working on new things. You might create a .user.ini file in that sub-directory containing
error_reporting = E_ALL
display_errors = On
display_startup_errors = On
Or perhaps you have a sub-directory of remote procedure calls which are invoked from a webpage via AJAX and always return JSON data. You could simplify them by creating a .user.ini file in that subdirectory containing
default_mimetype = “application/json”
display_errors = Off
What can’t you do? You can’t use any configuration directives marked PHP_INI_SYSTEM, which cover fundamental and security-related PHP configuration are reserved for the root php.ini file.
IP address allocation for web hosting isn’t really a new topic, it has in fact been pretty well resolved for over a decade. But it’s still a point of confusion to some people, so here we go.
Websites have a hostname, like www.iphouse.com. When you click on a link or enter a URL into your web browser, the browser extracts the hostname from the URL and opens a connection to it. But the network doesn’t work with a hostname, it works with numeric IP addresses like 3522190849, which is usually written 18.104.22.168. So the web browser first has to look up the IP address for the hostname through DNS, the Domain Name System. Once it has an IP address, it can open a connection to the server and request the file.
Having a development server separate from your production server is a great idea. You can make changes without fear of breaking your production system. You can develop and test new features before they’re ready to roll out. And you can try out entirely new ideas without committing to development.
With that, it should be pretty clear that your development server should be as identical as possible to your production environment. It does you no good to write a new feature which leverages FiddlyC 4.2pl64 with QuirkyProc enabled if your production server is designed for and built and upon FiddlyC 3.
Fortunately, this is something which a virtual data center makes really easy. If you’ve based your production server on a template from your catalog, it’s just as easy to create two or three identical VMs based on that template as it is to create one. If you want to try something really new, create a new VM. If it doesn’t work out, tear it down and recover the resources.
You can even clone your current production vApp and servers into a template, if you have space available and can afford the downtime. You’ll need to shut down the vApp, then right-click on it and select “Add to Catalog”. Give it a name, and click OK. This will take some time, depending on how many VMs and how much disk is allocated. Once the process completes, don’t forget to restart your production vApp. But now you’ll be able to create a development environment which is exactly identical (aside from network names and addresses) to the original.
Since most web browsers limit the number of concurrent requests to any particular host, loading scripts from other sites can get your website to load from your server faster. For some sites, it’s also the best way for them to offer an integration API, with minimal concern for breaking old code (since they control it all).
However, there can be a downside. Loading lots of scripts from other servers makes your website more dependent on those servers, which are outside your control. If any of them are down or inaccessible, it affects the performance and usability of your website as well. I’ve encountered this more often as content offloading has become more common, and its pretty annoying when a page stalls completely for want of some trivial bit of fluff.
What do you think? Does offloading lead to a faster and more usefully integrated web? Or to a house of cards, ready to topple at the first server outage anywhere?
Caching is a key component to any system design. Caching allows programs to be lazy, by referring to data that’s already been access. Looking up data takes a lot of work. Think of it this way: Someone asks you want the Capital of Indonesia is, and you don’t have Google handy. You have to figure out the best reference to look in, probably an encyclopedia, find the proper page, search on that page for the data that corresponds to “Capital”, in this case, Jakarta, and relay that information back to the person that asked you. However, five minutes later someone else asks you “what is the capital of Indonesia” and you simply say “Jakarta.” You’ve cached that data, and are now returning it. (more…)