|
| DevCentral > Weblogs > - Two Different Socks
|
application acceleration
There are 37 entries for the tag application acceleration
 |
Like peanut-butter and jelly, cloud computing and application acceleration are just better together. Ann Bednarz of Network World waxes predictive regarding 2010 trends in application delivery and WAN optimization in WAN optimization in 2010. One of the interesting tidbits she offers from research firm Gartner is growth in the application acceleration market: Second, the research firm is predicting a return to modest growth for the application acceleration market in 2010. Gartner is forecasting a compound annual growth rate of 12.22%, with 2014 revenue of $4.27 billion. This, when viewed alongside...
posted @ Thursday, December 17, 2009 3:21 AM |
|
|
Sharing is core to a successful cloud implementation but not something every organization does well. How do you encourage business stakeholders to play well with others? In most definitions of “cloud computing” there lies a central, key component: shared resources. It is the sharing of resources, in fact, through which many of the benefits of reduced operating expenses are supposed to be achieved. It is the sharing of resources – or perceived inability to share resources – that confounds some folks when discussing private cloud, although there are several ways in which sharing of resources can...
posted @ Friday, September 11, 2009 4:01 AM |
|
|
Why do application delivery vendors talk about both? Aren’t they the same thing? In general, acceleration implies that something will be done to the application: caching, compression, etc… The actual behavior of the application is changed such that the client may need to participate in the acceleration. Acceleration is technically speaking disruptive in the sense that it requires participation of client, intermediary, and often the server. This generally takes a form that leverages existing standards, a la caching, such that no changes need be made to clients or servers, but the behavior of the application and its...
posted @ Thursday, August 20, 2009 6:00 AM |
|
|
Understanding the impact of compression on server resources and application performance While doing some research on a related topic, I ran across this question and thought “that deserves an answer” because it certainly seems like a no-brainer. If you want to decrease bandwidth – which subsequently decreases response time and improves application performance – turn on compression. After all, a large portion of web site traffic is text-based: CSS, JavaScript, HTML, RSS feeds, which means it will greatly benefit from compression. Typical GZIP compression affords at least a 3:1 reduction in size, with hardware-assisted compression yielding an average...
posted @ Wednesday, May 27, 2009 3:50 AM |
|
|
The acceleration technique known as pre-fetching went the way of the do-do bird sometime around 2002. But perhaps it should be resurrected, just in a different place and with a slightly different focus. A SHORT HISTORY OF ACCELERATION TECHNIQUES Most modern acceleration techniques revolve around two things: decreasing the amount of data to be transferred (compression, optimization of the client-side cache) or twiddling with protocols (TCP, HTTP) and their associated behaviors to improve the overall speed at which a client and server communicate. Back in the early days of application acceleration most technologies were...
posted @ Tuesday, April 14, 2009 3:01 AM |
|
|
Increasingly WAN optimization solutions are adopting the application acceleration moniker, implying a focus that just does not exist. WAN optimization solutions are designed to improve the performance of the network, not applications, and while the former does beget improvements of the latter, true application acceleration solutions offer greater opportunity for improving efficiency and end-user experience as well as aiding in consolidation efforts that result in a reduction in operating and capital expenditure costs. WAN Optimization solutions are, as their title implies, focused on the WAN; on the network. It is their task to improve the utilization of bandwidth,...
posted @ Wednesday, March 04, 2009 3:29 AM |
|
|
It has been suggested that the use of application acceleration solutions as a means to improve application performance would result in programmers writing less efficient code. In a comment on “The House that Load Balancing Built” a reader replies: Not only will it cause the application to grow in cost and complexity, it's teaching new and old programmers to not write efficient code and rely on other products and services on [sic] thier behalf. I.E. Why write security into the app, when the ADC can do that for me. Why write code that...
posted @ Tuesday, February 17, 2009 3:41 AM |
|
|
When an application is deployed into a high-availability production environment there are a number of interesting infrastructure related things need to happen. The application delivery controller (ADC) needs to be configured, DNS entries updated, storage allocated, and all the other associated network infrastructure must be prepared to handle the delivery of the new application. We have a BIG-IP. Do I have to talk to the network guys?? ...
posted @ Tuesday, December 16, 2008 5:55 AM |
|
|
One of the most affordable options for small and medium businesses in terms of Internet connectivity is business-class service from cable and telco providers like Time Warner Cable, Cox, Verizon, and AT&T. Unfortunately, the definition of "business-class" is ill-suited to businesses that host their own web applications or mail servers. If you've ever looked into business class service, you'll notice that like residential services, they are only truly cost effective if you don't really care about upload speed. For example, Verizon has a promotional offer that promises download speeds up to 7.1Mbps, but limits upload speeds to 768Kbps....
posted @ Friday, December 12, 2008 3:46 AM |
|
|
Michael Vizard over at eWEEK makes an interesting prediction about the future of application acceleration: "Some day the whole concept of application acceleration will be baked into the core routers and switches we have in place." I disagree. Routers and switches are packet-based. They focus on getting a single packet from here to there based on layer 2/3 information. Application acceleration solutions require action higher in the stack, usually layer 4 through 7; they are flow or connection based, and are often specific to the application (think CIFS, SAMBA, HTTP, etc..). The information necessary for application acceleration solutions...
posted @ Tuesday, November 18, 2008 3:38 AM |
|
|
As a general rule, we spend far more time worrying about external appearances than we do internal. We are more concerned with our external web applications and how they look - and perform - than we are likely to regarding our intranet or internal only applications. This blog post was interesting in that rather than encouraging folks to optimize web sites and improve end-user response time for web applications for the sake of the user experience, it focused on the relationship between page load time and impact on Google AdWords quality scores. Which is a bit different than...
posted @ Thursday, November 13, 2008 3:36 AM |
|
|
AJAX. SOA. Social network API integration. What is TCP Multiplexing? All of aforementioned technologies have one thing in common. Okay, they have more than that in common, but for the purposes of this discussion there's one very TCP multiplexing is a technique used primarily by load balancers and application delivery controllers (but also by some stand-alone web application acceleration solutions) that...
posted @ Tuesday, October 14, 2008 5:10 AM |
|
|
Lately I've been seeing quite a few links to a white paper popping up in my alerts and feed-reader. Regardless of who's linking to it, it generally reads as promising to reveal some grand secret about how web application acceleration is an epic failure. I finally gave in and clicked on a link and ended up directed to download a white-paper, the description for which essentially distilled "web application acceleration" down to "caching". And then promised to tell me why caching wasn't a good way to accelerate web applications. I didn't download the white paper primarily because equating...
posted @ Friday, October 10, 2008 3:17 AM |
|
|
Developers have an almost supernatural ability to workaround restrictions, even though some of the restrictions on building applications delivered via the web have been akin to a kryptonite. Like Superman fighting through the debilitating effects of the imaginary mineral, they've gotten around those restrictions by coming up with ways to implement functionality and improve the behavior of browsers and thus web applications anyway. The first greatest hack was giving HTTP state. The second? Cookie-based persistence. The third? The CNAME trick. THE PROBLEM The reason the "CNAME trick" came about was a limitation on browser connections...
posted @ Monday, September 08, 2008 4:13 AM |
|
|
You walked past me again today without stopping. I remember when you used to stop and admire my glowing red ball every day. But that was back when I was brand new and you thought I was the center of your data center. I heard you talking to some friends about looking for a web acceleration solution yesterday. You were going to a meeting about it later that afternoon and you were so excited it was almost like old times, until you pointed me out on the way by and said, "Oh yeah, there's our load balancer." ...
posted @ Friday, August 29, 2008 4:05 AM |
|
|
As I was reading the Internet this morning I happened across an article with "Tips for Optimizing Your WAN (Wide Area Network)" and I thought, "Huh. That's pretty ... generic." While the article uses SAP applications as an example, it speaks in terms of generalities. Selective ACKs, quality of service, data reduction techniques, and HTTP compression. That's when I said, "Whoop de doo." Really, these techniques have nothing to do with SAP and applications and everything to do with packets. Every WAN and acceleration solution can do this stuff. I'm not really picking...
posted @ Wednesday, August 27, 2008 5:14 AM |
|
|
Greg Ferro over at My Etherealmind has a, for lack of a better word, interesting entry in his Network Dictionary on the term "Application Delivery Controller."
He says:
Application Delivery Controller (ADC) - Historically known as a “load balancer”, until someone put a shiny chrome exhaust and new buttons on it and so it needed a new marketing name.
However, the Web Application Firewall and Application Acceleration / Optimisation that are in most ADC are not really load balancing so maybe its alright.
Feel free to call it a load balancer when the sales rep is on the ground, guaranteed to...
posted @ Friday, August 22, 2008 4:49 AM |
|
|
One of the "real world" lessons rarely taught in the university setting is that in the "real world" you're going to have to follow coding standards. Back in the day, when I was allowed to code, I often railed against some of those coding standards on the basis that they impaired application performance. Anyone with a firm grounding in computer science knows that the introduction of a local scope necessarily means more work (and thus memory and cycles consumed) to set up the stack: copying variables, pushing parameters, etc... That means that a conditional statement with just one...
posted @ Tuesday, August 19, 2008 5:29 AM |
|
|
Green IT is a fairly well hyped topic at the moment. While the term may be seen as hype, there are tangible benefits to employing green tactics within IT. Even research firm Gartner sees it as one of the hyped technologies organizations can use now to see real benefits. Jackie Fenn, vice-president and Gartner Fellow on green IT via The Standard Another set of technologies that's benefit to companies now is green IT, which is valuable in more ways than one, Fenn said. "The happy...
posted @ Friday, August 15, 2008 5:32 AM |
|
|
Forrester Research recently conducted a survey on virtualization, citing server consolidation as one of the primary drivers behind the 73% of enterprises already or planning on implementing virtualization technology. But virtualization, particularly operating system virtualization, assumes you have additional cycles on servers to spare. In some cases, that's just not true. Your application servers are working as hard as they can to serve up your applications and virtualizing them isn't going to change that fact. But application acceleration technologies can change that, and offer you the chance to consolidate servers. I know that sounds crazy. How can...
posted @ Thursday, July 31, 2008 5:49 AM |
|
|
I read a very nice blog post yesterday discussing some of the traditional pros and cons of load-balancing configurations. The author comes to the conclusion that if you can use direct server return, you should. I agree with the author's list of pros and cons; DSR is the least intrusive method of deploying a load-balancer in terms of network configuration. But there are quite a few disadvantages missing from the author's list. Author's List of Disadvantages of DSR The disadvantages of Direct Routing are: Backend server...
posted @ Thursday, July 03, 2008 4:29 AM |
|
|
Several years ago it became necessary for browsers to put limitations on the number of simultaneous connections allowed not only to be open, but how many of those could be open to a single domain. This helped prevent unintentional (and, in some cases, intentional) denial of service situations where a site's poor web server just couldn't keep up with the demand. After all, managing TCP/IP connections is expensive and if one user hogs all the available connections (as determined by web server configuration and RAM) there may be hundreds of users out there that are denied access to the latest...
posted @ Tuesday, June 17, 2008 8:00 AM |
|
|
I was out trying to trim the hedges the other day, and doing...poorly. I tried, I really did, to make them as neat as the guys I hired last year, but alas, I just couldn't. Oh, it's "good enough", that's for sure, but it isn't as good as it could be. And when I went to clean up the landscaping - picking up small pieces of hedges and leaves - I couldn't help but think that those guys had some kind of secrets to doing this much more efficiently than I. Which got me thinking about application networking....
posted @ Tuesday, June 03, 2008 6:35 AM |
|
|
If you've ever used the quite popular Prototype framework, you've noticed that there are some unique options available that are designed to help reduce the number of connections made to the server when automatically updating specific content. The decay rate in Prototype's PeriodicalUpdater is designed to help reduce the number of requests made to the server when content is not refreshing on every request. Ajax.PeriodicalUpdater("content-id", "url", { frequency: 10, decay: 2, method: 'get'} ) This code will start making a call to url and updating content-id every 10 seconds. If the content hasn't changed, decay will...
posted @ Tuesday, May 20, 2008 4:36 AM |
|
|
The shortest distance between two points is, according to geometry, a straight line. Unfortunately for everyone, there's no way we can hope to physically have a straight line between us and any server - unless we're in the data center troubleshooting a problem. Whether it's because of physical distance limitations, location, or the device we're using, there's bound to be many points along the path between our client and any given server. But when we diagram network architectures we often obscure in a cloud the actual representation of the network - either because there's just too many devices (the...
posted @ Monday, May 05, 2008 6:52 AM |
|
|
I didn't say it was your fault, I said I was going to blame you. When the issue of application performance rears its ugly head like some kind of ancient dragon hell-bent on destruction (yours) it is often the application developer that ends up shouldering the blame. It's also often the case that neither the network admin or the developer can do anything to banish the evil dragon of poor performance. That's because sometimes the fault lies somewhere between the network and the application, in the murky middle layers of the OSI stack - above the network layers. ...
posted @ Wednesday, April 30, 2008 5:52 AM |
|
|
This is an interesting, albeit very short, post on web acceleration options. The author, Todd, gives a pretty quick "hit list" of reasons to use hardware (such as an application delivery controller) over the built-in capabilities of your web server: 1. Compression 2. Caching 3. TCP enhancements (optimizations) There are additional benefits to using a hardware solution with specific features/functionality that address web acceleration that Todd doesn't mention, perhaps because these options are not necessarily available for web servers and operating systems. 1. Better browser control. Many web application acceleration products are capable of manipulating the...
posted @ Thursday, April 17, 2008 9:02 AM |
|
|
Anxiety's attacking me, and my air is getting thin.I'm in trouble for the things I havent got to yet.I'm chomping at the bit, and my palms are getting wet, sweating bullets. --Megadeth, "Sweating Bullets" If you can relate to the kind of stress and anxiety sung about by Megadeth - and it's coming from the workplace - you aren't alone. Last fall InformationWeek ran a short story based on a survey they conducted and concluded that "two out of three IT managers say they're kept awake at night worrying about work, and 75% admit ongoing anxiety about application performance concerns."...
posted @ Wednesday, April 16, 2008 6:19 AM |
|
|
[ Imagine seven dwarves whistling the appropriate tune here ]
Despite Disney's insistence that the plural of dwarf is dwarfs, the rules of English and the Dungeons and Dragons Player's Handbook (PH) says it is dwarves. As the PH is obviously the authoritative source on demi-human races, it wins. Besides, dwarfs is a verb, dwarves is a noun. 'Nuff said.
The point of this post is not really to engage in a grammar war regarding dwarves and spelling, it's about the upcoming Web 2.0 Expo (April 22-25). I'm starting to think more about the conference as it's approaching quickly and...
posted @ Friday, April 11, 2008 11:21 AM |
|
|
Do you have a .plan for your .com? You should. Remember when users had a .plan? When the screech of a modem was the most annoying sound you'd hear while online? When multiplayer interaction meant joining a MUD, MOO, or MUSH? When FTP was the only way to transfer files, and if you wanted to chat you'd hop on #IRC? When discussions were for newsgroups, if you ignored alt.binaries.pictures.anything, which was certainly not for discussions. It wasn't necessarily the proliferation of broadband that caused a massive leap in users on the Internet. Just as there are plenty of...
posted @ Thursday, April 03, 2008 4:09 PM |
|
|
Matt Asay has an interesting post regarding the adoption of Firefox in the enterprise. According to a recent Forrester study, Firefox has garnered an 18% market share in that space in the US with an even larger share in Europe. Matt postulates that one of the drivers for adoption of Firefox is better performance. While he cites an evaluation of improved memory consumption as evidence of better performance, I'm willing to assert that it goes beyond simply memory consumption and into the realm of rendering speed and time to retrieve content. For example, modern browsers render content as it...
posted @ Tuesday, April 01, 2008 1:55 PM |
|
|
One of the core components of an application acceleration solution is almost always compression, and almost always implemented using industry standard algorithms supported by the ubiquitous browser. Compression is used as an application acceleration technique to decrease the total amount of data that needs to be transmitted, thereby reducing the total number of packets that must traverse the network. This results in an overall decrease in the amount of data and protocol overhead required which ultimately means the client gets the data faster. Developers and architects might be thinking: "Hey, my web/app server can compress content, I just have...
posted @ Friday, October 19, 2007 8:16 AM |
|
|
The evolution of programming languages and environments and the impact on performance Chances are that if I ask my son, a third-year computer science major, about Big(O) I'll either get that look - the one that says he's had that discussion with his father years ago and he really doesn't want to discuss such things with his mother - or he'll dismiss it as not relevant to today's computing environment. Big(O) and algorithmic performance is just not that important to today's generation of developers who are too often being taught to code within a vaccuum, or to be more accurate,...
posted @ Tuesday, October 02, 2007 9:23 AM |
|
|
More bandwidth can't always solve your application performance problems We have, over the years, come to the realization that application performance issues cannot always be solved simply by increasing the amount of bandwidth available. The concept was inherently flawed from the beginning anyway. You can increase the number of lanes on the highway but that doesn't mean that you'll get to your destination faster, it just means more people can get where they're going in about the same amount of time. This is because there is an upper bound on the speed of a car, just as there is an...
posted @ Thursday, September 27, 2007 1:30 PM |
|
|
Diving more deeply into the issue of speeding up JavaScript and the load balancing question, Scott Conroy points out: The single URL strategy has a major downside, though it is certainly cleaner than having to deal with many URLs. Since HTTP 1.1 says that user agents and servers SHOULD have only two concurrent connections, requests for multiple resources can easily develop into blocking operations. If, say, I have a page that includes twenty images to download, my browser (in its default config) will only download 2 images at a time. If I put those images on multiple "servers"...
posted @ Monday, August 27, 2007 8:34 AM |
|
|
An interesting article on "How JavaScript is Slowing Down the Web (And What To Do About It)". The basic premise is that Web 2.0 applications like blogs are using so much JavaScript to load widgets and perform other functions that it's causing the initial page load to be s l o w. That's so true. The author has many (okay, there are five) suggestions for improving performance, but one sticks out in my mind, probably because it's core to F5 and its products - and it's not entirely accurate. 3. Load-balance requests by generating different...
posted @ Friday, August 17, 2007 9:55 AM |
|
|
Improving the performance of AJAX applications by switching servers isn't always feasible in a real environment It's nice to see the analysis of AJAX I did last year being validated, especially by one of the creators of the popular AJAX-focused toolkit, Dojo. While I agree with Dylan's assessment of where to begin the "search & destroy mission" and the reasons behind poor performance of AJAX-based applications, I just can't get behind his suggestion to switch Web servers simply to resolve highly aggressive polling-based applications. The best place to begin a thorough search & destroy mission is with...
posted @ Tuesday, July 24, 2007 12:57 PM |
|
|
|
|
|
|
