jetNEXUS

FREE CDN? Host your jQuery on Google

2012-01-10T16:34:00.000Z

Why aren’t we all taking advantage of Google’s generosity, by hosting our jQuery on their fast Content Delivery Network?

3 reasons why I think we should!

1) Content Delivery Networks are expensive but fast! Users should get content served to them from a nearer / faster location.

2) Many websites use jQuery. If we all hosted our jQuery on Google then there is a reasonable likelihood that the end user will already have it locally, thus saving them having to download it again, therefore speeding up the page load time!

3) If users download their content from Google then it does not contribute towards their connection count. Most browsers will only open 2-6 connections to a specific host. After that it will have to re-use those connections. Given that most websites contain lots of objects, each connection may need to be used 20 times! If you can offload the jQuery onto a different host then you can download it in parallel, thus saving on your precious connections and accelerating the process for a speedy end user experience! J

How Do I Host my jQuery on Google?

Two options:

Visit: http://code.google.com/apis/libraries/devguide.html#jquery and change your code to use the Google link.

Use jetNEXUS ALB-X. Simply drag and drop the “Offload jquery to Google” rule from the flightPATH catalogue to apply.

A Nice Trick

What happens if Google is not accessible or accessed via an intranet with no external connection I hear you ask?

Try this little trick: (it’s an example so you need to change the source location!)

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>

<script>window.jQuery || document.write('<script src="http://www.jetnexus.com/js/jquery-1.6.4.min.js">\x3C/script>')</script>

Application Delivery Controllers - Real Business Uses

2011-08-15T12:51:00.000+01:00

Also known as traffic shaping or packet shaping, traffic manipulation is one of the advanced Layer7 features that differentiates next generation Application Delivery Controllers from old, simple load balancers.

Increasingly, organisations are subscribing to the advantages of greater control and intelligence in their service delivery. As we discussed in our last blog, users can implement traffic management rules to automate a myriad of everyday routing tasks from simple HTTP redirects to much more granular and complex rules unique to individual SOA’s. Great I hear you say, a feature that can control network traffic in order to optimize network performance, accelerate applications, and deliver personalised service levels!

More control ultimately leads to more productivity, efficiency and flexibility, doesn’t it? This blog discusses implementation scenarios for the jetNEXUS flightPATH routing engine, reflecting on the business benefits and the powerful implications of such. Is there really such a thing as too much control?

Controlling Spiders
Search engine spiders, robots, Googlebots, however you like to refer to them, can be quite the virtual pest for online businesses. Whilst we appreciate that they are vital to SEO, Googlebots utilise valuable bandwidth and add load to servers when they make multiple requests, crawl sites and test forms. Importantly, content found by the bots on your website is indexed, affecting search engine ranking and quality scoring. flightPATH gives users the ability to block or control spiders, redirecting them to dedicated servers, separate from where ‘real’ users are accessing the site to avoid network slowdowns.

Sound good? Better still, flightPATH can detect Googlebots and automatically serve them different content that has been specifically designed with them in mind. So you could have pages with very clean code or less dynamic data so that they load faster. Or if you are a bit naughty you could serve Googlebots pages that are enriched with heavily searched for keywords. An increase in relevant keywords helps to boost your site’s ranking in organic search results and give you that competitive edge. Just another possibility borne out of the power of fligthPATH!

Prioritising Premium Customers for E-commerce
Many E-commerce organisations have a set of loyal users and clients that frequently revisit their site. flightPATH can log and segment these premium users based on user ID or Cookie type and set rules to service their requests in a different way. It may be that you want to serve alternative content to repeat visitors or provision them with a premium service for a faster online experience. Either way, this feature gives clients greater control in their service delivery, detecting users and managing their online experience.

Traffic Shaping to Control Spam
*Play Jaws Theme Tune here* :) ‘botnets’ are the primary source of spam today. Typically ‘botnets’ are PCs with broadband connections that have been infected with malware, allowing a remote user to control its behaviour. Zombie computers grow uncontrollably each day, primarily because domestic users have a more relaxed approach to security and anti-virus!

jetNEXUS ALB-X can help to reduce the threats from spammers, ensuring that only a manageable quantity of email traffic flows into the mail server. This makes attempts to flood the servers and bring them down more difficult.

These are just a couple of ways in which you can use this powerful routing engine. With a catalogue of pre-built rules designed to satisfy the typical requirements of the vast majority of users including block unwanted requests, rewrite user requests and fix broken URLs, it has never been easier to take control of your network.

So for which ever scenario you need to manipulate traffic you can use flightPATH – but remember it’s a powerful tool, use it wisely!

Download a free trial and test it out for yourselves: jetNEXUS ALB-X 2.0 (with flightPATH)

Architectural Changes to Microsoft Exchange 2010 Makes Load Balancing Even More Important for Your Organization.

2011-07-19T15:13:00.000+01:00

As an Application Delivery Control Technology vendor, jetNEXUS all too well understands the vital role that business applications play in maintaining a productive and effective working organisation.

Communication applications in particular, such as Microsoft Exchange 2010 sit at the heart of corporate communication, making it part of the essential life blood of most business organisations.

As such, it is absolutely imperative that these business critical applications run seamlessly with superb performance and robust security.

Advanced Load Balancers, or Application Delivery Controllers, as termed by Gartner, play a pivotal role in ensuring this. Those unfamiliar with the terminology around this technology may want to read one of our archived blogs: An ADC is not just a Load Balancer with more features.

Application Delivery Controllers possess several key features that work within a network to maintain application availability and fluency. When discussing load balancing in conjunction with Microsoft Exchange 2010, an ADC solution would serve two main purposes:

1. It will reduce the impact of a single Client Access server failure within any one of your active directory sites.
2. It will ensure that the load on Client Access Servers and the Hub transport computers is distributed evenly.

In earlier versions of Microsoft Exchange 2010, Outlook would connect directly to the server hosting the relevant Mailbox or refer directly to a global catalogue server. Microsoft have since implemented architectural changes so that these connections are handled by a Client Access server role. In order to achieve fault tolerance and for better management, both external and internal connections should be load balanced across the array of the Client Access servers in any deployment.

Further to this, Microsoft recommend that a load balanced array of Client Access Servers be used for each Active Directory site and for each version of Exchange. It is not possible to share one load balanced array of Client Access Servers.

But what do architectural changes mean to your deployment? In response to these operational changes, network managers and system architects will need to reconfigure their Load Balancers in accordance with Microsoft recommendations to ensure that application delivery remains uninterrupted.

Microsoft suggest that “Before you configure load balancing, you should understand the loads that are placed on an Exchange 2010 Client Access server.” Microsoft Tech Net
We have taken the liberty to list a few pointers for consideration when configuring your Load Balancers for Exchange 2010 Client Access Server:

• Different types of traffic that the Exchange 2010 Client Access server receives
• Understanding the key technologies and the options of load balancing solutions
• Understanding Affinity
• Reverse Proxy Solutions
• How to use existing Cookies or HTTP Headers

There are many more to add to this list but we don’t want to scare you off! This may seem like a long and laborious task but when taking into consideration the integral role that Exchange 2010 plays in business communication, it is not only worthwhile but imperative to ensure it runs with optimised performance and high availability.

You will be relieved to know that the jetNEXUS ALB-X Application Delivery Controller is specifically developed and tested to operate within Microsoft Exchange 2010 environments. The ALB-X 2.0 has successfully completed solution testing, meeting all Exchange Server 2010 requirements and features on the Microsoft Technet list of qualified suppliers. :)

For more information please visit our jetNEXUS and Microsoft Exchange 2010 brief or contact info@jetnexus.com to understand how jetNEXUS can help you manage your Exchange 2010 deployment.

Save yourself the hassle, download a trial version of the jetNEXUS ALB-X here today.

Traffic Manipulation And ALB-X 2.0

2011-06-27T11:06:00.000+01:00

As with most networking solutions, over time load balancers have become increasingly sophisticated and capable thanks to the ever developing technology driving them. By way of reinforcing the advances that some load balancers have made, Gartner have introduced the term Application Delivery Controllers to mark a distinction between older, simple load balancers and more advanced solutions that offer greater functionality, application control and power. These next generation solutions become actively involved in the delivery of the application, providing sophisticated capabilities and true application fluency.

Gone are the days when a load balancer was simply required to blindly direct traffic to a designated server for high availability only. Today clients need more control and granularity in the management of their application environments. Optimising the speed and performance of the application itself is a crucial requirement. As I’m sure you are aware, we at jetNEXUS like to think of ourselves as innovators in this market space, developing and delivering the features that make the biggest difference to end user experience. Following this trend we are very proud to introduce to you flightPATH!

flightPATH is a powerful Layer 7 routing engine that helps to firmly place the jetNEXUS Accelerating Load Balancer Extreme product in the ADC camp. flightPATH can detect and manipulate application traffic, providing network managers with a level of control, intelligence and resilience in service delivery.

With flightPATH users can create and implement bespoke application rules. This can be as basic as removing server headers so that potential intruders remain unaware of your operating system through to more intricate scripting including the direction of search engine crawlers to dedicated servers to avoid site slow down. We like to think that with flightPATH you are limited only by imagination!

Due to the configurable nature of flightPATH, rule options are infinite but some common uses are to:
• Block Unwanted Requests
• Rewrite User Requests
• Control Spiders
• Fix Broken URLS
• Provide Application Level Security

Ok so here is the shameless product pitch! The ALB-X 2.0 ensures optimal resource utilization, maximum throughput and minimal response time across the network. With a new user friendly GUI and straight forward CLI, the jetNEXUS ALB-X offers ease of management, making it one of the most competent Application Delivery Controllers in its market.

For maximum flexibility the jetNEXUS ALB-X 2.0 is available as hardware, software or a virtual appliance. Feel free to request a trial here: www.jetnexus.com

Is your Online Shop PCI Compliant? | PCI DSS and ALB-X 2.0

2011-06-10T09:22:00.000+01:00

We are in the midst of a ‘shop online’ trend explosion. Internet retailers are continuously reinventing how we [customers] shop online. Whether it’s via our mobile devices, PCs, or in-store kiosks, there is a myriad of new options for transacting business that carry both positive and negative implications for the consumer and the retailers themselves.

One of the internet’s biggest issues is security; as an e-retailer you need to ensure that your online shop is safe and secure throughout the payment process, handling sensitive information efficiently and securely.

This brings me on to this week’s blog topic; PCI Data Security Standards (PCI DSS). In laymen’s terms this is the framework and set of regulations compiled by the PCI Security Standards Council within which online merchants must operate in order to be compliant. It demands that merchants develop a tenacious online card payment system, incorporating processes for prevention, detection and appropriate responses to security incidents.

Why Should I Comply?

As a merchant, you are probably wondering why you need to comply with the PCI Security Standards. These strict guidelines seem like a lot of effort, especially to small organisations. However Payment Card Security is becoming increasingly important and implementing precautionary measures could be potentially business saving.

Some of the reasons why (as highlighted by the PCI Compliance Council*) it would benefit to comply with the PCI Security Standards are:

Compliance with the PCI DSS means that your systems are secure, and customers can trust you with their sensitive payment card information:

• Trust means your customers have confidence in doing business with you.
• Confident customers are more likely to be repeat customers, and to recommend you to others.

Compliance improves your reputation with acquirers and payment brands -- the partners you need in order to do business.

Compliance is an ongoing process, not a one-time event. It helps prevent security breaches and theft of payment card data, not just today, but in the future:

• As data compromise becomes ever more sophisticated, it becomes ever more difficult for an individual merchant to stay ahead of the threats.
• The PCI Security Standards Council is constantly working to monitor threats and improve the industry’s means of dealing with them, through enhancements to PCI Security Standards and by the training of security professionals.
• When you stay compliant, you are part of the solution – a united, global response to fighting payment card data compromise.

Compliance has indirect benefits as well:

• Through your efforts to comply with PCI Security Standards, you’ll likely be better prepared to comply with other regulations as they come along, such as HIPAA, SOX, etc.
• You’ll have a basis for a corporate security strategy.
• You will likely identify ways to improve the efficiency of your IT infrastructure.

*https://www.pcisecuritystandards.org/security_standards/why_comply.php

Be PCI DSS Compliant ALB-X 2.0

Enterprises often go through the time consuming and costly process of deploying an application firewall to ensure that their web platform is PCI Compliant. We at jetNEXUS even have a great solution called the jetNEXUS Application firewall. However, this is not the only option for online merchants. In fact, the additional cost of purchasing and implementing a unique, standalone application firewall can be avoided with the jetNEXUS ALB-X 2.0 Application Delivery Controller.

The jetNEXUS ALB-X has a powerful rule engine called flightPATH that works in the background, FlightPATH can be configured to help with PCI compliance. Unique traffic rules can be implemented, offering clients greater control and intelligence in managing their service delivery and protecting against top application threats as summarised by the Open Web Application security project (OWASP)*.

*https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

This type of granular control in traffic management and application delivery is especially crucial when managing online applications and ecommerce sites. flightPATH is highly configurable, very powerful and yet easy to use. In addition to this, the jetNEXUS ALB-X is designed to dramatically improve the performance, reliability and manageability of application delivery. So whilst accelerating your applications may not have been the initial reason for looking at jetNEXUS, it is certainly a nice extra benefit!

Check out flightPATH here: http://www.jetnexus.com/flightpath.html

Date for Your Diaries: jetNEXUS Reveal New ALB-X 2.0 Release Date

2011-03-04T14:09:00.000Z

As promised, jetNEXUS has announced the launch date for the new and improved version of the jetNEXUS ALB-X.

You will be able to get your hands on the eagerly awaited release of ALB-X 2.0 in April 2011.

Our dev team has been working hard to deliver some powerful new features for the ALB-X which will dramatically improve the performance, reliability and manageability of application delivery environments.

So what goodies can you expect to find in the new release?

o Flightpath: our new powerful layer7 rules and routing engine
o Multi Networks which add virtually unlimited networks and network interfaces
o Significant performance improvement x4 and x2 for HTTPS on existing hardware and VM
o FTP support for both Active and Passive
o Configurable Email alert
o Configurable application cookie session persistence
o Real-time Ajax server status display
o Support made easier with optional dial home
o SOAP API for external communication

For maximum flexibility, the ALB-X is available as a hardware, virtual or software platform. We don’t like to brag but we are really proud of this new release – it’s feature rich, powerful and will definitely get all you tech savvy fellows (ok geeks!) firing to eval!

We hate to leave you in wild anticipation, so during the run up to the release, we will let you have a sneaky peak at tech specs, performance stats and GUI screenshots – stay tuned!

Alert for eRetailers!

2010-11-24T17:19:00.001Z

Do you know how and why to prepare for Manic Monday?

As we enter the run up towards Christmas, November 29th has been dubbed “Manic Monday” following forecasts that UK online sales are set to surge.
Manic Monday will follow Black Friday (26th November), a date which has seen sales figures rise consecutively year on year in the US. However it now looks as though the increase in sales expected on the 29th will see consumers spending over half a billion in one day! Internet sales are predicted to hit £22m an hour on the busiest online shopping day.
With websites predicted to be inundated by multitudes of Christmas shoppers, e-Commerce sites need to provision their delivery network for an increase in demand for their services.
The success of e-retail sites lies in ensuring that customers have an outstanding end-user experience. There are a number of factors which contribute to building a loyal customer base, and delivering a highly available site with excellent response times is definitely a good start. These have an immediate impact on user experience.
Websites have to be highly resilient and continuously available to cope with peaks in traffic, Black Friday and Manic Monday are key examples of such times. Everyone hates slow websites, so zero downtime is a must. Consumers are spoilt for choice and they simply refuse to wait around for your web pages to take time in loading. So making your site fast and responsive is a must or it could end up costing you dearly both economically and in terms of brand reputation.
So how do you ensure that you deliver a speedy, uninterrupted service for browsers?

Enter the ADC Application Delivery controller.

The Application Delivery Controller is a network device designed to sit between your web servers and your customers. Its aim is to speed up the delivery of the application so that your end users have an outstanding experience when shopping with you. Faster sites see an improvement in Browse to Buy ratio, as such you see an improvement in revenue!

Because your pages are being served faster, in a fixed amount of time you can serve more of them. This means you get a significant increase in capacity WITHOUT buying more webservers or other network equipment.

jetNEXUS Technology belongs in the ADC market: www.jetNEXUS.com

An ADC is not just a Load Balancer with more features

2010-10-04T14:09:00.000+01:00

We have been developing Application delivery devices for some time now and have continually been trying to convince network managers to separate Application delivery from Packet delivery.

Many network engineers seem to struggle with this concept. The old perception is that ADC’s are like load balancers with an upgrade. They tend to look like switches, containing loads of network sockets with cat 5 hanging out all over the place; basically an evolved switch.

Whilst it may be true that the modern Application Delivery Controller does indeed contain much of the functionality of a traditional load balancer, it is however architecturally different. Most modern Application Delivery Controllers have high speed networking ports that connect to switches. They are more like proxies than intelligent switches.

Application Delivery Controllers are not switches or routers. Design your packet delivery network then build your application delivery network on top of it.

Let the network take care of the packet delivery and the ADC take care of the application delivery.

Connection pooling

2010-08-04T16:17:00.000+01:00

What is connection pooling and what does it do?

In order to answer this question we need to look a little into why it’s relevant (This is not a politicians answer, honest!)

This feature, although having been around for many years originated in the days of the main frame.

Recently, since load balancing manufacturers have been pushing it as a feature, interest in connection pooling has increased.

As load balancing is what I know slightly more about, let’s start there. The first generation load balancer used a direct server return method meaning that the user request would first hit the virtual IP of the load balancer and then it would get routed on to a server. The server would respond directly back to the user i.e. miss out the load balancer. This was fine in the “old” days, indeed it is still being use by some of the more simplistic layer4 devices today. However, it has some major drawbacks.

1) How do you know how busy a server is?
i.e. You know how many requests you sent to it but you don’t know how quickly they were executed. This major problem has tried to be worked around with some rather crude solutions:

The guess - “Weighted load balancing”
You take a look at the box and estimate how much better (or worse) it is in relation to the other servers. I think that my new Dell is twice the power of my old one etc - you get the idea. The big problem, apart from the potentially massive inaccuracy of the initial guess, is the usage. For example, User A could run a massive report that takes ages, where as User B could request a small image thus creating different load requirements.

Run a client application
The idea of this is that you have to install some software on the servers. The load balancer will make a periodic request to this software to gather information such as number of connections or CPU utilisation. One thing to note is that many people use CPU but that does not always work. A server that is running with a lot of CPU does not always mean its going to be the slowest to serve your request.

2) The other drawback is that you can’t do anything with the response of the connection. Every user will make a new connection to the webserver.

So what’s changed?

Most of the newer load balancers and ADC Application Delivery Controllers now use a proxy based approach. This means that both the requests and the responses pass through the load balancer.

The web servers only ever talk to the load balancer. Well they may talk to other internal servers directly but as far as the end user conversation is concerned, all traffic goes through the load balancer.

This obviously addresses the issues highlighted above but also allows you to manage the way that connections are passed to the servers.

So managing the connections to the servers has the obvious advantage that we know exactly how busy they are and how quickly they are able to process requests. However in addition to this you can optimise the connection as you have control of both ends.

On one side you have the load balancer and on the other you have the web servers, as such it seems pointless to initialise and destroy a TCP connection for every request.

Connection pooling allows the load balancer to initialise a number of connections to the servers and pool them for use with multiple end users. This reduces the effect of TCP slow start and also helps to reduce load at the networking processing level.

The other advantage of this proxy type approach is the simple abstraction between the client and server connections. A server sitting on a high speed LAN can have a very high speed conversation with the load balancer. The data can be sent and the connection left free to serve another request. The load balancer can then buffer the response and send it to the client over the much slower WAN.

This approach can really help busy web servers, especially if client connections are filling up on the server due to slow links and/or using methods such as HTTP keep alive.

Keep an eye out for my next blog....

Web Content Caching Explained

2010-07-19T16:58:00.000+01:00

The minefield that is web content caching can be confusing and complicated!

It’s one of those features that really sits between the network and the application. In many businesses this grey area has no real ownership and as such, mistakes are often made. I want to take a little time to explore and hopefully simplify this complex area.

So firstly one must address the question of what is a content cache and why bother using it?

A content cache is a piece of software or an appliance designed to sit in front of the application server. Its job is to intercept certain requests and respond on behalf of the application thus reducing the number of hits sent to the backend severs.

Typically the requests that are intercepted have already been seen before, so the cache will store responses to these requests and if it intercepts a similar request it can respond in the same way.

A simple example would be an image cache. The client (ie browser) would make a response to the web server for an image. The first time this image is requested the cache will have to get it from the web server however for subsequent requests it will simply serve it directly.

The idea is that the web server will have a lot less work to do as the cache can serve a lot of the content. The implications of this really depend on the exact setup, application and content however they typically fit into the following:

1. Reduce load on the web/application servers – Save on application server hardware and licensing costs.

2. Reduce load on middleware and Backed DB systems.

3. Serve the content faster – Caches can be very fast!

4. Cache the content closer to your users. This is an interesting one. The cache does not always have to be at the same location as the rest of the system. You could use a good cache to build your own simple content distribution system to ensure your users get the content from a source as close to them as possible.

Who said that a CDN (Content Distribution Network) has to cost the earth!

OK so you have decided that you may want to use a cache, so what next? The biggest problem with content caching is simply deciding what and for how long you want to cache content for. It sounds simple but failure to do this in the past has given many a network manager / application owner a genuine fear of caching. You don’t want one user getting the account balance of the previous user!

However to really make the most of the capabilities that a modern content cache can offer we must understand the full picture. The application behaviour, the cache setup and the browser behaviour.
Let us take a quick look at typically what happens when an image is requested from a web server by a browser.

1. The user requests an image to look at.

2. The Cache will notice that it has not seen this request before and therefore will request it from the web server.

3. The web server will get the image and send it back to the cache.
Important. The web server will decide if this image can be cached or not. It will instruct the upstream devices such as the cache and ultimately the client if it should be cached it or not. It does this by using specific HTTP header. (I won’t geek out on this, in this article as it can get overly complex.)

4. Now it gets interesting because the cache will need to decide on which way to go. Does it obey the rules from the web server or does it override it with its own rules? We will discuss this later on.

5. So the image is now sent back to the client and just to complicate things the client will also cache the content and also look out for the cache control header.

So we can see that not only do we have to decide on the application caching rules but also how we want the cache to behave upstream. If we do this right we can even reduce the number of hits reaching the cache and thus network in the first place.

So now we have a rough idea of what is going on, so how do we implement a cache?

A general method is described in “light” detail below.

1. Decide what you want to cache and for how long – So I want to cache all images for 24hours or all *.asp for 2seconds etc. These can get complicated.

2. Be certain you are happy with these rules.

3. Now check again.

4. Configure the cache to remove all cache control headers from the response from the web server. In other words ignore any caching control setup on the webserver – We assume we know how to create more accurate set of rules.

5. Configure the cache with these new rules and also expiry dates/ durations.

6. Configure the cache to add some new cache controls for the Client. Client side cache control is tough as browsers respect these rules with varying degrees of success. This is not really in the scope of this paper but I may revisit it.

7. Document – These rules can be complex and can involve speaking to people in different parts of the business to understand the application, therefore it’s worth documenting this info whilst it is fresh.

8. Test and test again – The more testing the better. Remember part of testing is to manually empty the content cache’s cache but also the client’s too.

That’s it for now folks.
I am writing a follow up on this talking in a little more detail about typical cache settings and also helping to answer questions such as, ‘will a cache be of any help for my application and if so what type of cache should I be looking at?’

At last! Website Performance and page speeds are now relevant to Google page rank.

2010-04-15T17:33:00.000+01:00

No more slow web pages - no more excuses!!

Google has recognised that sites need to deliver excellent end user experience both in terms of content but also performance. The mysterious page rank will now also take into consideration site speed. Given the cost and competitive nature of ad words and SEO optimisation, now there is compelling financial reason to make your site faster.

We all hate web pages that are slow to load but many site owners now believe that we all have high speed broadband connections and that they don’t have to design a site for performance. How wrong they are! The network performance speeds can massively vary as most broadband connections are heavy contended. This means the end user experience of a site can still vary from very fast to frustratingly slow. In addition to this, the average home connection does not have a high tech QOS to ensure that you can do your online banking when little Tommy next door is hammering the line downloading the lasted game!

This new consideration launched by Google signals the beginning of interesting times. Network Managers are now going to have to align their work efforts even closer to the site business owners’ to achieve the mutual goal of speeding up their website.
Maybe discussions about site design and the overhead of delivering large pages with many objects will be jointly had between IT and the Business?

SEO, Sales, Marketing, Development and Infrastructure will all have to work and “compromise” together to achieve performance related objectives.

We are not very forgiving of slow web sites and will typically blame the site that we are visiting for an unsatisfactory experience. Whatever the reason and wherever the fault lies, the end user will leave with a negative perception of the site based on their encounter. It’s not your fault but it is your problem!

Ecommerce site are typically ahead of the curve on site performance as they know that faster sites offer a better user experience and in turn will increase the ‘Browse to Buy’ ratio thus making more money! With the new Google SEO implications, site performance will become increasingly important. Interestingly enough the ROI time of budget spent on optimising site performance will be further reduced.

So what can we do?

Websites are normally slow due to one of more of the reasons below:

The DNS server takes some time to resolve your domain name to your IP.
The Application/ web server is slow to create the web pages (maybe dependencies on backend systems such as databases etc).
The pages are large and take some time be sent to the client.
The code is not efficient for the browser to render.
Any part of the connection between the server and client connection is slow.

Remember the network is only as fast as the slowest link! So it does not matter if you have a high speed server network if you users are accessing your site over a contented ADSL. This is the last mile problem!

We at jetNEXUS have been developing technology to improve site performance for nearly 10 years so are in a pretty good position to help.

So what can jetNEXUS do to help?
The jetNEXUS accelerating load balancer is designed to ensure that web sites and applications are delivered to end users as fast as possible. We have advanced compression technology that will ensure that application delivery is fast even over the last mile. In addition, we help to offload tasks from the web servers so that they have more bandwidth and CPU to create web pages!

Because the pages will be served faster in a fixed amount of time, we can serve more of them, thus increasing capacity. This can almost be thought of as a check out queue at a supermarket. It’s like having superman and Superwoman at the check out J.

Ok so what’s the bottom line – how much faster can my site be with jetNEXUS?
Well it’s not an easy question to generically answer as all sites are different, however we have built a performance predictor tool to try to give you an idea.

PREDICTOR IS GOING LIVE TOMORROW ...... See my next post

This sounds too good to be true! How long does it take to implement jetNEXUS?
jetNEXUS can be implemented very quickly with low risk, It can be installed as a virtual machine or physical server. In addition we typically will offer a try and buy evaluation so you can ensure it delivers what you expect.

Links:

http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

What does Application acceleration mean?

2010-03-19T11:06:00.000Z

Advanced Load balancers have been around for some time, but there still seems to be a lot of confusion over the loosely used term “Application Acceleration” .

Ok, so you have heard the hype and read the sales material, but what does acceleration actually mean in real life? What real benefits can you expect to see and more importantly, what difference will it make for your customers or users?

The four main areas of acceleration are:

• Compression
• Connection Management
• Content Caching
• SSL Acceleration

This first blog (of 4) takes a look at HTTP Compression.

Compression:

Web pages are very compressible. Typically an average web page, whether it is dynamically generated or static content, can be reduced in size by 80-90%. Nearly all browsers can accept the compressed content automatically without the end user having to make any changes; i.e. no end user browser plug-in is required (it is naively supported as part of the HTTP 1.1 protocol definition).

This ability to send compressed HTTP data over the net has been around for years but it has still not been fully exploited and in many cases it can be misunderstood. This is partly because of the CPU power required to compress dynamic web pages and the unpredictable compatibility with early browsers.

Typically compression is used to compress the text based parts on a page i.e. java script, HTML, XML, CSS etc. Images such as JPG, PNG etc are already compressed; as such they see very little benefit from additional compression.
However, it is dangerous to assume that compression will have little positive effect if your site is image rich. Firstly, the images can't be displayed until the base page arrives at the client, so it follows that the quicker you can deliver the base page, the faster you can request the objects and the quicker the page can load.
Secondly, web sites and applications generally have a consistent look and feel. As such the effect of client side caching is significant. This means that most of the data that will be sent is compressible as most of the images are already saved at the client side.

Compression in real life.

This screen shot was taken from the GUI of a jetNEXUS ALB-X in action at an e-commerce customer's site. (You should see similar levels of compression with most of the top end vendors). The “Content Compression to Date” is 85%. This means that out of the content that can be compressed, the average level of compression is 85%. Only 164GB out of the 1126GB was sent.

The “Overall Compression to Date” is 81%. This number should equate to your bandwidth usage, assuming that all your traffic is from the ALB-X. In this example most of the traffic is compressible, as such the overall reduction in bandwidth is 81%. 1.17TB would have been sent but only 0.25Tb was actually sent.

Optimization rating ***** Compression will offer the easiest and most effective way to speed up your web application, especially if the distance between you and your users is great or you are working with a slow WAN connection. In addition, because you will be serving your users faster in a fixed amount of time, you can serve more of them and therefore experience a significant capacity increase - especially during peak periods where it’s needed most

New Hire

2010-03-12T16:58:00.000Z

One of the elements of my role that I find to be the most frustrating and ‘time burning’ is staff recruitment. In a growing business, this is continuing to be more and more of a challenge. Although the candidate pool has swelled in the current economic situation, this is not necessarily a good thing as it has made it more of a challenge to find the best candidates. We have always had an attitude of few but greater people and extracting the greatness from diluted mass of so called IT professional has not been easy. That said we have recently hired Jim to join our development team and he is already producing some great work after only a couple of weeks! 1 down 3 to go ! – Back to interviewing ;-)

Layer 7 and 4 load balancing

2008-08-26T22:08:00.000+01:00

Layer 7 and layer 4 load balancing. Layer 7 is the application layer and layer 4 is the transport layer or the OSI stack. Basically the higher up the stack you go the more processing power is required to read the data and make routing decisions. The big advantage is that you have more useful data on which to make these decisions. At the application layer you may have information such as the content of a web page perhaps the logged in user, the referrer etc.

At the transport layer you have very little information on which to make routing decisions. The source IP in many cases is fine, However many application particularly web apps require greater flexibility. Clearly layer 7 is more flexible but its more complex and more CPU intensive. As computing power has increased high performance layer 7 processing has been more accessible on cheaper hardware platforms without additional dedicated hardware. Nowadays devices can load balance over 2gig on a standard x86 platform. I believe this is why we have seen a significant increase in the number of layer 7 devices.

The next development of the Layer 7 load balancer is the evolution into the Application Delivery Controller ADC.

Advantages of Layer 4. Cheap, fast, simple to configure
Disadvantages of Layer 4. Inflexible, Struggle with persistence, No understanding of the application