Tuesday, December 25, 2012

HTTP protocol and URI fragments (#)

I've been working to create JMeter scripts for load testing an intranet web application and usually I tend to use the JMeter recording proxy, but as I was already familiar with the application and how it works and this was just another small addition to existing scripts, I just duplicated an existing HTTP Sampler and changed the path and some parameters/headers as needed. So I used Google Chrome developer tools to see what's the path I need to send the HTTP Request to and got:

So I copied the path part of the URI: "/message/1002#1003" and put it into my JMeter script, to generate the same HTTP request:

The thing is that when running this request from JMeter, I got a HTTP 500 error. I was going mad, this made no sense, running the same request with all needed headers/cookies from Chrome worked. I looked into the server's Apache access log and noted that when sending the request from JMeter for the path "/message/1002#1003", indeed there was a record for this path with a result of 500. The surprise was when I generated the same request from Google Chrome, I saw in the Apache logs that there is a request with a 200 result, but the path is "/message/1002", without the trailing "#1003"!!

That got me starting to think, why would a browser send the trailing part after the '#', it made no sense, as the application/web server don't care which part of the results we are looking for, the result will be the same with any given values after the '#' sign. It should be with the scope of the browser/client only and never sent to the HTTP server as part of the URI.

Looking at the Spec, (http://tools.ietf.org/html/rfc3986#section-3.5 - fifth paragraph) I found the approval to what I was looking for:
Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing, allowing an author to specifically identify aspects of an existing resource that are only indirectly provided by the resource owner. As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively. Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification.
For conclusion - now I know that:

  1. Google Chrome Dev tools doesn't show the real Request URL (while others like HTTP Watch do).
  2. Apache JMeter will sometimes send the values after the '#' sign in the path (HC3.1 and Java implementations will skip it, but HC4 will send it).
  3. The name for this '#' sign when speaking about the HTTP Protocol is "URI fragment".
  4. In any way - during future testing, it will make no sense to include URI fragments as part of the path, as they are only handled by the client / browser and in JMeter it make no sense.

Friday, October 26, 2012

Load and Performance Testing - JMeter based services

Hi,
After I wrote about why JMeter is better than HP LoadRunner (or Performance Center) earlier this year, I want to share few services which only exists for who choose to use JMeter.

Aside of running load tests from your own servers either inside your Data Center or on Cloud hosting, which you can do with any load testing tool, by installing and manage these servers yourself, here is a list of services which allow you to get more, for less.

These (paid/free) services are waiting for you, if you are using JMeter:

  1. BlazeMeter - don't mess around with building and managing your load testing servers. You can use this service to upload your existing JMeter scripts and resources (csv dataset files, etc) and run them from as many servers as you want, you pay for amount of servers/users you run over time and you can choose from which AWS locations to run the load test from. This service also provides nice central reporting capabilities.
  2. Gridinit - a new open source cloud load testing platform, which let you once again, utilize JMeter to run load tests from the cloud. The nice thing about this service is that you don't have to pay for anything, you can get the platform and install it on your own servers, either in the cloud or locally, and start load testing with nice web UI and some online reporting capabilities. You may also use this as a paid service and have them start needed servers in the cloud for you. Another nice feature is that you can do mixed mode load testing and utilize at once both their cloud service with combination of your own servers.
  3. Beatsoo! - a new free JMeter based application performance monitoring service. You can drop your existing JMeter scripts over there and start getting response times monitoring for your website (or any other thing your JMeter script interacts with) from world wide locations. Think how useful this is - you spend some time for load testing and improving system performance but why throwing away those scripts? Here you could re-use them for so-called "Synthetic User Monitoring" or End User Monitoring. This service will run your JMeter scripts from few world wide locations in very short intervals (around a minute or so) and allow you to compare your system performance over time and between different locations.
So here are more reasons for choosing JMeter over other load testing tools. Can you easily get you LoadRunner load tests run from several worldwide locations? Can you re-use your scripts for performance monitoring from worldwide locations?
Well, the truth about HP is that they have kinda LoadRunner SaaS but  it seems like they don't really want people to use it, as it is very expensive and it is basically a hosted Performance Center, rather than Load Testing Saas.
For re-using of the scripts for monitoring, HP have the EUM BPM but it is not available as a service neither.

Perform better, use JMeter!

Monday, October 22, 2012

Amazon EC2 N. Virginia is down

Tonight is the first time I see the AWS Management console not available after more than two years of using it. The Instances page result with an error: "Request limit exceeded" instead of a list of my instances for the N. Virginia region.


I was thinking something is broken with my connection so I cleared all my the browser caches and re-opened AWS, but it is really down.

On the AWS health dashboard only says there are performance issues with the EC2 and Elastic Beanstalk but only a note for some elevated error rate for the AWS management console... I would call it service disruption.

Let's hope the service will get back on track soon...



Friday, October 19, 2012

Internet Explorer 10 - broken link

I've developed an app which uses HTML5 capabilities and wanted to checkout which browsers are actually supporting it. I have Chrome 22 which runs it just fine and wanted to see how Firefox 16 and Internet Explorer 10 will do.

FF 16 download and installation went as expected and it actually runs my HTML5 stuff allright, the download of IE 10 is broken and I cannot even get to test it.


It seems like I will have easier life now and just skip supporting IE (anyway according to my blog statistics it seems like only 13% of my readers are using IE).

Friday, June 01, 2012

JMeter introduction presentation for Israeli audience

Last week I was one of the speakers in the Israeli Agile QA conference 2012, in front of more than 200 people from the Israeli QA industry.
Most of the speakers were very self-advertising about the products or services they offer.

On the other hand - I have nothing to sell but to spread the word about the changes coming to the load testing area, as I have the feeling that the Israeli market is really under-estimating JMeter as a product for load testing. This market controlled by HP load runner, completely.

This is changing worldwide - but in Israel we are living in some delay.



I started my presentation with the need for load testing, shared some key reasons to drive us into load testing as well as sharing some of the last couple of weeks crash stories for Israeli and world wide web sites and services, mentioning Golan Telecom, Le'an Israeli online ticketing service and Blizzard's Diablo 3 online service.

I talked about how load testing can be done:
  1. Manual load testing - which is self explaining, and while asking how many people did this in the past - I saw more than 30 hands raised, while asking how many of them did this during the last year about half of the hands remained in the air.
  2. Then I talked about HP Load Runner, asking who heard about it and got almost all hands of the crowed (very good job for HP's sales department!). Mentioning the fact the on early 90's they came with their game-changing product to allow load testing for many popular protocols. Since then the two most popular protocols which are really being used among the huge list of protocols are HTTP and Citrix. Cons: You need $$$ before you can even start thinking of load testing with this product and the fact that you will almost always end up needing to write scripts in C language + special functions they came up with in the early 90's.
  3. Now I've started to talk about JMeter, which is free, open source, you can sell it as it is to anyone and so on... and one of the important points was that the "J" in JMeter doesn't mean that this is a product for Java load testing, as usually J prefixed products do, but it only means that JMeter is written in Java and it suitable for load testing any of the supported protocols, no matter what the underlying platform is.
Later I exposed some interesting numbers from Indeed.com about jobs offering in the USA in the last years, showing a huge trend in JMeter's popularity - if about 7 years ago there was 1 JMeter job post, today there is 140 job posts! While on the same time, Load Runner popularity remained about the same, with a growth of about 20%.

The interesting fact is that JMeter is not taking over Load Runner jobs market, but it is actually making the load testing market (or the total number of jobs posted) bigger.

I then talked about the very near future with anticipating that until the end of this year (2012) there will be more JMeter job posting than Load Runner, in the USA.

As the last motivator - I talked about the doom of Load Runner, showing numbers about the popularity of Borland C, saying that if nothing big will happen with Load Runner, its popularity will look like Borland C in the next very few years.

Later I gave a ten minutes demo about how easy is to start with JMeter, making an example recording of few actions in the new web site of Golan Telecom, allowing people to join this new Israeli Cellular Network, online.


I also talked shortly about BlazeMeter, an Israeli start up utilizing JMeter to allow easily load testing with JMeter from several locations using Amazon AWS.

At last, I spoke about how to start using JMeter - referring to google for JMeter :)

Saturday, March 31, 2012

Download Java JRE/JDK 7 from shell

A bit off-topic from this blog prespective but still wanted to share this as I couldn't find an answer to this.

I've been trying to install JRE 7 on my amazon ec2 server.
The first step to do so, is to wget (download) the rpm / bin install file, right?

Well it seems like since Java7, you must accept license agreement on the download page, before you can download java, which make sense. The problem with that is that you cannot accept this license agreement if you are on shell, doing wget.

[root@X opt]# wget http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm
--2012-03-31 10:13:47--  http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm
Resolving download.oracle.com... 67.148.147.41, 67.148.147.57
Connecting to download.oracle.com|67.148.147.41|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://edelivery.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm [following]
--2012-03-31 10:13:47--  https://edelivery.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm
Resolving edelivery.oracle.com... 23.1.46.174
Connecting to edelivery.oracle.com|23.1.46.174|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://download.oracle.com/errors/download-fail-1505220.html [following]
--2012-03-31 10:13:47--  http://download.oracle.com/errors/download-fail-1505220.html
Connecting to download.oracle.com|67.148.147.41|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5307 (5.2K) [text/html]
Saving to: גdownload-fail-1505220.html.1ג
100%[==============================================================================================================================>] 5,307       --.-K/s   in 0.001s
2012-03-31 10:13:47 (3.40 MB/s) - גdownload-fail-1505220.html.1ג


So one way to work-around this is to download the file from a browser and copy over to the linux box, which for me, uploading 20MB file to amazon will take about half an hour or so..

The option I find to work around better for me is to run any network sniffer / IE developer tools / Chrome dev tools / etc and look for the final link which has the AuthParam=*.

So all you have to do now, is copy and paste this URL into your shell window like this:

[root@X opt]# wget http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm?AuthParam=1333189254_3bd4c119fa6d0056c3661e50ebc8c521
--2012-03-31 10:19:17--  http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jre-7u3-linux-x64.rpm?AuthParam=1333189254_3bd4c119fa6d0056c3661e50ebc8c521
Resolving download.oracle.com... 67.148.147.57, 67.148.147.41
Connecting to download.oracle.com|67.148.147.57|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21283819 (20M) [application/x-redhat-package-manager]
Saving to: גjre-7u3-linux-x64.rpm?AuthParam=1333189254_3bd4c119fa6d0056c3661e50ebc8c521ג
100%[==============================================================================================================================>] 21,283,819  16.9M/s   in 1.2s
2012-03-31 10:19:18 (16.9 MB/s) - גjre-7u3-linux-x64.rpm?AuthParam=1333189254_3bd4c119fa6d0056c3661e50ebc8c521ג

Good luck!

As I see many people still coming for this topic, please use the better solution described here: http://ivan-site.com/2012/05/download-oracle-java-jre-jdk-using-a-script/

Wednesday, January 11, 2012

Why Apache JMeter is better than HP Load Runner?


Few months ago I had a session with a friend of mine on performance testing and discussed the future load testing projects in his organization and on-going performance issues with current deployed systems.
During this session he shared with me his plans to invest on upgrading the current HP Performance Center 9.52 (Enterprise style Load Runner) to the new HP QC-PC 11 Platform during 2012.

It was after about a year or so I was familiar with JMeter and I was really pushing him to try it instead of Load Runner, as I found it much more reliable to work with.
I was trying to convey that instead of investing on licenses he can invest on better HR, better performance engineers.

So after some comparisons we made during this session, we got to a point where any lacking capabilities of JMeter in compare to Load Runner, is something that he can work around or live with.
The bottom line of that session was that there is nothing in Load Runner that he currently can't get out of JMeter (with some customizations and Plugins and aside of other protocols than HTTP/s).

Then he raised a question I never heard before:

What can JMeter give me, which Load Runner cannot?
I was always thinking the opposite way, always trying to compare with the leading product, with the "mature" product which is Load Runner.
I never thought that JMeter can provide something better than Load Runner other than it's being Free and Open Source.

So having this question echoing my mind for few months, I just had an enlightenment:

Community and support
JMeter has a strong supporting and prosperous community, questions asked or bugs found on the product got answers and fixes in a manner of minutes or hours (even on weekends!).
Bugs I found and reported got fixed in few hours and were publicly available on the next build (which is made on a daily basis or so).
With HP support I had a terrible experience, waiting hours for first response.
So whenever I found a bug in Load Runner I knew that if I will report it, I will probably have to wait for the next content pack or minor version for a few weeks in the good case (or usually forget about it and work-around it).
Even more than this – try googling for Load Runner errors / questions / topics and you find almost nothing that really helps you.

Scripting language
JMeter is java based, mostly you don't need to code anything, you only see a (gray) swing-based application and you easily play with test items which control the load test.

Load Runner is C based and you need to learn a propriety functions to generate the desired script.
Now who develops a web application in C? it is much easier to J2EE and even .Net developers (OO languages) to extend or work with a Java based application.

Simplicity
JMeter shows you everything you need in order to control the HTTP flow of the desired scenario, this way you know exactly what you are asking for and you know what response to expect.

Load Runner is hiding a lot in order to have a cleaner script code, this driving you crazy when you need to understand why certain things are working in a different way than what you expect.
Even with the new Ajax supporting engine "TruClient" they are doing the same trick – they hide things in these script "Levels", in order to make the script look nicer and you - a mad performance engineer who doesn't understand why the script behaves as it behaves.

Stupid-prof
JMeter force it's user to understand how web applications works, what is HTTP Request, what are headers, how a browser behaves and so on.

Load Runner is for everyone, so you find yourself trying to understand what is this load test engineer is talking about because he doesn't know what he is talking about.
I saw too many times load tests being executed by people who doesn't know the difference between a cookie and a header, or what is java script and where it being executed.
Do you want someone like this being responsible for you application performance or load stability? I wouldn't.


Conclusion
Of course JMeter has drawbacks which are fully documented on the net when comparing jmeter and load runner.
My point is that you can invest your budgets on utilities and you should, but you must invest some time in comparing the free utility with the expensive one.

In this case, if you are performance testing web based applications, JMeter may be better option for you.

Continue reading

Go to a following post on free jmeter-based cloud services.

Friday, January 21, 2011

Applications Monitoring is a Waste of Time

Organizations are making efforts on monitoring their information systems. These efforts are basically wasting the organization’s time and money.

There are great enterprise solutions from CA, IBM and others but even the leader (according to Gartner) which is HP BSM and its complementary components will fail in the basic purpose of monitoring. Not because these products monitor badly or incorrectly, but because organizations don’t understand the information they provide.

Yes you have a consolidate view of the system metrics for the relevant infra of the application, yes you do have some extra metrics from the Web Server, Application Server and DB Server.

You don’t understand which of those tens or hundreds of metrics are responsible for a failure in a case it happens and it will. There is no application with zero failures. Yes these products can analyze the historical metrics and alert when they get out of line, but who said that the historical metrics are good?

The answer in my opinion is Load and Performance Testing in order to get the metrics affect on the application performance and availability. Only when setting the relevant metrics on our monitoring systems we can fully take advantage of our investment in the monitoring solution.

I will try to convey in the following posts.

Thursday, January 13, 2011

dynaTrace Browser Cache False Positive?

I am using dynaTrace Free Edition (AJAX Edition) for couple of years now as a Browser Side profiling tool and I am really pleased with it, especially with the new features found on version 2.x.

I was working on a performance optimization project for an Intranet web application couple of weeks ago and of course dynaTrace is in my toolkit. After working with the customer and understanding he's requirements I started the analysis.

The first thing I do is working with dynaTrace to get a performance overview. The overall rank was good but I got FAIL on the caching rank. Indeed no caching headers were set on the HTTP response headers on none of the cacheable resources.

Long story short, one of the recommendations in my final performance report was to use caching headers and I also declared that according to dynaTrace, setting these headers will save about 1.5MB of network traffic and about 10 seconds (on slow network connections from remote locations in the customer's so called "LAN").

This is where the first part of the story ends, with a report recommends on putting the main effort on this no caching problem.

This week I am instructing on a Performance course for programmers and I introduced them with dynaTrace as my favorite client side / browser side profiler. I love showing examples the freestyle way and asked one of the participants to donate his web application for the science. After browsing to the homepage of the web site, I closed IE and got back to the performance report. I noticed that on his web site he got FAIL on caching rank as well and he was amazed that there was no caching.

On one of the breaks the participant asked to investigate the caching problem. We've opened the report and got found that many flash (swf), gifs, css, js files were not cached. dynaTrace says that it sums up to about 500KB of transfer size and about three seconds in download time. The participant asked to reload the page again because it can't be true, the entire load time should be less the three seconds according to his experience. I reloaded the page and indeed the reload time was faster than the first request. We've re-opened IE and try again and the load time was fast again. It seems like the browser is using a cache but on dynaTrace it keep on showing the same recommendation – "Specifying Expires Headers can save up to 500KB in transfer and up to 3 seconds in download time".

We opened the Temporary Internet Files folder and found the cacheable files which were "not cached" in it. IE is saving any file on a local cache folder even if no cache headers were provided by the web server. This is true since IE 5 (http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx#Leverage_the_HTTP_Expires_Header) and true to other browsers as well. This means that the load time of these components is faster than what prompted by dynaTrace.

When clicking on details on the resource we get to see the relevant HTTP request header and HTTP response header. In the response header we see:

1. HTTP/1.1 200 OK – which means we got a new file from the web server.

2. Content-Length 146471 bytes – which is the size of the response.



This is can't be true because we know that IE is using the files from the Temporary Internet Files folder – we see this component really fast on the browser. How can it be that dynaTrace shows a 200 OK ?

At this point I launched network sniffing tool – WireShark to see what's really going on and while working with dynaTrace in parallel I got:
1. The actual response code is not 200 OK but 304 Not Modified.

2. The actual size of the response body is not 146471 but 0 zero(no body).



So to sum things up this is what I learned:

1. Browsers will cache any resource (default configuration) even if no caching headers were provided.

2. Browsers will ask the web server if modified since on any resources on the caching folder which has no caching header (you can see it in the screen cap, the red line starting with If-None-Match).

3. Web servers have a special response when the browser already has an up-to-date resource – 304 Not Modified.

4. dynaTrace 2.1 has a bug – showing wrong information about this kind of requests.

Last thing - dynaTrace prompt for this caching problem and this is correct even with this bug. We still waste the browser's connections on asking for validation of these resources and on high latency networks this is a waste of time. If caching headers were provided, the browser wouldn't even ask to validate those resources.


Tuesday, September 01, 2009

J2EE Application Server Windows Vs. Linux Benchmark

Old debt of mine since my last post almost two years ago while comparing performance of Oracle Application Server, which is a J2EE Server, running on Windows and on Linux.

I won't post the full document which is about 30 pages but I will summarize things as OAS / IAS is deprecated after Oracle acquired BEA WebLogic Application Server.

To the point - we have build a Java simple application doing few things:
  1. I/O test:
    Reading a file located on the system disk (server side) and displaying its contents to the client.
  2. DB test:
    Executing query to an Oracle DB and displaying the result to the client.
  3. HTML test:
    Simple HTML page containing some text an few images in different sizes.
  4. Memory Leak test:
    Memory leak, by adding objects to the session and not releasing them.
We used HP's Load Runner and run some users doing each of the above actions, each action in a separate test.

At first we found that Windows and Linux (JVM) crushed and fail-back in the exact same manner when dealing with the Memory leak scenario.
The same with the queries to Oracle DB scenario (bottle-neck was with [UPDATE LATER]).

HTML test was the first time we finally got different results.
After adjusting the Apache.conf few times we got an amazing result,
Windows-based server couldn't keep up with over 300 concurrent users (bottle-neck was CPU) while in the exact same scenario Linux-based server got 1000 concurrent users (and CPU was less then 75%) !

Encouraged with our last results we continue to the last test, I/O test.
We found that Linux can handle requests much faster when parsing the exact same file with the same amount of concurrent users.
[UPDATE LATER]...

Our final conclusion is that J2EE performance is far better on Linux env rather than on Winodws env. It is extremely obvious with the HTML test (which is actually not J2EE) that Apache on Linux can handle four-times throughput than on Windows.

Feel free to ask for more information if you feel something is missing.