Application Profiling

Introduction:

I can turn you into an Application expert in 5 minutes by reading this post.  Just do what the experts do, or even the not-so-experts.  They pay meticulous attention to the requests from clients and the responses from servers, both headers and body content.  You do this the old fashioned way by taking a trace.  There are better tools out there, some free, some not-so-free.

Running a trace:

Running a trace will help you 'profile' the application. It is recommended that you do this before placing the Citrix Application Switch in-line of the Application traffic. This will gather important information about the Application that will help you understand it's basic operation at Layer 7, and help you begin to understand what it is that needs to be accelerated - cached, compressed, load balanced, ssl offloaded, etc.

Running a trace exposes the flow of transactions between all points of interest. Traces are especially helpful when digging in to find what is contained within the headers being exchanged between the client and the application.

Taking a trace with wireshark:

The free network protocol analyzer called wireshark, http://www.wireshark.org, will capture packets for you on the localhost, whether it's windows or linux. By filtering the stream of packets by IP Address, right clicking and selecting 'Follow TCP Stream' inside of wireshark, you can see the headers for both requests and responses.

Wireshark tip 1 Find the first 'SYN' in the stream, right click, 'Follow TCP Stream'.

Wireshark tip 2 Client requests are in Red, Server responses are in Blue.

Taking a trace with the Citrix Application Switch:

If the Citrix Application Switch is already in place, a trace can be run directly on the Citrix Application Switch. Running a trace will expose the flow of transactions between all points of interest, especially the client, load balancing VIPs and backend servers. Traces are especially helpful when digging in to find out if the proper headers are being exchanged between client & VIP and VIP & backend servers. A trace can be run directly on the Citrix Application Switch. Once downloaded this file can be opened and request and response headers read with Wireshark, a free network trace utility, http://www.wireshark.org. From the Citrix Application Switch GUI, navigate to NetScaler -> System -> Diagnostics -> New Trace -> Run. 

Viewing headers with Paros:

Paros was originially written for web security, but has value when viewing request and response headers, cookies and the like. Through Paros's proxy nature, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted. There is an additional option of trapping and modifying data before sending it on to the server, or client. Paros can be found at http://parosproxy.org. Free.

Viewing headers with Live HTTP Headers:

Live HTTP Headers, http://livehttpheaders.mozdev.org/, was developed for use with the Firefox web browser. It is a free add-on and allows you to view HTTP header information in real time. Free.

Viewing headers with IE Analyzer:

IEInspector HTTP Analyzer, http://www.ieinspector.com, is a tool that allows you to monitor, trace, debug and analyze HTTP/HTTPS traffic in real-time. It works with Microsoft Internet Explorer. Not-Free.

Viewing headers with IE Watch:

IEWatch, http://www.iewatch.com, is another plug-in for Microsoft Internet Explorer that helps you profile your web applications. You can use this tool to dig deep into the inner workings of web applications to find hidden issues. Not-Free.

Watch this Application Profiling Tip:

Tap into the power of AppExpert

The SAP Enterprise Service Oriented Architecture (SOA) provides a blueprint for services-based, enterprise scale business solutions that are adaptable, flexible, and open. Enterprise Services Architecture takes the concept of service-oriented architecture to a new level by transforming Web services into enterprise services. Bringing Citrix and SAP Enterprise Services Architecture together reduces the dependence on customized applications, and increases flexibility and reduces time to deployment while reducing operational expenses.

Watch this Load Balancing Tip:

Tap into the power of AppExpert

We recently had a meeting with a large partner of ours and they handed down some hefty requirements.  An average of 100 partners using their portal on any given month to access their development environments on the backend.  It was clear that NetScaler could scale, but the question was how to keep all of those partners separated from each other, without them peeking into each others traffic. It turned out to be easier than we thought using the NetScaler as an SSL VPN with the addition of some policies bound to each partner's user group.  The following is an overview of the network diagram, and there are some deployment guides to walk you through these installations. 

Recently I had to configure a virtual machine with two virtual network cards for testing purposes. One of them connects to a private virtual LAN. Another is bridged to the physical NIC card on the host and is connected to the physical LAN which is connected to the INTERNET. first I couldn get to http://www.google.com/ for example. It turned out that IE is not using the NIC that is connected to the INTERNET. How can this happen? Let me explain what I found and how I fixed it.

virtual machine runs windows 2003 server. You can try command print to show the routing table on the machine.

routing table shows two default routes with network destination of 0.0.0.0 and network mask of 0.0.0.0. Both of them have Metric of 10. I am not sure what algorithm my win2k server is using. But it seems to always pick the default route which uses the private LAN to get to http://www.google.com/ or any other external IP addresses on the INTERNET.

did the following to fix it:

the default routes using delete 0.0.0.0

the new default route using the bridged network.

Command:

-p add 0.0.0.0 mask 0.0.0.0 your default gateway here Metric 5 IF your network interface card ID here -p option to make the route persistent across reboot. I chose Metric 5 to make sure that if the default route using the virtual LAN was added back, this route has higher priority.

find out which interface uses the bridged network, check the ip address associated with the virtual network. Match the MAC address with the ones displayed in print would be easier to delete just the default route that uses the virtual LAN. But I can figure out a way to do that using this command. Do you know a better way?

guess the problem and solution is not limited to virtual machine. And there may be other solutions. Your suggestions and comments are welcome.

I had to connect to a remote desktop on a server in Germany. The funny thing is that some keys are not mapped correctly. It turned out the default keyboard is German. Switching to US keyboard solved the problem.

Here is how:

Open the regional and language options from control panel

Click text services key settings button to find out how to switch between keyboards. By default, left Alt+shift will do.

Moved Document Root

The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.

Usually the Document Root of the web server directly relates to the URL "/". But in some cases the document root should shift to some other directory. The following rules can be used to implement this.

Example : Rewrite the url / to /e/www

Apache rewrite:

RewriteEngine on
RewriteRule   ^/$  /e/www/  [R]

AppExpert rewrite: (There are two ways to do this)

add responder action act1 redirect '"/e/www/"' -bypassSafetyCheck yes
add responder policy pol1 'HTTP.REQ.URL.EQ("/")' act1
bind responder global pol1 100

add responder action act1 redirect '"/e/www"+HTTP.REQ.URL' -bypassSafetyCheck yes
add responder policy pol1 '!HTTP.REQ.URL.STARTSWITH("/e/www/")' act1
bind responder global pol1 100 END

Tap into the power of AppExpert!