Showing posts with label Web Performance Best Practices. Show all posts
Showing posts with label Web Performance Best Practices. Show all posts

Jan 20, 2010

Effective usage of Online tools for web based testing

Web Standards
  • The World Wide Web Consortium (W3C) is an international consortium where Web standards are developed. Mission : To lead the WWW to its full potential by developing protocols and guidelines that ensure long-term growth for the Web
  • A major chunk of the population suffers from some of the impairment. The target segment for accessibility includes – Visual, Hearing, Old age, low Literacy, low bandwidth connections
  • Web Content Accessibility Guidelines (WCAG) - Explains to Web content developers how to make content accessible for people with disabilities
  • Section 508 and ADA (American with Disabilities Act) are laws that govern Web accessibility in US
Browser Compatibility
  • Different web browsers are created by different organizations, user-interface enhancements. The designer must devise a strategy that accounts for this possible variation to ensure that a website can still be used without the enhancement or only use features that are supported by ‘all’ browsers.
  • Testing the Browser Compatibility of Web sites across various browsers and operating systems
Readability
  • Readability is the measure of how easy to read and comprehend a document
  • Reading level algorithms only provide a rough guide, but can give a useful indication as to whether you've pitched your content at the right level for your intended audience
  • Gunning Fog, Flesch Reading Ease, and Flesch-Kincaid are reading level algorithms that can be helpful in determining how readable your content is
Web Page Speed Analysis
  • Web page speed is based on page size, composition, and download time.
  • Page weight is a measurement of the file size of a Web page that includes the combined size of all the elements of the page, including HTML files, images, audio or video, Flash animation, etc.
  • Reducing the page weight obviously improve the performance of the web site
Tools Usage

Tools

Description

HTML Validator

To check the HTML code as per W3C standards. This validator checks the markup validity of Web documents in HTML, XHTML, SMIL, MathML etc

Link Checker

To check the Link navigations as per W3C standards. Link Checker looks for issues in links, anchors and referenced objects in a Web page, or recursively on a whole Web site

CSS Validator

To check the CSS as per W3C standards

HTML WDG

To check the HTML code as per WDG standards

Juicy Studio

To check the readability of the content of the website

Page Speed Report

To analyze Web page speed

WAVE

To check for accessibility errors as per WCAG standards

All these evaluators are available with Web Accessibility Tool Bar (WAT) 2.0 for IE.

WAT 2.0 is a Free Ware provided by Web Accessibility Tools consortium. The tool aids in manual examination of web pages for a variety of aspects of accessibility. The functions are

1.Identify components of webpage

2.Provide access to alternate views of page content

3.Facilitate use of 3rd party online applications

Along with these evaluators, WAT2.0 also features tools such as Lynx viewer, Grey scale, FAE, Contrast analyzer, Vischeck color blindness simulator, Resize etc

Other Tool

http://www.webshot.org – Free Online Tool used for Cross Browser Testing

Analysis for a XXX Website

This case study provides the effective usage of free online tools available to test the XXX Website

Evaluator

Standards

Errors

Warning

HTML

W3C

123image

107image

Link Checker

W3C

1    image

110image

CSS

W3C

49 image

203image

HTML

WDG

30 image

21   image

Not an issue: Though these errors are reported, it doesn’t affect the core functionality.

Nice to have: The ease of displaying in various browsers, PDA, Pagers etc.

* All the results reported were w.r.t the XXX Website

Accessibility analysis using WAVE

Web pages

No of Errorsimage

Home page

29

Collection page

55

Product page

46

Shopping Cart

27

Sign in - check out

24

Recipient page

36

Billing page

48

Review order page

79

Not an issue: Within a given system configuration we will not have any issues.

Nice to Have: The web page is assured to meet WCAG standards and also accessible at any situation. (The errors reported are “Alt text” missing for the images, links, form labels. The error will be critical to access, if the page is not fully loaded.)

* Refer appendix for screen shot of WAVE Tool

Browser Compatibility

Browser

Versions

Browser

Versions

Avant

11.7

K-Meleon

(1.1.4), (1.5.0)

Chrome

(0.2.149.30), (1.0.154.65), (0.3.154.9), (0.4.154.25)

Konqueror

4.2

Epiphany

2.22

Minefield

(3.1), (3.2), (3.6)

Firefox

(0.8), (0.9), (1.0.8), (1.5),(2.0.0.4), (3.0.1), (3.1)

MSIE

(5.01), (6.0), (7.0)

Flock

(1.2.6), (2.03)

Navigator

9.0.06

Galeon

2.0.4

Safari

(3.2.1), (4.0)

Iceweasel

3.0.4

SeaMonkey

(1.1.14), (2.0)

Kazehakase

0.5.2

Shiretoko

(3.1), (3.5)

Opera

(8.0), ( 9.25), (10.0), (7.03), (7.11), (7.54), (8.54), (9.26), (9.27), (9.6), (9.62), (9.63), (9.64)

47 browsers showed positive results for the XXX Website. Almost all the widely used browsers were able to access the site

Evaluator

Value

Gunning Fox Index

10.89

Flesh Reading Ease

52.04

Flesh Kincaid Grade

6.92

 

  • Gunning Fox index and Flesh Kincaid, the value represents number of schoolings required to read the content. For example if the value is sixteen, the sixteen years of schoolings is required to read the content
  • For Flesh Reading Ease, the result is an index number that rates the text on a 100-point scale. The higher the score, the easier it is to understand the document. 60 – 70 is standard value and we stand at only 52.04 (Almost Near but still can reach the Standards)
Web Page Speed Analysis

Test

Units

Remarks

Status

Total HTML

1

The Total HTML should be 1

Pass

Total Objects

93

The Optimum number of object should be <20

Warning

Total Images

69

The images should be lowered for quick loading

Warning

Total CSS

5

The CSS should be lowered for quick loading

Caution

Total Size

735Kb

The optimum size should be < 100Kb

Warning

Total Script

18

The total script should be lowered for quick loading

Warning

HTML Size

67Kb

The Optimum HTML size should be <50Kb

Caution

Image Size

390Kb

The Optimum Image size should be <100Kb

Warning

Script Size

223Kb

The Optimum Script size should be <20Kb

Warning

CSS size

55Kb

The Optimum CSS Size should be <55Kb

Warning

Multi Size

0

The Multimedia size should be < 10Kb

Pass

Nice to Have: The Page size – Images, CSS, HTML can be decreased so that the pages gets loaded faster

Note: This depends on parameters like bandwidth, System Configuration etc..

Merits

The benefits on rectification of these errors are,

Clean code – Any developer could analyze the code easily.

Search Engine friendly – Search engines can track our website with ease

Faster Page Loading – A minor change can help in loading the pages quickly

Standard compliance - Publishing the standard compliance the Client can win the customer confidence

Accessibility – Easy accessibility of website across the various category of people

Once the site is W3C standard compliant, then the site shall have the W3C logo

image

Conclusion
  • The Accessibility can be improvised to WCAG standard and open a new path for Disabled customers
  • Writing web pages in accordance with the standards shortens site development time and makes pages easier to maintain. Debugging and troubleshooting become easier, because the code follows a standard
  • Cross Browser testing can ensure that the Website can be used by the largest possible audience, with minimal variation in the user-experience
  • The Readability Test provides prediction of the reading ease of the document with respect to sentence length and polysyllabic words. The results shall be used with Good writing style guidelines to increase the readability
  • Lower page load times create more comfortable visitors. The Website brand perception will be enhanced.
Screen Shots

Web Accessibility Tool bar 2.0

image

WAVE report

image

Effective usage of Online tools for web based testing

Web Standards
  • The World Wide Web Consortium (W3C) is an international consortium where Web standards are developed. Mission : To lead the WWW to its full potential by developing protocols and guidelines that ensure long-term growth for the Web
  • A major chunk of the population suffers from some of the impairment. The target segment for accessibility includes – Visual, Hearing, Old age, low Literacy, low bandwidth connections
  • Web Content Accessibility Guidelines (WCAG) - Explains to Web content developers how to make content accessible for people with disabilities
  • Section 508 and ADA (American with Disabilities Act) are laws that govern Web accessibility in US
Browser Compatibility
  • Different web browsers are created by different organizations, user-interface enhancements. The designer must devise a strategy that accounts for this possible variation to ensure that a website can still be used without the enhancement or only use features that are supported by ‘all’ browsers.
  • Testing the Browser Compatibility of Web sites across various browsers and operating systems
Readability
  • Readability is the measure of how easy to read and comprehend a document
  • Reading level algorithms only provide a rough guide, but can give a useful indication as to whether you've pitched your content at the right level for your intended audience
  • Gunning Fog, Flesch Reading Ease, and Flesch-Kincaid are reading level algorithms that can be helpful in determining how readable your content is
Web Page Speed Analysis
  • Web page speed is based on page size, composition, and download time.
  • Page weight is a measurement of the file size of a Web page that includes the combined size of all the elements of the page, including HTML files, images, audio or video, Flash animation, etc.
  • Reducing the page weight obviously improve the performance of the web site
Tools Usage

Tools

Description

HTML Validator

To check the HTML code as per W3C standards. This validator checks the markup validity of Web documents in HTML, XHTML, SMIL, MathML etc

Link Checker

To check the Link navigations as per W3C standards. Link Checker looks for issues in links, anchors and referenced objects in a Web page, or recursively on a whole Web site

CSS Validator

To check the CSS as per W3C standards

HTML WDG

To check the HTML code as per WDG standards

Juicy Studio

To check the readability of the content of the website

Page Speed Report

To analyze Web page speed

WAVE

To check for accessibility errors as per WCAG standards

All these evaluators are available with Web Accessibility Tool Bar (WAT) 2.0 for IE.

WAT 2.0 is a Free Ware provided by Web Accessibility Tools consortium. The tool aids in manual examination of web pages for a variety of aspects of accessibility. The functions are

1.Identify components of webpage

2.Provide access to alternate views of page content

3.Facilitate use of 3rd party online applications

Along with these evaluators, WAT2.0 also features tools such as Lynx viewer, Grey scale, FAE, Contrast analyzer, Vischeck color blindness simulator, Resize etc

Other Tool

http://www.webshot.org – Free Online Tool used for Cross Browser Testing

Analysis for a XXX Website

This case study provides the effective usage of free online tools available to test the XXX Website

Evaluator

Standards

Errors

Warning

HTML

W3C

123image

107image

Link Checker

W3C

1    image

110image

CSS

W3C

49 image

203image

HTML

WDG

30 image

21   image

Not an issue: Though these errors are reported, it doesn’t affect the core functionality.

Nice to have: The ease of displaying in various browsers, PDA, Pagers etc.

* All the results reported were w.r.t the XXX Website

Accessibility analysis using WAVE

Web pages

No of Errorsimage

Home page

29

Collection page

55

Product page

46

Shopping Cart

27

Sign in - check out

24

Recipient page

36

Billing page

48

Review order page

79

Not an issue: Within a given system configuration we will not have any issues.

Nice to Have: The web page is assured to meet WCAG standards and also accessible at any situation. (The errors reported are “Alt text” missing for the images, links, form labels. The error will be critical to access, if the page is not fully loaded.)

* Refer appendix for screen shot of WAVE Tool

Browser Compatibility

Browser

Versions

Browser

Versions

Avant

11.7

K-Meleon

(1.1.4), (1.5.0)

Chrome

(0.2.149.30), (1.0.154.65), (0.3.154.9), (0.4.154.25)

Konqueror

4.2

Epiphany

2.22

Minefield

(3.1), (3.2), (3.6)

Firefox

(0.8), (0.9), (1.0.8), (1.5),(2.0.0.4), (3.0.1), (3.1)

MSIE

(5.01), (6.0), (7.0)

Flock

(1.2.6), (2.03)

Navigator

9.0.06

Galeon

2.0.4

Safari

(3.2.1), (4.0)

Iceweasel

3.0.4

SeaMonkey

(1.1.14), (2.0)

Kazehakase

0.5.2

Shiretoko

(3.1), (3.5)

Opera

(8.0), ( 9.25), (10.0), (7.03), (7.11), (7.54), (8.54), (9.26), (9.27), (9.6), (9.62), (9.63), (9.64)

47 browsers showed positive results for the XXX Website. Almost all the widely used browsers were able to access the site

Evaluator

Value

Gunning Fox Index

10.89

Flesh Reading Ease

52.04

Flesh Kincaid Grade

6.92

 

  • Gunning Fox index and Flesh Kincaid, the value represents number of schoolings required to read the content. For example if the value is sixteen, the sixteen years of schoolings is required to read the content
  • For Flesh Reading Ease, the result is an index number that rates the text on a 100-point scale. The higher the score, the easier it is to understand the document. 60 – 70 is standard value and we stand at only 52.04 (Almost Near but still can reach the Standards)
Web Page Speed Analysis

Test

Units

Remarks

Status

Total HTML

1

The Total HTML should be 1

Pass

Total Objects

93

The Optimum number of object should be <20

Warning

Total Images

69

The images should be lowered for quick loading

Warning

Total CSS

5

The CSS should be lowered for quick loading

Caution

Total Size

735Kb

The optimum size should be < 100Kb

Warning

Total Script

18

The total script should be lowered for quick loading

Warning

HTML Size

67Kb

The Optimum HTML size should be <50Kb

Caution

Image Size

390Kb

The Optimum Image size should be <100Kb

Warning

Script Size

223Kb

The Optimum Script size should be <20Kb

Warning

CSS size

55Kb

The Optimum CSS Size should be <55Kb

Warning

Multi Size

0

The Multimedia size should be < 10Kb

Pass

Nice to Have: The Page size – Images, CSS, HTML can be decreased so that the pages gets loaded faster

Note: This depends on parameters like bandwidth, System Configuration etc..

Merits

The benefits on rectification of these errors are,

Clean code – Any developer could analyze the code easily.

Search Engine friendly – Search engines can track our website with ease

Faster Page Loading – A minor change can help in loading the pages quickly

Standard compliance - Publishing the standard compliance the Client can win the customer confidence

Accessibility – Easy accessibility of website across the various category of people

Once the site is W3C standard compliant, then the site shall have the W3C logo

image

Conclusion
  • The Accessibility can be improvised to WCAG standard and open a new path for Disabled customers
  • Writing web pages in accordance with the standards shortens site development time and makes pages easier to maintain. Debugging and troubleshooting become easier, because the code follows a standard
  • Cross Browser testing can ensure that the Website can be used by the largest possible audience, with minimal variation in the user-experience
  • The Readability Test provides prediction of the reading ease of the document with respect to sentence length and polysyllabic words. The results shall be used with Good writing style guidelines to increase the readability
  • Lower page load times create more comfortable visitors. The Website brand perception will be enhanced.
Screen Shots

Web Accessibility Tool bar 2.0

image

WAVE report

image

Nov 21, 2009

Performance Benchmarks a Webserver

ApacheBench is a command line computer program for measuring the performance of HTTP web servers, in particular the Apache HTTP Server. It was designed to give an idea of the performance that a given Apache installation can provide. In particular, it shows how many requests per second the server is capable of serving.

The ab tool comes bundled with the standard Apache source distribution, and like the Apache web server itself, is free, open source software and distributed under the terms of the Apache License.

The performance is usually measured in terms of:

  • Number of requests that can be served per second (depending on the type of request, etc.);
  • Latency response time in milliseconds for each new connection or request;
  • Throughput in bytes per second (depending on file size, cached or not cached content, available network bandwidth, etc.).

The measurements must be performed under a varying load of clients and requests per client.

ab [ -A auth-username:password ] [ -c concurrency ] 
[ -C cookie-name=value ] [ -d ] [ -e csv-file ]
[ -g gnuplot-file ] [ -h] [ -H custom-header ]
[ -i ] [ -k ] [ -n requests ] [ -p POST-file ]
[ -P proxy-auth-username:password ]
[ -q ] [ -s ] [ -S] [ -t timelimit ] [ -T content-type ]
[ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ]
[ -X proxy[:port] ] [ -y <tr>-attributes ]
[ -z <td>-attributes ] [http://]hostname[:port]/path



Options


-A auth-username: password



Supply BASIC Authentication credentials to the server. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the server needs it



-c concurrency



Number of multiple requests to perform at a time. Default is one request at a time.



-C cookie-name= value



Add a Cookie: line to the request. The argument is typically in the form of a name=value pair. This field is repeatable.



-d 



Do not display the "percentage served within XX [ms] table". (legacy support).



-e csv-file



Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the  requests. This is usually more useful than the 'gnuplot' file; as the results are already 'binned'.



-g gnuplot-file



Write all measured values out as a 'gnuplot' or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are on the first line of the file.



-h



Display usage information.



-H custom-header



Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").



-i



Do HEAD requests instead of GET.



-k



Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.



-n requests



Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.



-p POST-file



File containing data to POST.



-P proxy-auth-username: password



Supply BASIC Authentication credentials to a proxy en-route. The username and  password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the proxy needs it (i.e., has sent an 407 proxy authentication needed).



-q



When processing more than 150 requests, ab outputs a progress count on stderr every 10% or 100 requests or so. The -q flag will suppress these messages.



-s



When compiled in (ab -h will show you) use the SSL protected https rather than the http protocol. This feature is experimental and very rudimentary. You probably do not want to use it.



-S



Do not display the median and standard deviation values, nor display the  warning/error messages when the average and median are more than one or two times the standard deviation apart. And default to the min/avg/max values. (legacy support).



-t timelimit



Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount of time. Per default there is no timelimit.



-T content-type



Content-type header to use for POST data.



-v verbosity



Set verbosity level - 4 and above prints information on headers, 3 and above prints  response codes (404, 200, etc.), 2 and above prints warnings and info. 



-V



Display version number and exit.



-w



Print out results in HTML tables. Default table is two columns wide, with a white background.



-x <table>-attributes



String to use as attributes for <table>. Attributes are inserted <table here >.



-X proxy[: port]



Use a proxy server for the requests.



-y <tr>-attributes



String to use as attributes for <tr>.



-z <td>-attributes



String to use as attributes for <td>.



Apache Benchmark Procedures




  • First record server load using top or uptime command


  • Take at least 3-5 readings and use the best result


  • After each test reboot the server and carry out test on next configuration (web server)


  • Again record server load using top or uptime command


  • Carry on test using static html/php files and dynamic pages


  • It also important to carry out test using the Non-KeepAlive and KeepAlive (the Keep-Alive extension to provide long-lived HTTP sessions, which allow multiple requests to be sent over the same TCP connection) features



Note down server load using uptime command

$ uptime



Create a static (small) html page as follows (snkpage.html) (assuming that server IP is 202.54.200.1) in /var/www/html (or use your own webroot):




<html>
<head>
<title>Webserver test</title>
</head>
<body>
This is a webserver test page.
</body>
</html>



Login to Linux/bsd desktop computer and type following command:



$ ab -n 1000 -c 5 http://202.54.200.1/snkpage.html 



Where,




  • -n 1000: ab will send 1000 number of requests to server 202.54.200.1 in order to perform for the benchmarking session


  • -c 5 : 5 is concurrency number i.e. ab will send 5 number of multiple requests to perform at a time to server 202.54.200.1


  • For example if you want to send 10 request, type following command:

    $ ab -n 10 -c 2 http://www.somewhere.com/



Output




This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0 
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.cyberciti.biz (be patient).....done
Server Software:
Server Hostname: www.somewhere.com
Server Port: 80
Document Path: /
Document Length: 16289 bytes
Concurrency Level: 1
Time taken for tests: 16.885975 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 166570 bytes
HTML transferred: 162890 bytes
Requests per second: 0.59 [#/sec] (mean)
Time per request: 1688.597 [ms] (mean)
Time per request: 1688.597 [ms] (mean, across all concurrent requests)
Transfer rate: 9.59 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 353 375 16.1 386 391
Processing: 1240 1312 52.1 1339 1369
Waiting: 449 472 16.2 476 499
Total: 1593 1687 67.7 1730 1756
Percentage of the requests served within a certain time (ms)
50% 1730
66% 1733
75% 1741
80% 1753
90% 1756
95% 1756
98% 1756
99% 1756
100% 1756 (longest request)



Repeat above command 3-5 times and save the best reading.



Use -k option that enables the HTTP KeepAlive feature using ab test tool. For example:



$ ab -k -n 1000 -c 5 http://202.54.200.1/snkpage.html



Use -e option that allows to write a comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the requests:



$ ab -k -n 50000 -c 2 -e apache2r1.cvs http://202.54.200.1/snkpage.html 



After displaying some status reports every 100 requests or so, it will print out a fairly detailed report, including document length, bytes transferred, completed and failed requests, requests per second and some statistics on connection times.


Performance Benchmarks a Webserver

ApacheBench is a command line computer program for measuring the performance of HTTP web servers, in particular the Apache HTTP Server. It was designed to give an idea of the performance that a given Apache installation can provide. In particular, it shows how many requests per second the server is capable of serving.

The ab tool comes bundled with the standard Apache source distribution, and like the Apache web server itself, is free, open source software and distributed under the terms of the Apache License.

The performance is usually measured in terms of:

  • Number of requests that can be served per second (depending on the type of request, etc.);
  • Latency response time in milliseconds for each new connection or request;
  • Throughput in bytes per second (depending on file size, cached or not cached content, available network bandwidth, etc.).

The measurements must be performed under a varying load of clients and requests per client.

ab [ -A auth-username:password ] [ -c concurrency ] 
[ -C cookie-name=value ] [ -d ] [ -e csv-file ]
[ -g gnuplot-file ] [ -h] [ -H custom-header ]
[ -i ] [ -k ] [ -n requests ] [ -p POST-file ]
[ -P proxy-auth-username:password ]
[ -q ] [ -s ] [ -S] [ -t timelimit ] [ -T content-type ]
[ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ]
[ -X proxy[:port] ] [ -y <tr>-attributes ]
[ -z <td>-attributes ] [http://]hostname[:port]/path



Options


-A auth-username: password



Supply BASIC Authentication credentials to the server. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the server needs it



-c concurrency



Number of multiple requests to perform at a time. Default is one request at a time.



-C cookie-name= value



Add a Cookie: line to the request. The argument is typically in the form of a name=value pair. This field is repeatable.



-d 



Do not display the "percentage served within XX [ms] table". (legacy support).



-e csv-file



Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the  requests. This is usually more useful than the 'gnuplot' file; as the results are already 'binned'.



-g gnuplot-file



Write all measured values out as a 'gnuplot' or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are on the first line of the file.



-h



Display usage information.



-H custom-header



Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").



-i



Do HEAD requests instead of GET.



-k



Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.



-n requests



Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.



-p POST-file



File containing data to POST.



-P proxy-auth-username: password



Supply BASIC Authentication credentials to a proxy en-route. The username and  password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the proxy needs it (i.e., has sent an 407 proxy authentication needed).



-q



When processing more than 150 requests, ab outputs a progress count on stderr every 10% or 100 requests or so. The -q flag will suppress these messages.



-s



When compiled in (ab -h will show you) use the SSL protected https rather than the http protocol. This feature is experimental and very rudimentary. You probably do not want to use it.



-S



Do not display the median and standard deviation values, nor display the  warning/error messages when the average and median are more than one or two times the standard deviation apart. And default to the min/avg/max values. (legacy support).



-t timelimit



Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount of time. Per default there is no timelimit.



-T content-type



Content-type header to use for POST data.



-v verbosity



Set verbosity level - 4 and above prints information on headers, 3 and above prints  response codes (404, 200, etc.), 2 and above prints warnings and info. 



-V



Display version number and exit.



-w



Print out results in HTML tables. Default table is two columns wide, with a white background.



-x <table>-attributes



String to use as attributes for <table>. Attributes are inserted <table here >.



-X proxy[: port]



Use a proxy server for the requests.



-y <tr>-attributes



String to use as attributes for <tr>.



-z <td>-attributes



String to use as attributes for <td>.



Apache Benchmark Procedures




  • First record server load using top or uptime command


  • Take at least 3-5 readings and use the best result


  • After each test reboot the server and carry out test on next configuration (web server)


  • Again record server load using top or uptime command


  • Carry on test using static html/php files and dynamic pages


  • It also important to carry out test using the Non-KeepAlive and KeepAlive (the Keep-Alive extension to provide long-lived HTTP sessions, which allow multiple requests to be sent over the same TCP connection) features



Note down server load using uptime command

$ uptime



Create a static (small) html page as follows (snkpage.html) (assuming that server IP is 202.54.200.1) in /var/www/html (or use your own webroot):




<html>
<head>
<title>Webserver test</title>
</head>
<body>
This is a webserver test page.
</body>
</html>



Login to Linux/bsd desktop computer and type following command:



$ ab -n 1000 -c 5 http://202.54.200.1/snkpage.html 



Where,




  • -n 1000: ab will send 1000 number of requests to server 202.54.200.1 in order to perform for the benchmarking session


  • -c 5 : 5 is concurrency number i.e. ab will send 5 number of multiple requests to perform at a time to server 202.54.200.1


  • For example if you want to send 10 request, type following command:

    $ ab -n 10 -c 2 http://www.somewhere.com/



Output




This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0 
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.cyberciti.biz (be patient).....done
Server Software:
Server Hostname: www.somewhere.com
Server Port: 80
Document Path: /
Document Length: 16289 bytes
Concurrency Level: 1
Time taken for tests: 16.885975 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 166570 bytes
HTML transferred: 162890 bytes
Requests per second: 0.59 [#/sec] (mean)
Time per request: 1688.597 [ms] (mean)
Time per request: 1688.597 [ms] (mean, across all concurrent requests)
Transfer rate: 9.59 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 353 375 16.1 386 391
Processing: 1240 1312 52.1 1339 1369
Waiting: 449 472 16.2 476 499
Total: 1593 1687 67.7 1730 1756
Percentage of the requests served within a certain time (ms)
50% 1730
66% 1733
75% 1741
80% 1753
90% 1756
95% 1756
98% 1756
99% 1756
100% 1756 (longest request)



Repeat above command 3-5 times and save the best reading.



Use -k option that enables the HTTP KeepAlive feature using ab test tool. For example:



$ ab -k -n 1000 -c 5 http://202.54.200.1/snkpage.html



Use -e option that allows to write a comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the requests:



$ ab -k -n 50000 -c 2 -e apache2r1.cvs http://202.54.200.1/snkpage.html 



After displaying some status reports every 100 requests or so, it will print out a fairly detailed report, including document length, bytes transferred, completed and failed requests, requests per second and some statistics on connection times.


Oct 9, 2009

An introduction to JavaScript Object Notation (JSON)

JSON (JavaScript Object Notation)

JSON (JavaScript Object Notation) is a lightweight computer data interchange format. It is a text-based, human-readable format for representing simple data structures and associative arrays (called objects).It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

The JSON file extension is .json.Many of the Yahoo! Web Services provide JSON as an alternate output format to XML


XML Crossroads: The Browser and Ajax

When designing an application that will communicate with a remote computer, a data format and exchange protocol must be selected. While XML works well for many application scenarios, it has some drawbacks that make it less than ideal for others. One such space where XML is often less than ideal is with Ajax-style web applications.

Ajax allows Web-enabled applications to perform out-of-band client-server calls, establishing a separate channel on which to send and receive information from remote Web services. In layman's terms, updates and navigation sequences in Ajax applications are done outside the classical client-server context, which entails a complete screen refresh, with the information being received in the background (a.k.a out-of-band).

Ajax is a technique used for building interactive web applications that provide a snappier user experience through the use of out-of-band, lightweight calls to the web server in lieu of full-page postbacks. These asynchronous calls are initiated on the client using JavaScript and involve formatting data, sending it to a web server, and parsing and working with the returned data.

These application updates that are typically obtained from RESTful Web services, once received in a user's browser, need to be incorporated in the overall HTML page layout, which is exactly where XML proves to be more than a handful. Though the capabilities of most mainstream browsers have increased over the years with the support of scripting languages and plug-in support, many programming tasks still remain difficult or unnatural to perform, one of them being manipulating and processing text, which is typically done using DOM.

The complexity in using DOM lies in its function-based roots, with a simple modification or access to a data tree requiring numerous method calls. In addition, DOM is known for differing implementation details among various browsers; this process takes us to a very elaborate programming scheme with ample possibilities for a breakdown in cross-browser compatibility. So the outstanding question now becomes: How can a markup language be easily integrated into an HTML layout page to accommodate Ajax requirements?

The answer comes in the form of leveraging a common component in all mainstream browsers: The JavaScript engine. Instead of delivering Ajax updates in a format such as XML, which would require the use of a mechanism like DOM to access and incorporate data into a layout, a more natural and intuitive approach would be using a format that fits natively to the aforementioned engine, namely JSON.

Though the x in Ajax stands for XML, and Web services have come to the forefront by the steady use of this same format, it doesn't necessarily mean such an approach is cast in stone. As we have seen, XML has a few drawbacks when applied to Ajax-enabled applications, due to the text-processing capabilities in browsers. In this sense, JSON has emerged to provide a compelling alternative in this same context.

JSON has come to the attention of Web service providers as a lighter and friendlier format for Web services clients in the form of a browser, or what would essentially be an Ajax-enabled application accessing RESTful Web services.


JSON vs XML

Both JSON and XML can be used to represent native, in-memory objects in a text-based, human-readable, data exchange format. Furthermore, the two data exchange formats are isomorphic—given text in one format, an equivalent one is conceivable in the other.

For example, when calling one of Yahoo!'s publicly accessible web services, you can indicate via a querystring parameter whether the response should be formatted as XML or JSON. Therefore, when deciding upon a data exchange format, it's not a simple matter of choosing one over the other as a silver bullet, but rather what format has the characteristics that make it the best choice for a particular application.

For example, XML has its roots in marking-up document text and tends to shine very well in that space (as is evident with XHTML). JSON, on the other hand, has its roots in programming language types and structures and therefore provides a more natural and readily available mapping to exchange structured data. The following table will help you to understand and compare the key characteristics of XML and JSON.


Differences between XML and JSON

Characteristic

XML

JSON

Data types

Does not provide any notion of data types. One must rely on XML Schema for adding type information.

Provides scalar data types and the ability to express structured data through arrays and objects.

Support for arrays

Arrays have to be expressed by conventions, for example through the use of an outer placeholder element that models the arrays contents as inner elements. Typically, the outer element uses the plural form of the name used for inner elements.

Native array support.

Support for objects

Objects have to be expressed by conventions, often through a mixed use of attributes and elements.

Native object support.

Null support

Requires use of xsi:nil on elements in an XML instance document plus an import of the corresponding namespace.

Natively recognizes the null value.

Comments

Native support and usually available through APIs.

Not supported.

Namespaces

Supports namespaces, which eliminates the risk of name collisions when combining documents. Namespaces also allow existing XML-based standards to be safely extended.

No concept of namespaces. Naming collisions are usually avoided by nesting objects or using a prefix in an object member name (the former is preferred in practice).

Formatting decisions

Complex. Requires a greater effort to decide how to map application types to XML elements and attributes. Can create heated debates whether an element-centric or attribute-centric approach is better.

Simple. Provides a much more direct mapping for application data. The only exception may be the absence of date/time literal.

Size

Documents tend to be lengthy in size, especially when an element-centric approach to formatting is used.

Syntax is very terse and yields formatted text where most of the space is consumed (rightly so) by the represented data.

Parsing in JavaScript

Requires an XML DOM implementation and additional application code to map text back into JavaScript objects.

No additional application code required to parse text; can use JavaScript's eval function.

Learning curve

Generally tends to require use of several technologies in concert: XPath, XML Schema, XSLT, XML Namespaces, the DOM, and so on.

Very simple technology stack that is already familiar to developers with a background in JavaScript or other dynamic programming languages.

JSON is a relatively new data exchange format and does not have the years of adoption or vendor support that XML enjoys today (although JSON is catching up quickly). The following table highlights the current state of affairs in the XML and JSON spaces.


Support Differences between XML and JSON

Support

XML

JSON

Tools

Enjoys a mature set of tools widely available from many industry vendors.

Rich tool support—such as editors and formatters—is scarce.

Microsoft .NET Framework

Very good and mature support since version 1.0 of the .NET Framework. XML support is available as part of the Base Class Library (BCL). For unmanaged environments, there is MSXML.

None so far, except an initial implementation as part of ASP.NET AJAX.

Platform and language

Parsers and formatters are widely available on many platforms and languages (commercial and open source implementations).

Parsers and formatters are available already on many platforms and in many languages. Consult json.org for a good set of references. Most implementations for now tend to be open source projects.

Integrated language

Industry vendors are currently experimenting with support literally within languages. See Microsoft's LINQ project for more information.

Is natively supported in JavaScript/ECMAScript only.




Structure of JSON

JSON is built on two structures:

· A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

· An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.

In JSON, they take on these forms:

An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).

clip_image001

An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma).

clip_image002

A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested.

clip_image003

A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string. A string is very much like a C or Java string.

clip_image004

A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.

clip_image005

Whitespace can be inserted between any pair of tokens.


Benefits

The benefit of using JSON' is easier data access. The internal representation used by JavaScript engines for data structures like strings, arrays, and objects are precisely these same characters. This leads us is to a more straightforward approach for accessing data than the alternate DOM technique

An added benefit of JSON is its less verbose nature. In XML, the opening and closing of tags is a necessity just for markup compliance, but in JSON's case all that's required is a simple bracket for closure. In data exchanges comprising a hundred or more fields, this additional XML markup can add to transit times. There is no formal study concluding that JSON is more efficient than XML over the wire; it's simply a matter of byte-to-byte comparison, where an equivalent JSON and XML payload is always smaller in the former than in the latter format.

Additionally, JSON has garnered the attention of many developers specializing in different programming languages, giving way to libraries capable of producing this format from environments as diverse as Haskell and Lisp to more mainstream options like C# and PHP.


Constraints

JSON lacks a few of XML's properties. Namespaces, which allow the mixing of identical pieces of information in different contexts, is clearly missing in JSON.

Another differing feature is that of attributes, since every JSON assignment is done with colons (:); when transforming XML to JSON it can be difficult to distinguish between what would be considered text between tags—XML CDATA—and the actual value of attributes.

You may also find the actual creation and validation of JSON a little more complex than an average XML fragment. In this sense, it may be that XML has had a head start in terms of developing tools for its processing.

Another constraint of JSON is the lack of a date/time literal. The simple explanation for the absence of a date/time literal is that JavaScript never had one either: The support for date and time values in JavaScript is entirely provided through the Date object. Most applications using JSON as a data format, therefore, generally tend to use either a string or a number to express date and time values.


From JavaScript Literals to JSON

JSON is a data exchange format that was created from a subset of the literal object notation in JavaScript. While the syntax accepted by JavaScript for literal values is very flexible, it is important to note that JSON has much stricter rules. According to the JSON standard, for example, the name of an object member must be a valid JSON string. A string in JSON must be enclosed in quotation marks. JavaScript, on the other hand, allows object member names to be delimited by quotation marks or apostrophes or to omit quoting altogether so long as the member name doesn't conflict with a reserved JavaScript keyword. Likewise, an array element or an object member value in JSON is limited to a very limited set. In JavaScript, however, array elements and object member values can refer to pretty much any valid JavaScript expression, including function calls and definitions!

The charm of JSON is in its simplicity. A message formatted according to the JSON standard is composed of a single top-level object or array. The array elements and object values can be objects, arrays, strings, numbers, Boolean values (true and false), or null.


Working with JSON in the .NET Framework

Starting out as a couple of static methods for escaping JavaScript strings, Json.NET evolved as features were added. To add support for reading JSON a major refactor was required and Json.NET will split into the three major classes it still uses today, JsonReader, JsonWriter and JsonSerializer.Json.NET was first released in June 2006.

JSON text can easily be created and parsed from JavaScript code, which is part of its allure. However, when JSON is used in an ASP.NET web application, only the browser enjoys JavaScript support since the server-side code is most likely written in Visual Basic or C#.

Most Ajax libraries designed for ASP.NET provide support for programmatically creating and parsing JSON text. Therefore, to work with JSON in a .NET application, consider using one of these libraries. There are plenty of open-source and third-party options, and Microsoft also has their own Ajax library named ASP.NET AJAX.

One of the example is Jayrock, an open-source implementation of JSON for the Microsoft .NET Framework

Working with JSON in .NET using Jayrock is similar to working with XML through the XmlWriter, XmlReader, and XmlSerializer classes in the .NET Framework. The classes JsonWriter, JsonReader, JsonTextWriter, and JsonTextReader found in Jayrock mimic the semantics of the .NET Framework classes XmlWriter, XmlReader, XmlTextWriter, and XmlTextReader. These classes are useful for interfacing with JSON at a low- and stream-oriented level. Using these classes, JSON text can be created or parsed piecemeal through a series of method calls. For example, using the JsonWriter class method WriteNumber(number) writes out the appropriate string representation of number according to the JSON standard. The JsonConvert class offers Export and Import methods for converting between .NET types and JSON. These methods provide a similar functionality as found in the XmlSerializer class methods Serialize and Deserialize, respectively.


Conclusion

JSON is a lightweight, text-based data exchange format based on a subset of the literal notation from the JavaScript programming language. It provides a succinct encoding for application data structures and is typically used in scenarios where a JavaScript implementation is available to one or both of the applications exchanging data, such as in Ajax-style web applications. The allure of JSON lies in its simplicity to understand, adopt, and implement. JSON has virtually no learning curve for developers already familiar with JavaScript or other programming languages with similar support for a rich literal notation (like Python and Ruby). Parsing JSON text in JavaScript code can be accomplished by simply calling the eval function, and creating JSON text is a breeze with the json.js script provided at http://www.json.org/json.js.


References:

An introduction to JavaScript Object Notation (JSON)

JSON (JavaScript Object Notation)

JSON (JavaScript Object Notation) is a lightweight computer data interchange format. It is a text-based, human-readable format for representing simple data structures and associative arrays (called objects).It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

The JSON file extension is .json.Many of the Yahoo! Web Services provide JSON as an alternate output format to XML


XML Crossroads: The Browser and Ajax

When designing an application that will communicate with a remote computer, a data format and exchange protocol must be selected. While XML works well for many application scenarios, it has some drawbacks that make it less than ideal for others. One such space where XML is often less than ideal is with Ajax-style web applications.

Ajax allows Web-enabled applications to perform out-of-band client-server calls, establishing a separate channel on which to send and receive information from remote Web services. In layman's terms, updates and navigation sequences in Ajax applications are done outside the classical client-server context, which entails a complete screen refresh, with the information being received in the background (a.k.a out-of-band).

Ajax is a technique used for building interactive web applications that provide a snappier user experience through the use of out-of-band, lightweight calls to the web server in lieu of full-page postbacks. These asynchronous calls are initiated on the client using JavaScript and involve formatting data, sending it to a web server, and parsing and working with the returned data.

These application updates that are typically obtained from RESTful Web services, once received in a user's browser, need to be incorporated in the overall HTML page layout, which is exactly where XML proves to be more than a handful. Though the capabilities of most mainstream browsers have increased over the years with the support of scripting languages and plug-in support, many programming tasks still remain difficult or unnatural to perform, one of them being manipulating and processing text, which is typically done using DOM.

The complexity in using DOM lies in its function-based roots, with a simple modification or access to a data tree requiring numerous method calls. In addition, DOM is known for differing implementation details among various browsers; this process takes us to a very elaborate programming scheme with ample possibilities for a breakdown in cross-browser compatibility. So the outstanding question now becomes: How can a markup language be easily integrated into an HTML layout page to accommodate Ajax requirements?

The answer comes in the form of leveraging a common component in all mainstream browsers: The JavaScript engine. Instead of delivering Ajax updates in a format such as XML, which would require the use of a mechanism like DOM to access and incorporate data into a layout, a more natural and intuitive approach would be using a format that fits natively to the aforementioned engine, namely JSON.

Though the x in Ajax stands for XML, and Web services have come to the forefront by the steady use of this same format, it doesn't necessarily mean such an approach is cast in stone. As we have seen, XML has a few drawbacks when applied to Ajax-enabled applications, due to the text-processing capabilities in browsers. In this sense, JSON has emerged to provide a compelling alternative in this same context.

JSON has come to the attention of Web service providers as a lighter and friendlier format for Web services clients in the form of a browser, or what would essentially be an Ajax-enabled application accessing RESTful Web services.


JSON vs XML

Both JSON and XML can be used to represent native, in-memory objects in a text-based, human-readable, data exchange format. Furthermore, the two data exchange formats are isomorphic—given text in one format, an equivalent one is conceivable in the other.

For example, when calling one of Yahoo!'s publicly accessible web services, you can indicate via a querystring parameter whether the response should be formatted as XML or JSON. Therefore, when deciding upon a data exchange format, it's not a simple matter of choosing one over the other as a silver bullet, but rather what format has the characteristics that make it the best choice for a particular application.

For example, XML has its roots in marking-up document text and tends to shine very well in that space (as is evident with XHTML). JSON, on the other hand, has its roots in programming language types and structures and therefore provides a more natural and readily available mapping to exchange structured data. The following table will help you to understand and compare the key characteristics of XML and JSON.


Differences between XML and JSON

Characteristic

XML

JSON

Data types

Does not provide any notion of data types. One must rely on XML Schema for adding type information.

Provides scalar data types and the ability to express structured data through arrays and objects.

Support for arrays

Arrays have to be expressed by conventions, for example through the use of an outer placeholder element that models the arrays contents as inner elements. Typically, the outer element uses the plural form of the name used for inner elements.

Native array support.

Support for objects

Objects have to be expressed by conventions, often through a mixed use of attributes and elements.

Native object support.

Null support

Requires use of xsi:nil on elements in an XML instance document plus an import of the corresponding namespace.

Natively recognizes the null value.

Comments

Native support and usually available through APIs.

Not supported.

Namespaces

Supports namespaces, which eliminates the risk of name collisions when combining documents. Namespaces also allow existing XML-based standards to be safely extended.

No concept of namespaces. Naming collisions are usually avoided by nesting objects or using a prefix in an object member name (the former is preferred in practice).

Formatting decisions

Complex. Requires a greater effort to decide how to map application types to XML elements and attributes. Can create heated debates whether an element-centric or attribute-centric approach is better.

Simple. Provides a much more direct mapping for application data. The only exception may be the absence of date/time literal.

Size

Documents tend to be lengthy in size, especially when an element-centric approach to formatting is used.

Syntax is very terse and yields formatted text where most of the space is consumed (rightly so) by the represented data.

Parsing in JavaScript

Requires an XML DOM implementation and additional application code to map text back into JavaScript objects.

No additional application code required to parse text; can use JavaScript's eval function.

Learning curve

Generally tends to require use of several technologies in concert: XPath, XML Schema, XSLT, XML Namespaces, the DOM, and so on.

Very simple technology stack that is already familiar to developers with a background in JavaScript or other dynamic programming languages.

JSON is a relatively new data exchange format and does not have the years of adoption or vendor support that XML enjoys today (although JSON is catching up quickly). The following table highlights the current state of affairs in the XML and JSON spaces.


Support Differences between XML and JSON

Support

XML

JSON

Tools

Enjoys a mature set of tools widely available from many industry vendors.

Rich tool support—such as editors and formatters—is scarce.

Microsoft .NET Framework

Very good and mature support since version 1.0 of the .NET Framework. XML support is available as part of the Base Class Library (BCL). For unmanaged environments, there is MSXML.

None so far, except an initial implementation as part of ASP.NET AJAX.

Platform and language

Parsers and formatters are widely available on many platforms and languages (commercial and open source implementations).

Parsers and formatters are available already on many platforms and in many languages. Consult json.org for a good set of references. Most implementations for now tend to be open source projects.

Integrated language

Industry vendors are currently experimenting with support literally within languages. See Microsoft's LINQ project for more information.

Is natively supported in JavaScript/ECMAScript only.




Structure of JSON

JSON is built on two structures:

· A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

· An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.

In JSON, they take on these forms:

An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).

clip_image001

An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma).

clip_image002

A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested.

clip_image003

A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string. A string is very much like a C or Java string.

clip_image004

A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.

clip_image005

Whitespace can be inserted between any pair of tokens.


Benefits

The benefit of using JSON' is easier data access. The internal representation used by JavaScript engines for data structures like strings, arrays, and objects are precisely these same characters. This leads us is to a more straightforward approach for accessing data than the alternate DOM technique

An added benefit of JSON is its less verbose nature. In XML, the opening and closing of tags is a necessity just for markup compliance, but in JSON's case all that's required is a simple bracket for closure. In data exchanges comprising a hundred or more fields, this additional XML markup can add to transit times. There is no formal study concluding that JSON is more efficient than XML over the wire; it's simply a matter of byte-to-byte comparison, where an equivalent JSON and XML payload is always smaller in the former than in the latter format.

Additionally, JSON has garnered the attention of many developers specializing in different programming languages, giving way to libraries capable of producing this format from environments as diverse as Haskell and Lisp to more mainstream options like C# and PHP.


Constraints

JSON lacks a few of XML's properties. Namespaces, which allow the mixing of identical pieces of information in different contexts, is clearly missing in JSON.

Another differing feature is that of attributes, since every JSON assignment is done with colons (:); when transforming XML to JSON it can be difficult to distinguish between what would be considered text between tags—XML CDATA—and the actual value of attributes.

You may also find the actual creation and validation of JSON a little more complex than an average XML fragment. In this sense, it may be that XML has had a head start in terms of developing tools for its processing.

Another constraint of JSON is the lack of a date/time literal. The simple explanation for the absence of a date/time literal is that JavaScript never had one either: The support for date and time values in JavaScript is entirely provided through the Date object. Most applications using JSON as a data format, therefore, generally tend to use either a string or a number to express date and time values.


From JavaScript Literals to JSON

JSON is a data exchange format that was created from a subset of the literal object notation in JavaScript. While the syntax accepted by JavaScript for literal values is very flexible, it is important to note that JSON has much stricter rules. According to the JSON standard, for example, the name of an object member must be a valid JSON string. A string in JSON must be enclosed in quotation marks. JavaScript, on the other hand, allows object member names to be delimited by quotation marks or apostrophes or to omit quoting altogether so long as the member name doesn't conflict with a reserved JavaScript keyword. Likewise, an array element or an object member value in JSON is limited to a very limited set. In JavaScript, however, array elements and object member values can refer to pretty much any valid JavaScript expression, including function calls and definitions!

The charm of JSON is in its simplicity. A message formatted according to the JSON standard is composed of a single top-level object or array. The array elements and object values can be objects, arrays, strings, numbers, Boolean values (true and false), or null.


Working with JSON in the .NET Framework

Starting out as a couple of static methods for escaping JavaScript strings, Json.NET evolved as features were added. To add support for reading JSON a major refactor was required and Json.NET will split into the three major classes it still uses today, JsonReader, JsonWriter and JsonSerializer.Json.NET was first released in June 2006.

JSON text can easily be created and parsed from JavaScript code, which is part of its allure. However, when JSON is used in an ASP.NET web application, only the browser enjoys JavaScript support since the server-side code is most likely written in Visual Basic or C#.

Most Ajax libraries designed for ASP.NET provide support for programmatically creating and parsing JSON text. Therefore, to work with JSON in a .NET application, consider using one of these libraries. There are plenty of open-source and third-party options, and Microsoft also has their own Ajax library named ASP.NET AJAX.

One of the example is Jayrock, an open-source implementation of JSON for the Microsoft .NET Framework

Working with JSON in .NET using Jayrock is similar to working with XML through the XmlWriter, XmlReader, and XmlSerializer classes in the .NET Framework. The classes JsonWriter, JsonReader, JsonTextWriter, and JsonTextReader found in Jayrock mimic the semantics of the .NET Framework classes XmlWriter, XmlReader, XmlTextWriter, and XmlTextReader. These classes are useful for interfacing with JSON at a low- and stream-oriented level. Using these classes, JSON text can be created or parsed piecemeal through a series of method calls. For example, using the JsonWriter class method WriteNumber(number) writes out the appropriate string representation of number according to the JSON standard. The JsonConvert class offers Export and Import methods for converting between .NET types and JSON. These methods provide a similar functionality as found in the XmlSerializer class methods Serialize and Deserialize, respectively.


Conclusion

JSON is a lightweight, text-based data exchange format based on a subset of the literal notation from the JavaScript programming language. It provides a succinct encoding for application data structures and is typically used in scenarios where a JavaScript implementation is available to one or both of the applications exchanging data, such as in Ajax-style web applications. The allure of JSON lies in its simplicity to understand, adopt, and implement. JSON has virtually no learning curve for developers already familiar with JavaScript or other programming languages with similar support for a rich literal notation (like Python and Ruby). Parsing JSON text in JavaScript code can be accomplished by simply calling the eval function, and creating JSON text is a breeze with the json.js script provided at http://www.json.org/json.js.


References:

Text Widget

Copyright © Vinay's Blog | Powered by Blogger

Design by | Blogger Theme by