True or False: Application acceleration solutions teach developers to write inefficient code
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 executes faster, the ADC will do that for me, etc., etc.
While no one can control whether a programmer writes “fast” code, the truth is that application acceleration solutions do not affect the execution of code in any way. A poorly constructed loop will run just as slow with or without an application acceleration solution in place. Complex mathematical calculations will execute with the same speed regardless of the external systems that may be in place to assist in improving application performance.
The answer is, unequivocally, that the presence or lack thereof of an application acceleration solution should have no impact on the application developer because it does nothing to affect the internal execution of written code.
If you answered false, you got the answer right.
The question has to be, then, just what does an application acceleration solution do that improves performance? If it isn’t making the application logic execute faster, what’s the point?
It’s a good question, and one that deserves an answer.
Application acceleration is part of a solution we call “application delivery”. Application delivery focuses on improving application performance through optimization of the use and behavior of transport (TCP) and application transport (HTTP/S) protocols, offloading certain functions from the application that are more efficiently handled by an external often hardware-based system, and accelerating the delivery of the application data.
OPTIMIZATION
Application acceleration improves performance by understanding how these protocols (TCP, HTTP/S) interact across a WAN or LAN and acting on that understanding to improve its overall performance. There are a large number of performance enhancing RFCs (standards) around TCP that are usually implemented by application acceleration solutions.
- Delayed and Selective Acknowledgments (RFC 2018)
- Explicit Congestion Notification (RFC 3168)
- Limited and Fast Re-Transmits (RFC 3042 and RFC 2582)
- Adaptive Initial Congestion Windows (RFC 3390)
- Slow Start with Congestion Avoidance (RFC 2581)
- TCP Slow Start (RFC 3390)
- TimeStamps and Windows Scaling (RFC 1323)
All of these RFCs deal with TCP and therefore have very little to do with the code developers create. Most developers code within a framework that hides the details of TCP and HTTP connection management from them. It is the rare programmer today that writes code to directly interact with HTTP connections, and even rare to find one coding directly at the TCP socket layer.
The execution of code written by the developer takes just as long regardless of the implementation or lack of implementation of these RFCs. The application acceleration solution improves the performance of the delivery of the application data over TCP and HTTP which increases the performance of the application as seen from the user’s point of view.
OFFLOAD
Offloading compute intensive processing from application and web servers improves performance by reducing the consumption of CPU and memory required to perform those tasks. SSL and other encryption/decryption functions (cookie security, for example) are computationally expensive and require additional CPU and memory on the server. The reason offloading these functions to an application delivery controller or stand-alone application acceleration solution improves application performance is because it frees the CPU and memory available on the server and allows it to be dedicated to the application. If the application or web server does not need to perform these tasks, it saves CPU cycles that would otherwise be used to perform them. Those cycles can be used by the application and thus increases the performance of the application.
Also beneficial is the way in which application delivery controllers manage TCP connections made to the web or application server. Opening and closing TCP connections takes time, and the time required is not something a developer – coding within a framework – can affect. Application acceleration solutions proxy connections for the client and subsequently reduce the number of TCP connections required on the web or application server as well as the frequency with which those connections need to be open and closed. By reducing the connections and frequency of connections the application performance is increased because it is not spending time opening and closing TCP connections, which are necessarily part of the performance equation but not directly affected by anything the developer does in his or her code.
The commenter believes that an application delivery controller implementation should be an afterthought. However, the ability of modern application delivery controllers to offload certain application logic functions such as cookie security and HTTP header manipulation in a centralized, optimized manner through network-side scripting can be a performance benefit as well as a way to address browser-specific quirks and therefore should be seriously considered during the development process.
ACCELERATION
Finally, application acceleration solutions improve performance through the use of caching and compression technologies.
Caching includes not just server-side caching, but the intelligent use of the client (usually the browser) cache to reduce the number of requests that must be handled by the server. By reducing the number of requests the server is responding to, the web or application server is less burdened in terms of managing TCP and HTTP sessions and state, and has more CPU cycles and memory that can be dedicated to executing the application.
Compression, whether using traditional industry standard web-based compression (GZip) or WAN-focused data de-duplication techniques, decreases the amount of data that must be transferred from the server to the client. Decreasing traffic (bandwidth) results in fewer packets traversing the network which results in quicker delivery to the user. This makes it appear that the application is performing faster than it is, simply because it arrived sooner.
Of all these techniques, the only one that could possibly contribute to the delinquency of developers is caching. This is because application acceleration caching features act on HTTP caching headers that can be set by the developer, but rarely are. These headers can also be configured by the web or application server administrator, but rarely are in a way that makes sense because most content today is generated dynamically and is rarely static, even though individual components inside the dynamically generated page may in fact be very static (CSS, JavaScript, images, headers, footers, etc…).
However, the methods through which caching (pragma) headers are set is fairly standard and the actual code is usually handled by the framework in which the application is developed, meaning the developer ultimately cannot affect the efficiency of the use of this method because it was developed by someone else.
The point of the comment was likely more broad, however. I am fairly certain that the commenter meant to imply that if developers know the performance of the application they are developing will be accelerated by an external solution that they will not be as concerned about writing efficient code.
That’s a layer 8 (people) problem that isn’t peculiar to application delivery solutions at all. If a developer is going to write inefficient code, there’s a problem – but that problem isn’t with the solutions implemented to improve the end-user experience or scalability, it’s a problem with the developer.
No technology can fix that.
Published Feb 17, 2009
Version 1.0
Lori_MacVittie
Employee
EmployeeLori_MacVittieEmployee
Employee
Lori_MacVittieMike, Mike, Mike. Yes, that's true. However, it is rare to see developers in an organization writing down at the protocol level.
Most enterprise developers code within a framework; a framework which handles all the protocol layer details. In fact, in JavaEE apps deployed in containers, the application doesn't even begin executing until after the HTTP request has been evaluated by the container and routed down the execution chain to the application.
The same is true in .NET applications. And while it's certainly possible (and sometimes happens) that PHP/ASP developers will play with sockets, the vast majority of them are not dealing with TCP or even HTTP aside from manipulation of cookies/headers.
Then you have third-party applications which have similar performance problems but cannot be modified by the customer. Sure, you can complain about the performance, but it's not likely to be improved in a time frame such as that it will benefit you.
Developers aren't writing at that level in general, and there is a need for external improvements in network performance to deal with the inefficiencies inherent in the protocol stacks implemented in OSs and deployment platforms.
Those developers that are tweaking the protocols should absolutely be more cognizant of what they are doing and how they are doing it and be as efficient as possible.
Lori- Heh. I don't recall a time when developers didn't write inefficient code - all depends upon the developer. If it's a job, they find the fastest solution, if it's a craft, they find the best solution.
I agree with Fratto though, networking is still a bit of a mystery to many developers, which opens the door to inefficiency.
Don. - Lori_MacVittieDear Developer: Step Away from the Keyboard
whswhswhs124_98Nimbostratus
whscheck
