Thursday, April 18, 2013

FlushDNS cache on Mac OS X and Linux



#flush your DNS cache on your Mac OS X machine


#Yosemite
sudo discoveryutil mdnsflushcache

#Mountain Lion
sudo killall -HUP mDNSResponder


#CentOS
sudo /etc/init.d/nscd restart










Wednesday, April 17, 2013

Expand LVM in CentOS 6


# review your disk layout
fdisk -l

# scan for new disk.
echo "- - -" > /sys/class/scsi_host/host0/scan

# check disk layout again {notice changes}
fdisk -l



fdisk /dev/sda
p  (print partition table)
n  (New partition)
p  (primary partition)
3  (ID #3 (this may be different for you, since I already had /dev/sda1 and 2)

# When asked for block value, add 1 to the end of block value for sda2 partition and use it as the start of the sda3 partition.  

t  (change partition type)
3 (change partition 3)
8e (Type = Linux LVM)
p (print the partition table again)
w (write the partition table)


# Now create a new LVM physical volume from the partition you just created.
lvm pvcreate /dev/sda3
lvm pvdisplay

# Mount the volume group
lvm vgscan
lvm vgchange -ay
* a message will echo that the volume group is activated.

# extend the volume group with the new physical volume.  change the volume group hostname with yours. 
lvm vgextend /dev/vg_vdevd01 /dev/sda3

# now extend the logical volume to include the new partition. 
lvm lvextend /dev/vg_vdevd01/lv_home /dev/sda3

# Mount the volume group
lvm vgscan
lvm vgchange -ay

# Run a filesystem check on the newly expanded disk
e2fsck -f /dv/vg_hostname/lv_root

# resize the filesystem to use the entire disk
resize2fs /dev/vg_vdevd01/lv_home

# reboot and check your new disk 
df -h

Thursday, March 28, 2013

Execution is the Key

Three things that need to be done in order to accomplish your goals.  Don't set vague goals without knowing the details.

1.  Understand what to do.
2.  Understand how to do it.
3.  Execute

Most people set vague goals such as exercising more, improving on A or B, etc.  The key is lay out the plan on what steps are needed to call this goal a success.  "Working on it" is not completing it.  You don't get to check it off your list if your still "working on it".   One good point to remember is that the beginning is usually the most difficult both physically and mentally.  Don't quit! Get past the first few hurdles and keep going.  

-Khalid

Thursday, February 7, 2013

Monday, January 28, 2013

Seth Goden - Beyond Showing up


Beyond showing up

You've probably got that part nailed. Butt in seat, smile on your face. We often run into people who understand their job to be showing up on time to do the work that's assigned.
We've moved way beyond that now. Showing up and taking notes isn't your job. Your job is to surprise and delight and to change the agenda. Your job is to escalate, reset expectations and make us delighted that you are part of the team.
Showing up is overrated. Necessary but not nearly sufficient.

Monday, December 24, 2012

21 tips to get you to your best productivity


Another great article from Robin Sharma via robinsharma.com

Here are 21 tips to get you to your best productivity.
#1. Check email in the afternoon so you protect the peak energy hours of your mornings for your best work.
#2. Stop waiting for perfect conditions to launch a great project. Immediate action fuels a positive feedback loop that drives even more action.
#3. Remember that big, brave goals release energy. So set them clearly and then revisit them every morning for 5 minutes.
#4. Mess creates stress (I learned this from tennis icon Andre Agassi who said he wouldn’t let anyone touch his tennis bag because if it got disorganized, he’d get distracted). So clean out the clutter in your office to get more done.
#5. Sell your TV. You’re just watching other people get successful versus doing the things that will get you to your dreams.
#6. Say goodbye to the energy vampires in your life (the negative souls who steal your enthusiasm).
#7. Run routines. When I studied the creative lives of massively productive people like Stephen King, John Grisham and Thomas Edison, I discovered they follow strict daily routines. (i.e., when they would get up, when they would start work, when they would exercise and when they would relax). Peak productivity’s not about luck. It’s about devotion.
#8. Get up at 5 am. Win the battle of the bed. Put mind over mattress. This habit alone will strengthen your willpower so it serves you more dutifully in the key areas of your life.
#9. Don’t do so many meetings. (I’ve trained the employees of our FORTUNE 500 clients on exactly how to do this – including having the few meetings they now do standing up – and it’s created breakthrough results for them).
#10. Don’t say yes to every request. Most of us have a deep need to be liked. That translates into us saying yes to everything – which is the end of your elite productivity.
#11. Outsource everything you can’t be BIW (Best in the World) at. Focus only on activities within what I call “Your Picasso Zone”.
#12. Stop multi-tasking. New research confirms that all the distractions invading our lives are rewiring the way our brains work (and drop our IQ by 5 points!). Be one of the rare-air few who develops the mental and physical discipline to have a mono-maniacal focus on one thing for many hours. (It’s all about practice).
#13. Get fit like Madonna. Getting to your absolute best physical condition will create explosive energy, renew your focus and multiply your creativity.
#14. Workout 2X a day. This is just one of the little-known productivity tactics that I’ll walk you through in my new online training program YOUR PRODUCTIVITY UNLEASHED (details at the end of this post) but here’s the key: exercise is one of the greatest productivity tools in the world. So do 20 minutes first thing in the morning and then another workout around 6 or 7 pm to set you up for wow in the evening.
#15. Drink more water. When you’re dehydrated, you’ll have far less energy. And get less done.
#16. Work in 90 minute blocks with 10 minute intervals to recover and refuel (another game-changing move I personally use to do my best work).
#17. Write a Stop Doing List. Every productive person obsessively sets To Do Lists. But those who play at world-class also record what they commit to stop doing. Steve Jobs said that what made Apple Apple was not so much what they chose to build but all the projects they chose to ignore.
#18. Use your commute time. If you’re commuting 30 minutes each way every day – get this: at the end of a year, you’ve spent 6 weeks of 8 hour days in your car. I encourage you to use that time to listen to fantastic books on audio + excellent podcasts and valuable learning programs. Remember, the fastest way to double your income is to triple your rate of learning.
#19. Be a contrarian. Why buy your groceries at the time the store is busiest? Why go to movies on the most popular nights? Why hit the gym when the gym’s completely full? Do things at off-peak hours and you’ll save so many of them.
#20. Get things right the first time. Most people are wildly distracted these days. And so they make mistakes. To unleash your productivity, become one of the special performers who have the mindset of doing what it takes to get it flawless first. This saves you days of having to fix problems.
#21. Get lost. Don’t be so available to everyone. I often spend hours at a time in the cafeteria of a university close to our headquarters. I turn off my devices and think, create, plan and write. Zero interruptions. Pure focus. Massive results.
I truly hope these 21 productivity tips have been valuable to you. And that I’ve been of service. Your productivity is your life made visible. Please protect it.
Stay productive.

Tuesday, December 18, 2012

Using mod_jk1.2 with JBoss



Using mod_jk 1.2.x with JBoss/Tomcat bundle and Apache2

Quick Overview


  1. Download Apache2
  2. Download modjk 1.2.x (At least 1.2.27 suggested)
  3. Change the main Apache config to include modjk config
  4. Create the modjk config
  5. Configure the modjk workers (which JBoss/Tomcat nodes Apache uses)
  6. Configure the Apache URIs served by modjk (the applications served by JBoss/Tomcat)
  7. Restart Apache
  8. Configure Tomcat (Give each JBoss/Tomcat a jvmRoute for session stickness)
  9. Restart JBoss
  10. Test it

mod_proxy

Most httpd-2.2.x actual distributions (x>=6) have a decent AJP proxying and don't require to compile an external module. See

More Details


This wiki outlines the various steps required to install a basic load-balancing solution based on JBoss/Tomcat and mod_jk 1.2.

Step 1: Download Apache2 Web Server

Get the latest Apache2 package from Apache.org and install it. We require no special configuration, just use the default settings.
In the following steps, APACHE_HOME will represent the Apache install directory.

Step 2: Download mod_jk 1.2.x

Download the latest package available from Tomcats's 'Download Tomcat connector section' page . Always download the latest stable release if possible.

Rename the lib mod_jk.so and drop it in APACHE_HOME/modules directory.

NOTE: Don't use any release prior to mod_jk 1.2.15. Earlier releases are fairly buggy.

+
Note: Darwin Ports supports the installation of mod_jk on OS X. See http://darwinports.opendarwin.org/ for more info.
+

Step 3: Setup Apache to use modjk

Add this line at the very bottom in APACHE_HOME/conf/httpd.conf :
# Include mod_jk configuration file
Include conf/mod-jk.conf

Step 4: Create the modjk config

Under APACHE_HOME/conf, create mod-jk.conf and populate it as follows:
# Load mod_jk module
# Specify the filename of the mod_jk lib
LoadModule jk_module modules/mod_jk.so

# Where to find workers.properties
JkWorkersFile conf/workers.properties

# Where to put jk logs
JkLogFile logs/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel info

# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

# JkOptions indicates to send SSK KEY SIZE
# Notes: 
# 1) Changed from +ForwardURICompat. 
# 2) For mod_rewrite compatibility, use +ForwardURIProxy (default since 1.2.24)
# See http://tomcat.apache.org/security-jk.html  
JkOptions +ForwardKeySize +ForwardURICompatUnparsed -ForwardDirectories

# JkRequestLogFormat
JkRequestLogFormat "%w %V %T"

# Mount your applications
JkMount /__application__/* loadbalancer
# Let Apache serve the images
JkUnMount /__application__/images/* loadbalancer

# You can use external file for mount points.
# It will be checked for updates each 60 seconds.
# The format of the file is: /url=worker
# /examples/*=loadbalancer
JkMountFile conf/uriworkermap.properties

# Add shared memory.
# This directive is present with 1.2.10 and
# later versions of mod_jk, and is needed for
# for load balancing to work properly
# Note: Replaced JkShmFile logs/jk.shm due to SELinux issues. Refer to 
# https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225452
JkShmFile run/jk.shm

# Add jkstatus for managing runtime data
<Location /jkstatus>
JkMount status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

mod_jk is ready to forward requests to JBoss instances. We need now to setup the workers

Note: As of mod_jk 1.2.6+ you need to include "JkMountCopy all" in globals if you intend to specify global JkMount's or JkMountFile's instead of per VirtualHost. If you do not want to copy the same JkMount/JkMountFile for each VirtualHost, you can specify "JkMountCopy On" inside the VirtualHost directive.

-


Step 5: Configuring workers

Under APACHE_HOME/conf, create workers.properties and populate it as follows:
# Define list of workers that will be used
# for mapping requests
# The configuration directives are valid
# for the mod_jk version 1.2.18 and later
#
worker.list=loadbalancer,status


# Define Node1
# modify the host as your host IP or DNS name.
worker.node1.port=8009
worker.node1.host=node1.mydomain.com
worker.node1.type=ajp13
worker.node1.lbfactor=1
worker.node1.prepost_timeout=10000 #Not required if using ping_mode=A
worker.node1.connect_timeout=10000 #Not required if using ping_mode=A
worker.node1.ping_mode=A #As of mod_jk 1.2.27
# worker.node1.connection_pool_size=10 (1)

# Define Node2
# modify the host as your host IP or DNS name.
worker.node2.port=8009
worker.node2.host= node2.mydomain.com
worker.node2.type=ajp13
worker.node2.lbfactor=1
worker.node2.prepost_timeout=10000 #Not required if using ping_mode=A
worker.node2.connect_timeout=10000 #Not required if using ping_mode=A
worker.node2.ping_mode=A #As of mod_jk 1.2.27
# worker.node1.connection_pool_size=10 (1)

# Load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2

# Status worker for managing load balancer
worker.status.type=status

Important: Please review http://tomcat.apache.org/connectors-doc/reference/workers.html for the directive descriptions. Especially lookout for the comments on cachsize for Apache 1.3.x.

(1) You should only set the connection_pool_size if the number of allowed connection to the Httpd is higher than maxThreads in server.xml

If you specify worker.loadbalancer.sticky_session=Off, each request will be load balanced between node1 and node2. But when a user opens a Session on one server, it is a good idea to always forward this user's requests to the same server. Otherwise the user's session data would need to be synchronized between both servers. This is called a "sticky session", as the client is always using the same server he reached on his first request.
Session stickiness is enabled by default.

Side Note: a non-loadbalanced setup with a single node required the "worker.list=node1" entry before mod_jk would function correctly. Without this setting I would only get a 500 error and no other useful messages in log or otherwise. -Harlequin516

Side Note: I tried both loadbalanced and single node methods on Fedora 4. Both setups causing jk.shm errno=13 and jk-runtime-status errno=13 in the mod_jk.log. Could only get 500 errors. As a last resort disabled selinux on apache server. Restarted service and connection was made first try. -paulbrown


Step 6: Create the URI to worker map file

Create a uriworkermap.properties file in the APACHE_HOME/conf directory. This file should contain the URL mappings you want Apache to forward to Tomcat. The format of the file is /url=worker_name. To get things started, paste this example into the file you created:
# Simple worker configuration file
#

# Mount the Servlet context to the ajp13 worker
/jmx-console=loadbalancer
/jmx-console/*=loadbalancer
/web-console=loadbalancer
/web-console/*=loadbalancer
/myapp/*=loadbalancer
!/myapp/images/*=loadbalancer
This will configure mod_jk to forward requests for the /jmx-console/web-console and /myapp contexts to JBoss Web. The '!' at the beginning of the last line results in the URLs for the images dir in the myapp context not being forwarded. Instead httpd will handle them directly (which means they must be available on the httpd server).

Step 7: Restart Apache


Step 8: Configure Tomcat

To complete the configuration, we also need to name each node to match the names specified in workers.properties.

To do this, edit the server.xml file. Where server.xml is located depends on the version of JBoss AS:

  • In JBoss 5, it's $JBOSS_HOME/server/all/deploy/jbossweb.sar/server.xml
  • In JBoss 4.2.x and EAP 4.x, it's $JBOSS_HOME/server/all/deploy/jboss-web.deployer/server.xml
  • In earlier releases it's $JBOSS_HOME/server/all/deploy/jbossweb-tomcatXX.sar/server.xml where XX is 40, 50, 55 etc depending on the Tomcat version embedded in the AS.

(In the examples above, replace /all/ with the name of the AS configuration you are running.)

Locate the <Engine/.> element and add an attribute jvmRoute:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">
.
</Engine>
The jvmRoute attribute value must match the name specified in workers.properties.

In the server.xml file, make sure that the AJP 1.3 Connector is uncommented, e.g.:

<!-- A AJP 1.3 Connector on port 8009 -->
<Connector port="8009" address="${jboss.bind.address}"
      emptySessionPath="true" enableLookups="false" redirectPort="8443" 
      protocol="AJP/1.3" connectionTimeout="600000" maxThreads="200"/>

If you are only accepting requests via mod_jk, you can comment out the regular HTTP Connector; Tomcat then won't listen on port 8080.

Step 9: Activate the JvmRouteValve in JBoss (not needed with Tomcat Standalone)

Finally, we need to tell JBoss to add a special valve that detects when failover of a session from a distributable webapp has occurred. This JvmRouteValve ensures a new session cookie is emitted that includes the jvmRoute of the server that is now handling the session.

This configuration step is only needed with JBoss 4.2.x and earlier; beginning with JBoss AS 5 the application server uses the existence of a jvmRoute configuration in server.xml as an indication that it should add the JvmRouteValve.

To do this, edit the jboss-service.xml file for the JBoss Web service. Where this is located depends on the version of JBoss AS:

  • In JBoss 5, this step isn't needed.
  • In JBoss 4.2.x and EAP 4.x, it's $JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml
  • In earlier releases it's $JBOSS_HOME/server/all/deploy/jbossweb-tomcatXX.sar/META-INF/jboss-service.xml where XX is 40, 50, 55 etc depending on the Tomcat version embedded in the AS.

Locate the <attribute> element with a name of UseJK, and set its value to "true":
<attribute name="UseJK">true</attribute>


Step 10: Restart JBoss AS.

Step 11: Access the JBoss AS web-console through Apache by browsing to http://localhost/web-console and you should see the JBoss web console page.

-

Note: to use mod_jk with Jboss 2 (e.g. jboss 2.4.6), you must edit jboss.jcml. Add the 'jvmRoute="myWorker"' to the Engine element under the EmbeddedCatalinaSX mbean.
-

-

Note: You may need to use VirtualHost in you mod-jk.conf. For example:
Instead of just
JkMount /jmx-console   loadbalancer
JkMount /jmx-console/* loadbalancer
try
<VirtualHost host.name.or.IP>
  ServerName host.name.or.IP

  JkMount /jmx-console loadbalancer
  JkMount /jmx-console/* loadbalancer
</VirtualHost>
-

Configure Jboss to use hugepages in RHEL/CentOS

HOW TO : Configure Jboss to use hugepages in RHEL/CentOS | Kudithipudi.Org:

'via Blog this'

Understanding JVM Internals | CUBRID Blog

Understanding JVM Internals | CUBRID Blog

Friday, November 16, 2012

3 web performance mistakes and how to avoid them



Could you imagine NASA sending a rocket into space without testing it first? What about a racing team putting a brand new car on the track without taking it for a few laps to test the handling and stability? It seems to me that testing is inherent in every technical field — except for website development that is.
Too often we see websites where it’s clear that design was the main priority, while testing the site’s functionality and user experience was just an afterthought. What you’re left with is a great looking website that feels like it is being sent over the Internet via carrier pigeon. And that’s going to send your customers to another site, and fast.
So let’s look at the three biggest performance mistakes many developers make when they create a website and some simple ways to fix them.
Identify your audience. When developing a website, many organizations fail to identify who their audience is and where they are located. This is important for sales and marketing purposes, but also for identifying which of the many available architectures, platforms, and technologies can best handle that anticipated traffic. As a general rule, the farther away from something you are, the higher the probability you will experience latency or other performance issues. So before starting development, test various architectures to see which ones best meet the parameters of your target audience. If your audience is scattered geographically, consider a CDN to localize delivery of content and alleviate some of the issues that can come with distance.
Avoid the quick fix. One of the most common development issues relates to database performance. Database performance issues are typically the result of misconfiguration or a lack of optimization, and they manifest themselves as web delays or slowdowns. To keep on track with tight production schedules, organizations often don’t take the time to understand the root causes of these issues. Instead they attempt a quick fix, simply throwing more bandwidth, memory, or servers at the problem. This is a costly and incomplete remedy for an issue that will likely arise again if not dealt with appropriately from the start. Instead, developers should look to enhance site speed through caching, CDN deployment, or image optimization.
Test early, test often. Often web development teams wait until post-production to test a website’s performance, when the finishing touches have already been applied. But what if your testing reveals weaknesses in your site’s performance or architecture? Will you be prepared to go to your boss (who is anticipating the site to launch at any time now) and break the news that a serious fix is in order? That an error overlooked since the early stages of development is threatening to push your website launch past deadline and over budget? And will your organization be willing to make these concessions, or will it choose (or be forced) to forge ahead with a vulnerable site just to launch on time?
Performance issues uncovered this late in the game will be more difficult, time consuming, and costly to resolve than if you had caught them early on. And if you choose not to resolve them you risk a critical website malfunction and the lost business, customers, and bad press that come with it.
Performance testing should be strategically budgeted and accounted for at various stages of the development process, not regarded as just another check in the block, a formality to be completed before rolling out your site. Before development even begins, you should set benchmarks for how many concurrent users you want the site to be able to serve and what its traffic limits will be. Then, periodically throughout the development cycle, test your site’s ability to meet those goals, and optimize web performance.
By no means are these the only mistakes or pitfalls an organization can run into when launching a new website. What other web development or performance problems have you run into?

Monday, September 24, 2012

Behind the scene when Surfing the Web

Have you ever thought about what happens when you surf the web? It’s not as simple as it seems:

    1.    You type an URL into address bar in your preferred browser.

    2.    The browser parses the URL to find the protocol, host, port, and path.

    3.    It forms a HTTP request (that was most likely the protocol)

    4.    To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host

    5.    Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)

    6.    When a connection is open, the HTTP request is sent to the host

    7.    The host forwards the request to the server software (most often Apache) configured to listen on the specified port

    8.    The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)

    9.    The plugin gets access to the full request, and starts to prepare a HTTP response.

    10.    To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request

    11.    Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).

    12.    The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.

    13.    The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response

    14.    A DOM tree is built out of the broken HTML

    15.    New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.

    16.    Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree

    17.    Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly

    18.    The browser renders the page on the screen according to the DOM tree and the style information for each node

    19.    You see the page on the screen

Thursday, September 13, 2012

Tips for ensuring great performance and Customer Experience of your Website.


Better, faster web experiences result in higher conversion rates, greater customer satisfaction and an edge over the competition. Monitoring users on your website allows you to find out how fast a website loads and how well it performs for your customers. Websites are rarely accessed in perfect conditions or from ideal circumstances; there are many variables, from platform and browser version through to connection quality and physical location. End user experience monitoring allows businesses to have visibility of the way real users with different localities, experience a website. Here’s a quick overview of what to consider:

1. Understand why you are doing it
Why do you need good performance on your website? Poor performance results in lost revenues, brand damage, increased support calls, higher costs, and forces expensive tactical decision making. Today’s internet users are not patient. In fact, 57% of people will abandon a site after a 3 second wait for a page to load; 80% of these people will not return, and of those people, almost half will go on to tell others of their negative experience. Users also perceive load times to be slower than they actually are, and increasingly slower when recounting the experience to others. In short, bad performance and slow site speed not only directly affects your bottom line; it can actually drive your customers away to your competitors – often for good.

2. Know what good performance looks like
To achieve good performance, you need to know how to define it. A customer is happy when a site performs to their expectations. How fast are your competitors’ websites? Where are you in terms of your industry’s average? What level of performance is realistic and affordable for you? Consider these points from the start of development and before you start to measure performance.

3. Find the right tools for the job
There are many performance monitoring tools out there that work in different ways and deliver different benefits. Know what’s out there, what you want to get out of your monitoring, and pick your tools accordingly. Consider a combination of solutions and make sure your team knows how the get the most out of each. It’s best to ask for guidance from an expert, as a lot of time could be spent looking over all the options available.

4. Understand normality
By analysing your website and knowing what is “normal”, you will understand your site better and will be able to make better recommendations to improve it. What does a “normal day” look like? If you don’t know this, you don’t know what your measurements really imply or what the appropriate response to these metrics could be. For example, if you have a cut off time for orders, it might be normal to see more visitors and slower pages just before this time each day, whereas a spike of slow page load times at a period where there is not usually a lot of visitors would warrant closer inspection.

5. Anticipate trends
You can’t directly influence the behaviour of your customers, but you can anticipate what they are likely to do based on watching current trends, acting accordingly and staying ahead of the competition. This could mean any number of customer behaviours, from the type of devices they are using (such as mobile, desktops, tablets), the time of day they are accessing certain areas of your site, or increasing expectations around the speed of websites. This can be done through investigation of your website’s analytics or from the advisement of industry leaders and experts.

6. Stay close to the end user
While you must monitor performance from the backbone of your system, it’s also vitally important to make sure your end users are getting the best possible experience with your website. It always makes sense to take on your customers’ viewpoint to make sure they are getting the service you are aiming to deliver. Make sure you use the right tools for this job and have good visibility of your users, wherever they may be and however they might be accessing your site.

7. Measure all components
As well as measuring the parts of your site you have control over, you must also understand the effect of external (third party) elements have on your site. This could be social plugins like Facebook and Twitter buttonsor any content hosted externally. You may not have direct control over them, but if they’re on your site, you need to know all about how they are affecting the end user experience.

8. Serve key customer groups
With the huge variety of devices, browsers, browser versions, locations and connections that could be used by your potential end users, it’s virtually impossible to account for everyone equally when optimising your website. Know who your key customer groups are and make sure they are the ones who are driving your business decisions. Crucially, continue to monitor who these people are and, again, where the trends are heading to keep your business focused.

9. Set iterative goals
Assuming you understand where your customers are, how they are accessing your site, and how well your competitors are performing, you will be able to set manageable goals leading to increased commercial success for your business. Know what’s possible and how to go about making those things happen.

10. Make Performance holistic
Performance is not just about technicians and monitoring, it is driven by the line of business. Good performance, considered early on in a project, allows you to take your strategy to the market; a holistic view of your performance should bridge gaps between teams and departments, aligning business and technical goals. This goes all the way from developers and QA through to marketing and C level.