The Canonical/Ubuntu Landscape service has been around for as long as I can remember using Ubuntu. A free trial period is enabled (re-enabled?) when a new installation occurs, that allows for a server administrator to see performance metrics and uptime information for any hardware that is running the client. After the trial ends, it is still a quick means of visually observing some key statistics in the terminal MOTD at login. I’d also noticed that it was still doing DNS lookups to “
landscape.canonical.com” on a regular basis, and while I did not look for it, I assume that some information was still being collected and reported upon.
As there are MANY other ways to get server performance information, I decided that it was time to be rid of landscape itself.
Removal is easy, as only one line is required… I chose to “purge” all references, though you can “remove” if you feel inclined to leave any configuration for possible later re-installation.
sudo apt-get purge landscape-client landscape-client-ui landscape-client-ui-install landscape-common
Categories: WebStandards, Work canonical, cpu, landscape, memory, motd, performance, purge, remove, server, temperature, terminal, ubuntu, uninstall
Installing MySQL on Ubuntu requires only a few simple steps.
sudo apt-get install mysql-server
sudo netstat -tap | grep mysql
sudo vi /etc/mysql/my.cnf
sudo service mysql restart
To look for some simple performance and security suggestions:
sudo apt-get install mysqltuner
Adding a new user is equally easy…
mysql --user=root --password=mypassword mysql
CREATE USER 'myusername'@'%' IDENTIFIED BY 'mypassword';
GRANT ALL PRIVILEGES ON *.* TO 'mydatabase'@'%' WITH GRANT OPTION;
NOTE: This allows access to the user from ALL hosts, it can be limited by replacing the
'%' with a specific hostname (such as ‘localhost’ if desired) for security.
Categories: WebStandards, Work add, command, database, db, grant, install, line, mysql, new, password, performance, privileges, security, server, sql, tuner, ubuntu, user
Logging is often an overlooked performance drain on systems requiring high throughput. Here’s a simple change to the default Tomcat logging configuration to implement. It works on all operating systems.
In the file:
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler
Categories: WebStandards, Work apache, configuration, linux, logging, performance, properties, server, tomcat, ubuntu, windows
There are four primary features/goals of strict mode:
- Throws errors for some common coding issues, that are sometimes obscure but previously didn’t throw an error.
- Prevents or throws errors for potentially “unsafe” actions (such as gaining access to the global object).
- Disables functions that are confusing or poorly thought out
Initial support added in FireFox 4 and MSIE10:
WARNING: if you chose to do this at a ‘file’ level, be sure to never concatenate several files together that are not ALL strict.
JS File Example:
var testvar = 1;
// This causes a syntax error.
testvar = 2;
JS Function Example:
// This causes a syntax error.
testvar = 1;
testvar = 2;
Regardless if you host your own websites, or pay to have them hosted elsewhere, up-time, availability and network performance metrics are important to your visiting guests.
Here are two free services that I’ve found useful for monitoring, notification and reporting.
BTW, you can even use these to watch competitors or sites that you frequent.
Categories: WebStandards, Work availability, free, http, monitoring, network, performance, reporting, server, ssh, web
Most developers (myself included) are often unaware of the performance impact of the Content-Type / charset of a web page. Ideally you should set this as an HTTP Header vs. using
META http-equiv. It’s often though that this only helps with the transport and display of data, however, the browser also makes use of it when parsing CSS & JS assets. Tags related to those provide an optional ‘
charset‘ attribute should they ever need to vary from your content.
General guidance is to set this at the very top of the
<title> and within the first 1024 bytes, though there are reports that Firefox will look at the first 2048 bytes of the page for this
Not doing so may cause the browser to do a codepage restart to re-parse assets that were interpreted in the potentially incorrect codepage.
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Categories: WebStandards, Work browser, charset, codepage, content, css, iso, js, parse, performance, render, type, unicode, utf
Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.
It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.
The solution is both simple and painless to implement…. just add an empty condition above all of the other content. This works for all approaches, such as those where comments surround the <body> or various
Categories: MSIE bugs, WebStandards, Work block, blocking, browser, comments, conditional, connections, css, files, hacks, ie, link, msie, network, performance, script, style
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support
Categories: MSIE bugs, WebStandards, Work acceleration, akamai, application, browser, cache, cdn, client, cloudflare, content, delivery, fast, http, ipv4, ipv6, network, performance, security, server, speed, web, webapp
In the past few years the browser wars have heated up again. Performance and capabilities of some browsers varies greatly. There are several standard tests that are publicly available to benchmark your systems. WebKit (Safari, Chrome & Chromium) and Mozilla (Firefox) based browsers, as well as Opera perform pretty well, MSIE is currently trailing in most cases.
Here are a few common ones…
These are useful for some advanced caching behavior, but there are cases where you might find them unnecessary for static files (in particular). Most network analysis tools will call attention to this header value, and while it seems like a trivial amount of bandwidth to send from the server to the client, the real reason for the negative score is more likely related to the behaviors that it causes in the client.
It should be noted that the default value used for the ETag is based upon the ‘inode’ of the file, as such it’s IS problematic in clustered server environments. I’ve shown the correction for this below.
Adding the following to your Apache http.conf file is a start:
# Change ETag to remove the iNode (for multi-server environments)
FileETag MTime Size
#Remove ETag from all static content, this could be done globally without the FilesMatch, but we want better control.
Header unset ETag
Categories: WebStandards, Work apache, browser, cache, caching, ETag, header, http, network, performance, server