|
| DevCentral > Weblogs > - Two Different Socks
|
BIG-IP
There are 64 entries for the tag BIG-IP
 |
When you’re dealing with conditional formatting of objects based on enumerated values you can eliminate conditional assignments by directly mapping your ENUMs to CSS classes. There are many cases where enumerated values are used to describe values, especially in the world of infrastructure 2.0. Availability status, for example, is a commonly used enumeration to indicate whether a load balancing related object – a virtual server, a pool, a node (server) – is available, unavailable, or in some unknown state. When building web-based dashboards or management interfaces for such solutions, the server-side code often ends up with a lot...
posted @ Monday, December 14, 2009 4:45 AM |
|
 |
When you look at the success of some very proprietary solutions and the loyalty with which customers defend them, you have to wonder if vendor lock-in is really as bad a thing as we sometimes make it sound. The subtext in the discussions around data portability and interoperability in general in cloud computing is really about vendor lock-in. Those driving efforts to come up with solutions that allow customers to pack up their data and head to another provider are primarily concerned about the dangers of being locked-in to a single vendor solution. ...
posted @ Friday, November 13, 2009 3:47 AM |
|
 |
Infrastructure 2.0, from a purely developmental standpoint, is about APIs. It’s about offering up the functionality and capabilities of a wide variety of infrastructure – network, storage, and application network – to be externally controlled, integrated, and leveraged for whatever purpose a developer might dream up. It enables providers and enterprises alike to turn infrastructure functionality into services. Need compression? Caching? Routing? Load balancing? Via service-enabled management APIs these can become services, provisioned and released through the invocation of a service. When expanded to include the sharing of actionable data – performance statistics, status, availability of application...
posted @ Wednesday, November 04, 2009 3:18 AM |
|
 |
Cloud offers an appealing “pay only for what you use” that makes it hard to resist. Paying on a per-usage hour basis sounds like a good deal, until you realize that your site is pretty much “always on” because of bots, miscreants, and users. In other words, you’re paying for 24x7x365 usage, baby, and that’s going to add up. Ironically, the answer to this problem is … cloud. Don and I occasionally discuss how much longer we should actually run applications on our own hardware. After all, the applications we’re running are generally pretty light-weight, and only see...
posted @ Tuesday, October 13, 2009 4:30 AM |
|
 |
F5 and VMware demonstrate live migration of a virtualized application across clouds without downtime or user disruption Cloud is reaching the peak of possibilities and that (often) means just more paper solutions. You know the ones; the ones that exist only on paper (or in blogs as the case may be). Those paper solutions need to exist because the ideas need to come first either out of necessity, i.e. to solve a specific problem, or out of a desire to find new ways to leverage emerging technology, like virtualization. But still, you’d like to see some of these...
posted @ Monday, August 31, 2009 4:33 AM |
|
 |
Using network-side scripting to remove client-side cookies @quine overhead an interesting question that he offered via Twitter regarding cookies and BIG-IP. Specifically someone was wondering whether BIG-IP automatically removes cookies from the browser. Our team had a quick discussion because the question isn’t as straight-forward as it first appears. On the surface the answer is an unequivocal “no”, because for an intermediary to just arbitrarily remove cookies would be a Very Bad Thing. But the ability to manipulate cookies is certainly something you can do using iRules, and if you implemented such functionality then the...
posted @ Wednesday, July 08, 2009 3:43 AM |
|
 |
We know what the problem is. We know what the solution is. So why aren’t we doing something about it? Every year, around April Fools’ day, someone pulls out the old “Internet Spring Cleaning” gag. For those of us who are not technical neophytes or have been “online” long enough, the joke is amusing but not nearly as much as when it originally appeared many, many, many years ago. Is it possible, though, that one day the old “the Internet needs to be rebooted” gag might be real? That in order to get from here...
posted @ Monday, April 27, 2009 3:23 AM |
|
 |
You’ve declared your Data Center Independence. You’ve agreed on a basic set of rights. The problem now is ensuring that those rights are upheld and that you can achieve that independence. We’re not innocent bystanders in the data center revolution; we wholly support your rights to choose the architecture and solutions that best fit your environment. You can’t do it alone. You need tools with which to fight the data center revolution. So we’re arming you with at least some of those tools (hey, we can’t do it all alone) with the introduction of BIG-IP v10...
posted @ Wednesday, April 08, 2009 4:47 AM |
|
 |
Ah, those were the days, weren’t they? When improving the security, reliability, and performance of applications over the LAN, over the WAN, and over the Internet meant you had to deploy many different solutions, each one standing on their own in the data center. When you had to learn how to configure and manage as many devices as you have fingers just to deliver a single business-critical application to users and customers across a wide variety of environments. When there really wasn’t an option because solutions weren’t unified, weren’t contextually aware, and were basically just a bunch of point solutions...
posted @ Monday, March 23, 2009 3:21 AM |
|
 |
Ah, those were the days, weren’t they? When you needed a way to add security at several layers to your network and application network infrastructure but knew that implementing a solution capable of securing those pesky applications was more than likely going to end up with poor performance and angry users. When you needed to add something to secure applications and the network against the growing wave of attacks but knew that doing so would negatively impact performance. It was a tough choice, and most people ended up going the route of maintaining application performance at the expense...
posted @ Monday, March 16, 2009 3:39 AM |
|
 |
Ah, those were the days, weren’t they? When you needed a way to inspect data at the edge for application-specific issues but knew that implementing a solution capable of that kind of agility was more than likely going to end up with poor performance and angry users. When you needed to add something to secure applications and the network against the growing wave of attacks but knew that doing so would negatively impact performance. It was a tough choice, and most people ended up going the route of maintaining application performance at the expense of security and optimization...
posted @ Monday, March 09, 2009 4:30 AM |
|
 |
One of the reasons behind some folks pushing for infrastructure as virtual appliances is the on-demand nature of a virtualized environment. When network and application delivery infrastructure hits capacity in terms of throughput - regardless of the layer of the application stack at which it happens - it's frustrating to think you might need to upgrade the hardware rather than just add more compute power via a virtual image. The truth is that this makes sense. The infrastructure supporting a virtualized environment should be elastic. It should be able to dynamically expand without requiring a new network architecture,...
posted @ Tuesday, January 13, 2009 4:15 AM |
|
 |
Over the holidays I did, as most folks I suspect, things I enjoy doing. For me, one of those things was playing around with Adobe's Flex using Flex Builder 3. Yes, I am that much of a geek. I was a bit concerned it would take some time to figure it all out, but after quickly realizing that MXML, Adobe's interface markup language, was close enough to XAML, Microsoft's interface markup language, it was pretty much smooth going. ActionScript is close enough to JavaScript and C and most other languages I'm familiar with so that...
posted @ Thursday, January 08, 2009 8:12 AM |
|
 |
If you're an F5 customer running BIG-IP v4.x it's time to consider migrating to newer platforms. I know, why in the world would you want to upgrade when your BIG-IP has been running just fine for years? Probably the most important reason is that F5 is ending the life of the 4.x release and will no longer focus resources on improving it. That means all the new improvements and innovation will continue to be put into the 9.x branch and without migrating you'll miss out on a lot of great opportunities to support new protocols, deploy new functionality...
posted @ Monday, November 17, 2008 5:22 AM |
|
 |
We all understand the lines in the sand (or the architectural diagram) that separate client-side scripting from server-side scripting. It's very clear that client-side scripting, e.g. JavaScript, VBScript, ActionScript, executes on the client while server-side scripting, e.g. PHP, ASP, executes on the server. But what about network-side scripting?
"There is no such thing!" might be the first response to this question, but I beg to disagree. Programmable proxies, a la F5's BIG-IP Local Traffic Manager, that provide a scripting language such as iRules, are simultaneously client-side and server-side, with the best definition to describe their placement in architectures being network-side...
posted @ Friday, October 31, 2008 5:26 AM |
|
 |
Over the years imaginative developers have come up with a number of ways through which they hope to stop the pilfering of their images. Whether due to copyright issues or the increased bandwidth and associated costs resulting from "hot linking", site owners have tried a variety of solutions from JavaScript that prevents the ability to right-click and "save as" to watermarking high-resolution versions to make their images less appealing to image thieves. Regardless of the reason you may want to prevent image theft, there's an easier and more effective method than introducing easily countered JavaScript and costly alternative...
posted @ Tuesday, October 21, 2008 3:31 AM |
|
 |
After having recently discussed all the different kinds of proxies that exist, it occurred to me that it might be nice to provide some examples of what you can do with proxies besides the obvious web filtering scenario. This is by no means an exhaustive list, but is provided to show some of the more common (and cool, I think) uses of proxies. What's really awesome is that while some of these uses are available with only one type of proxy (reverse or forward), a full proxy can provide all these uses, and more, in a single, unified...
posted @ Wednesday, October 08, 2008 4:27 AM |
|
 |
I read about a "new" TCP flaw that, according to C|Net News, Related Posts puts Web sites at risk. There is very little technical information available; the researchers who discovered this tasty TCP tidbit canceled a conference talk on the subject and have been sketchy about the details of the flaw when talking publicly. So I did some digging and ran into a...
posted @ Friday, October 03, 2008 5:06 AM |
|
 |
If you're excited about the automation capabilities of cloud computing and virtualization, you are going to love this solution. In a virtualized environment where applications can ostensibly be popping up all over, and applications are no longer tied to specific servers, there is a need to automatically manage these application instances in a high-availability (load balanced) environment. What you need is the ability to automagically add and remove application instances from the application delivery controller (load balancer) so you don't have to worry about tying those applications down, which could reduce the benefits typically associated with virtualization. If...
posted @ Tuesday, September 30, 2008 4:49 AM |
|
 |
Reuven Cohen of the Elastic Vapor blog, in this article, puts forth the notion that infrastructure is required to enable cloudbursting and then asks an excellent question: To truly enable a capable cloudbursting infrastructure, I feel there needs to be a common consensus on how this may be archived and by what means. So the question in...
posted @ Thursday, September 18, 2008 8:41 AM |
|
 |
We're virtually there! Figuratively speaking, of course. VMWorld kicks off Monday night, and F5 is just putting the finishing touches on everything we've got to bring along to the show (yes, that means trinkets, too). What the heck are we doing at a virtualization show? Pshaw. We've been in the business of network and server virtualization for ... well, forever. Hey, 12 years is forever in this industry, isn't it? We'll be doing a cool demo with BIG-IP GTM in the B-Hive demo, where we'll demonstrate global load sharing between virtual data centers, and Trace|3...
posted @ Wednesday, September 10, 2008 4:18 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 |
|
 |
For those of you unfamiliar with the idiom, it should be taken to mean "benefiting one at the expense of another." In this case, Paul is the end-user and Peter is the server administrator. Or better yet, Paul is the browser and Peter is the server. All web browsers, including IE (Internet Explorer), impose a per-server connection limit was imposed to reduce overload on servers. This was introduced back when the web was exploding and browsers opened up connections willy-nilly and made server operators cry. Often. The limitation imposed by IE (two connections per host) was harsher...
posted @ Friday, September 05, 2008 4:19 AM |
|
 |
The cloud computing craze is leading to some interesting new terms. Cloudware and cloudbursting are two terms I particularly like for their ability to describe specific computing models based on cloud computing. Today we're going to look at cloudbursting, which is basically a new twist on an old concept. Cloudbursting appears to be to marry the traditional safe enterprise computing model with cloud computing; in essence, bursting into the cloud when necessary or using the cloud when additional compute resources are required temporarily. Jeff at Amazon Web Services Blog talks about the inception of this term as applied...
posted @ Wednesday, September 03, 2008 5:10 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 |
|
 |
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 |
|
 |
Web 2.0 is built on primarily two technologies: AJAX and RSS. AJAX is used to develop interactive, real-time applications while RSS is primarily used as for integration and syndication. Import a feed, share a feed, drag-n-drop a gadget, widget, or component. It's all RSS (XML) today. It's further becoming a requirement of Web 2.0 sites that they provide some sort of API through which developers can write add-on applications. Twitter, Tumblr, Facebook. They all offer APIs that are quite heavily used at this time and startups are following suit. Other sites offer richer media, like video or slideware,...
posted @ Tuesday, July 01, 2008 4:53 AM |
|
 |
This past week there's been some interesting commentary regarding Twitter's change to its API request throttling feature. Request throttling, often used as a method to ensure QoS (Quality of Service) for a variety of network and application uses, is used by Twitter as an attempt to not overwhelm the system such that they are forced to display the now (in)famous Twitter fail whale image. One of the things you can do with a BIG-IP Local Traffic Manager (LTM) and iRules is request throttling. Why would you want to let a mediating device like an application delivery controller control...
posted @ Monday, June 30, 2008 3:43 AM |
|
 |
Multi-tenant applications are extremely popular in the SaaS (Software as a Service) world. Almost all SaaS delivered CRM (Customer Relationship Manager) and SFA (Sales Force Automation) applications are necessarily multi-tenant. These applications use a meta-data driven model to enable the customization of applications on a per customer basis. This allows the provider to deploy a single application to scale vertically, supporting a wide variety of industries with a single code base. In order to scale horizontally, however, it is necessary to deploy multiple instances of that single code base. To enable a scalable architecture to properly support (hopefully)...
posted @ Tuesday, June 24, 2008 5:35 AM |
|
 |
Remember way back when we talked about dynamically updating a WSDL to present the appropriate endpoint when being delivered through a BIG-IP? You may recall the basic problem: automatically generated WSDL docs contain the local web/application server's IP address/FQDN as the endpoint and not the IP address/FQDN of the BIG-IP, leaving clients with a non-reachable service endpoint. Since that original blog post, a couple of users have asked for the appropriate iRule to dynamically update those auto-generated WSDL docs. Colin was kind enough to code up just such an iRule, and wrap it up with some...
posted @ Monday, June 23, 2008 5:52 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 |
|
 |
Yes, I've got gaming on the brain after this month's release of the latest edition of D&D and a weekend with friends "geeking" out with polyhedral dice and imaginary monsters. You might recall that Don stood in line at midnight earlier this month to pick up our copy of the newest (4th) edition of Dungeons & Dragons (D&D). Since then we've been dissecting the game, noting its similarities and differences from earlier versions. Bemoaning the loss of some features while nodding our heads appreciatively at some of the other changes. It took me most of...
posted @ Monday, June 16, 2008 5:44 AM |
|
 |
Apparently quite a bit if it can be turned into an acronym... Quick. Say the acronym "ROC" out loud. Now choose the picture that immediately came to your mind. A B ...
posted @ Thursday, June 12, 2008 4:48 AM |
|
 |
Kevin Saitta, a solution consultant, has a nice blog post on architecting a Microsoft BizTalk 2006 R2 solution. Unfortunately, amidst the goodness, is a statement regarding load balancers that needs to be corrected. Kevin is not alone in his beliefs regarding load balancers, unfortunately, I've seen a lot of posts lately that seem to indicate that folks out there still have a circa 1999 knowledge set regarding the capabilities of load balancers. Kevin writes Load Balancer A load balancer balances the load between servers, but more importantly, if one server...
posted @ Wednesday, June 11, 2008 5:12 AM |
|
 |
Everyone's now familiar with last week's Amazon outage, it's been all over the web. Amazon is still not detailing what went wrong, but lots of folks are speculating on the reasons for the failure. Alistair Croll over at gigaom had a nice recap of the recent Amazon outage, including a list of facts and what we can deduce them, and the rumor mill is, of course, churning away with fantastic stories of what went wrong. Rather than add to the speculation on the reasons behind Amazon's outage - because we may never know the truth - it's a...
posted @ Tuesday, June 10, 2008 5:50 AM |
|
 |
In researching the MySpace deprecated API exploit I came across the details on MySpace's REST (Representational State Transfer) API. I'm going to ignore the debate surrounding the definition of "high REST" versus "low REST" and concentrate on the bridging aspect, as it's something I've already touched on and find to be of more value than worrying over what it's called or whether it's a standard or whatever else might be the focus of these arguments. You may recall that part of the problem with a true REST implementation is that many browsers do not support PUT and DELETE....
posted @ Friday, June 06, 2008 9:02 AM |
|
 |
An issue that often comes up for users of any full proxy-based product is that the original client IP address is often lost to the application or web server. This is because in a full proxy system there are two connections; one between the client and the proxy, and a second one between the proxy and the web server. Essentially, the web server sees the connection as coming from the proxy, not the client. Needless to say, this can cause problems if you want to know the IP address of the real client for logging, for troubleshooting, for...
posted @ Monday, June 02, 2008 4:20 AM |
|
 |
After reading most of what's available on the Adobe Zero Day Exploit, and getting an idea of how it propagates (Flash and JavaScript inserted via an SQL injection attack), I turned to iRules guru Colin for some help crafting an iRule that might stop a site from serving up infected content to a user. This is particularly helpful for those who are running a BIG-IP but who aren't running a web application firewall like ASM (Application Security Manager) and may have been inadvertently infected.
After looking through the screen capture of some JavaScript that attempts to load the malware from...
posted @ Thursday, May 29, 2008 5:40 AM |
|
 |
By now you've certainly heard about the "zero day" Adobe Flash player exploit. If not, you can read a bit about it here and here. What appears to be going on is similar to how other exploits and malware become quickly propagated across the web: Set up a site that hosts some malware with a simple but effective password stealer hidden in a Flash file Inject malicious code via SQL injection techniques into a web site that will load the Flash files from the host you set up in step 1....
posted @ Wednesday, May 28, 2008 11:00 AM |
|
 |
Individual servers in a farm may be expected to fail, but the site - that's a different story Tom's Hardware has an interesting look at an architecture I'm going to call "built to fail". This architecture is focused on building a fault tolerant site, not necessary a fault tolerant web application infrastructure. While the author of the article implies that this architecture is something new, it's really not except in the sense that today's Web 2.0 app providers might not care if a server is lost because it's cheap to replace while other, more cost conscious organizations...
posted @ Tuesday, May 27, 2008 5:00 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 |
|
 |
There's a lot of things that BIG-IP can do to improve the reliability, scalability, and performance of Web 2.0 applications. But there are always two sides to every story, and so it is with BIG-IP and Web 2.0, or specifically, AJAX. This latest article, Getting Started with iControl and AJAX, offers advice and code to get you started building a custom AJAX-based dashboard for BIG-IP. Imbibing: Coffee Technorati Tags: MacVittie,development,iControl,BIG-IP,F5,AJAX,Web 2.0
posted @ Tuesday, May 13, 2008 5:05 AM |
|
 |
This is an interesting article from Network World about how CIOs in Australia and New Zealand perceive security as being easier than reducing costs. The IDC Annual Forecast for Management report surveyed 363 IT executives from Australia (254 respondents) and New Zealand (109 respondents) across industries including finance, distribution, leisure and the public sector. CIO Challenges ...
posted @ Friday, May 09, 2008 8:15 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 |
|
 |
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 |
|
 |
How to apply SOA principles to traditional web application architecture I promised kudos and comments last week for Ronald Schmelzer's ZapNote on the requirement for a service proxy in SOA implementations and so I shall right now. While Ron didn't come right out and say it, a major reason the service proxy is an essential component of a successful SOA implementation is that it protects the concept of loose-coupling, a primary foundational principle of SOA. Loose-coupling is generally applied to consumer-producer relationships and essentially requires that there be no code or logic on the consumer (client) that binds it tightly...
posted @ Tuesday, March 11, 2008 9:49 AM |
|
 |
Why do web app developers make URLs so hard to remember?!? Rewriting for Fun Over the course of the past few weeks I've sent out a link to our personal Gallery installation to share pictures of our new son many times. Now I love Gallery and even though I can recite PI to 42 significant digits, I can't recall the exact URL to the album containing his pictures. I'm constantly looking it up and cutting and pasting it into my e-mail and quite frankly, it's getting annoying. It's long and confusing and not easily remembered. I can't rewrite...
posted @ Thursday, March 06, 2008 9:47 AM |
|
 |
A Quick History Lesson Back in the day, server-load balancing vendors figured out that connection management (the setup and teardown of TCP/IP connections) was actually quite a burden on servers. You see, the server not only had to spend time setting up and tearing down the connection, but it also had to keep track of those connections in something we like to call a "session state table". The problem was, and still is, that a server has a limited amount of memory and can only manage X number of connections concurrently. This is primarily a matter of configuration of...
posted @ Thursday, February 21, 2008 9:13 AM |
|
 |
Over the past three weeks Don and I have had a lot of time to chat whilst making the trek back and forth between home and the hospital where the newest member of our family was keeping residence. Mostly we talked about our new son and speculating as to when he might be allowed to come home (Feb 17), but as is our wont we often ended up talking about work. That's one of the benefits of working "together" and in the same field, at least we think so. One of those discussions revolved around iControl and the fact that...
posted @ Tuesday, February 19, 2008 9:42 AM |
|
 |
Every morning while I drink my allowed daily allowance of caffeine I peruse through my news and blog feeds via Google Reader. I expect, and am not disappointed, to find that those items I marked as "read" yesterday are still marked as such, and that those I "starred" for follow up are also still marked as such. And of course every feed I've subscribed to still exists, just as it did the night before. This seems like a trivial thing, because we've come to expect that our web applications are intelligent enough to remember our personal settings and configuration....
posted @ Wednesday, January 16, 2008 2:25 PM |
|
 |
Erik Dafforn recently posted his Webmaster Wish List for 2008. What it sounds like is that Erik is really asking for tools that make it easier to configure web sites and, more specifically, how web servers respond to requests. What's interesting about his list is that most of his wish list can easily be answered with the implementation of a simple iRule on BIG-IP Local Traffic Manager. For example, you might have pages such as www.companyname.com/products/ and www.companyname.com/products/index.aspx. Typically, these URLs contain exactly the same content, but due to inconsistent linking throughout the site (and from third-party sites),...
posted @ Friday, January 11, 2008 1:42 PM |
|
 |
We don't often consider the impact of manageability of technology in our daily lives, even though it's become an integral part of just about every aspect of our lives. Likely most prevalent amongst technology management issues is how we deal with our home entertainment systems. From a desire to manage all the devices that deliver and control various forms of media - cable, DVDs, games, etc... - with a single, intelligent mangement device evolved what we like to call the "universal remote". These little management devices are able to control every component comprising our home entertainment system, greatly reducing the cost...
posted @ Wednesday, January 09, 2008 2:31 PM |
|
 |
Google. Amazon. Facebook. LinkedIn. Salesforce.com. While certainly not an all inclusive list, these very recognizable web monsters all offer access to their "platforms" via a web-based API, a.k.a. services. With the notable exception of Salesforce.com, most have implemented these services as a REST (Representational State Transfer) or REST-like set of interfaces, but in general these APIs meet the criteria necessary to be referred to as services. They're SOA as surely as any other service out there. These services are being incorporated at a rapid pace into other web-based (dare I say Web 2.0) applications, and a plethora of others...
posted @ Friday, January 04, 2008 10:09 AM |
|
 |
Every industry measures performance, we just use different jargon to discuss it. When we talk about the raw power of a car engine we talk in terms of horsepower; of harnessing the performance of hundreds of horses such that they work together as a single unit. In the world of computing we use terms like MIPS (million instructions per second), and in the world of application delivery we measure performance in terms of transactions per second (TPS). The problem in the world of computing is, unfortunately, that simply adding more "horses" to the mix doesn't linearly increase performance. Generally...
posted @ Wednesday, January 02, 2008 2:12 PM |
|
 |
This was just one of those press releases that was so close to being right and yet was missing half the picture. Chicago-based managed dedicated server provider, SingleHop, Inc., advises shoppers to be prepared to suffer through the dreaded "high traffic volume" warnings this holiday season as retailers may be hit with higher than average website traffic.
That's really no surprise, after all I'm fairly certain my shopping alone is enough to cause outages. If you've run into an outage lately, my apologies. I'll be finished shopping shortly. I promise.
In any case, Zak Boca, President, SingleHop, goes...
posted @ Friday, December 14, 2007 11:20 AM |
|
 |
Our own Deb Allen posted a great tech tip yesterday on conditional logic using HTTP::retry with iRules. This spawned a rather heated debate between Don and myself on the importance of performance versus reliability and application delivery, specifically with BIG-IP. Performance is certainly one of the reasons for implementing an application delivery network with an application delivery controller like BIG-IP as its foundation. As an application server becomes burdened by increasing requests and concurrent users, it can slow down as it tries to balance connection management with execution of business logic with parsing data with executing queries against a database with making...
posted @ Thursday, September 20, 2007 9:35 AM |
|
 |
Performance. Everybody wants to know how things perform, whether it be cars, laptops, XML gateways, or application delivery controllers. It's one of the few quantifiable metrics used to compare products when IT goes shopping, especially in the world of networking. Back at Network Computing I did a lot of testing, and a large portion of that testing revolved around performance. How fast, how much data, how many transactions, how many users. If it was possible, I tested the performance of any product that came through our lab in Green Bay. You've not had fun until you've actually melted an SSL...
posted @ Monday, September 10, 2007 7:06 AM |
|
 |
Yesterday Don voiced his opinion that XML tagging is a broken proposition. One of his basic premises is that because tags, a.k.a. meta-data, are generated by people and people aren't always as, shall we say, obsessive about doing so, that the entire system is broken. Obviously I disagree or I wouldn't be penning this post. :-) Web 3.0, a.k.a. the Semantic Web, is going to require tagging, or meta-data if you prefer. Without it there's not a good way to establish the relationships between content that forms the basis for connections. But people are only part of the equation,...
posted @ Thursday, August 30, 2007 9:28 AM |
|
 |
Occassionally I get to chat with the guys in the trenches about ongoing implementations involving BIG-IP. Often these involve deploying BIG-IP in front of XML/SOA gateways for load balancing and high-availability (a la failover) duties, as well as session management capabilities. This is primarily due to a lack of support for these options on the part of XML/SOA gateways combined with the need to horizontally scale out the gateways to deal with high volume throughput. I got to thinking about this deployment scenario during a chat with very smart SOA guys Tony Bishop and Jim Haughton and we decided that...
posted @ Wednesday, August 29, 2007 3:39 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 |
|
 |
When being chased by a dragon, you don't need to be faster than the dragon. You just need to be faster than the halfling behind you.
I had a lot of discussions at RSA this past week, and of course some of them centered on performance. One of the challenges often associated with pure proxy-based application anything involves dealing with the argument that proxies degrade performance, especially in something as intense as an application firewall. That's because of the associated computational cost of buffering input, reassembling packets, and parsing through data in addition to the requirement of managing TCP connections...
posted @ Monday, February 12, 2007 12:49 PM |
|
 |
Is the pipe half-full or half-empty?
David Linthicum does a good job of pointing out the factors that can affect performance of your SOA in his recent Real World SOA entry: When to Consider SOA Performance.
I particularly liked rule #3:
"Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services."
You should indeed take the network into careful consideration when...
posted @ Wednesday, December 20, 2006 1:27 PM |
|
|
|
|
|
|