I have mentioned in the past that you should really look ‘under the hood’ as far as application communication goes.
I have seen many web applications that ‘work’ but not ‘work well’. if you dig in, you may find error messages or logs. Errors can caused many different ways;
- Application - Messages are entirely application based and are addressed by the application team or vendor.
- Sending commands with no authentication, wait for the error message, then resend the same command but this time with authentication
- Using small packet or data payload sizes
- Inefficient multi-tiered server architecture
- Login processes that constantly download application files without checking if you have them already
- References to servers that are de-commissioned or only used for testing/development
- Network – Messages generated by the network devices that can affect application performance and are addressed by the networking team, like ICMP redirects
- MTU issues caused by different network topologies, firewalls, routers or load balancers
- Blocked ICMP error messages that the application needs to make proper adjustments, like MTU and routing
- Inefficient or misconfigured routes
- Proxies or firewalls that do not allow application access but fails to the default gateway that still works
- New equipment with old switch port VLAN, speed or duplex configurations
- Access points with 1 Gb Ethernet ports using the existing 100Mb POE injector
- Client/Server- Errors caused at the server or host configurations. These are addressed by the server and desktop team.
- Old configurations blindly used on newer operating systems
- Using all the default protocols and services when they are not needed
- Aggressive antivirus or firewall settings causing disconnections or performance issues
- Server with limited resources (RAM or CPU)
In this example, I will focus on HTTP 503 Service Unavailable messages generated from web servers. In many cases, these are generated as a webpage loads and the user has no idea this is happening but may experience delays or page load 'stuttering'.
If you’re lucky, the error will cause a noticeable issue, so you can investigate. If you’re not lucky the issue may intermittently resolve itself quickly resulting in random performance issues and support calls.
Many protocol analyzers and applications can report or count the number of errors. I suggest you initially concentrate on 4xx or 5xx error codes. If none exist, look for big delta times between the HTTP command responses.
If you are using HTTPS, look into what logs or analysis tools are available. For example most web browsers have a Developer Tools facility that will record all sorts of helpful information. Alternatively there are agents you can load on your clients to record and log performance or errors.
In any case, I suggest you test and get familiar with your chosen tools to ensure they are accurate and that you understand what they are reporting.
One of my favorite webservers to use for testing is the FREE Rejetto HFS HTTP server
