Some basic benchmarks for http://gadgettest.ngenplatform.com

Currently gadgettest is running on 3.bsgplatform.com in the same tomcat 5 instance that is running storagettest.ngenplatform.com.  Also this box is currently running clustered instances of service_user, service_provision, and service_org.

Each test is conducted using the apache ab tool.  The testing will assume a real world page of between 1 to 20 gadgets.  I will conduct 1000 requests across all of its major services: gadget renderer, stylesheet rendering, javascript rendering, and ajax requests.  Each test will use between 1 to 20 concurrent requests in increments of 5.

Test 1: Gadget rendering

The following test will occur against the sample directoery list gadget from the storage service.  It is using the following url for the gadget: http://gadgettest.ngenplatform.com/gadgets/ifr?up_userguid=35702a08-5733-11dd-a0ef-0030488b5524&url=http%3A%2F%2Fstoragetest.ngenplatform.com%2Fgadget%2Fdirectory_list_gadget

Results:

Using 1 conccurent request seems to be the anomaly, with 5 or more the average time request handling seems to degrade linearly.  In this setup, gadgetest seems to handle about 18 req/s.

Test 2: Javascript Rewriting

The next test deals with javascript rewriting.  Whenever shindig renders a gadget, it will first introspect its content looking for <script> tags.  It concatenates all of the javascript files  together and give one <script> tag to the browser that points to this service.  This service will then concatenate all of the javascript files, and do a quick rewrite.  The URL for this test is referencing the following javascript files:

• http://storagetest.ngenplatform.com:8080/javascripts/gadgets/base64.js
• http://storagetest.ngenplatform.com:8080/javascripts/gadgets/xml_util.js
• http://storagetest.ngenplatform.com:8080/javascripts/gadgets/platform.js
• http://storagetest.ngenplatform.com:8080/javascripts/prototype.js

The following URL is what is actually used for the tests:

http://gadgettest.ngenplatform.com/gadgets/concat?rewriteMime=text/javascript&gadget=http%3A%2F%2Fstoragetest.ngenplatform.com%2Fgadget%2Fdirectory_list_gadget&fp=-182800334&1=http%3A%2F%2Fstoragetest.ngenplatform.com%3A8080%2Fjavascripts%2Fgadgets%2Fbase64.js&2=http%3A%2F%2Fstoragetest.ngenplatform.com%3A8080%2Fjavascripts%2Fgadgets%2Fxml_util.js&3=http%3A%2F%2Fstoragetest.ngenplatform.com%3A8080%2Fjavascripts%2Fgadgets%2Fplatform.js&4=http%3A%2F%2Fstoragetest.ngenplatform.com%3A8080%2Fjavascripts%2Fprototype.js

Results:

The number of request per second handled by this service is 25% of the gadget rendering.  Also performance degradation, particular for the max requests is very fast.  Part of the problem with this test is the test occurred simulatneously with a platform clustering effort that may have impacted performance.  I plan on re-running the tests during more down time to see if performance remains this poor.  It may not matter anyways, as a better solution may be to disable this functionality and instead have the asset service use asset packaging like the collab does for its packages.  This would completely remove this service as a requirement and offload the processing to the asset service.

Test 3: Data Proxy

This test is arguably the most important test as it will be the biggest bottleneck in the system.  Even though the platform architecture is a distributed RESTful architecture, all data requests must be proxied through the gadget service due to same origin security policy of all browsers.  This means this service will receive the largest amount of requests, as any gadget dynamically retrieving data will be routed through this request.  Shindig combats this by using a time to live (TTL) cache with a user configurable expiry per data request.  This means that although the first request may be slow, subsequent requests will be much faster as it is merely a cache load.  This is illustrated in the results as the response time actually increases with the number of concurrent requests.

For the test I used a standard provision service query that would be necessary for any gadget using platform services.  The query was:

http://provisiontest.ngenplatform.com/provisions/6b0c73c0-bsga-serv-stor-001b7744stor

The resulting proxy request used in the test was:

http://gadgettest.ngenplatform.com/gadgets/makeRequest?refresh=3600&url=http%3A%2F%2Fprovisiontest.ngenplatform.com%2Fprovisions%2F6b0c73c0-bsga-serv-stor-001b7744stor&httpMethod=GET&headers=BSGRA_GUID%3D6b0c73c0-bsga-serv-stor-001b7744stor&postData=&authz=&st=&contentType=DOM&numEntries=3&getSummaries=false&signOwner=true&signViewer=true&gadget=http%3A%2F%2Fstoragetest.ngenplatform.com%2Fgadget%2Fdirectory_list_gadget&container=default&bypassSpecCache=

Result

As stated before the results show the performance actually increasing logarithmically.  It appears for the avg response time to limit out at around 20 ms per request.  For requests per second, it seems to be maxing out at 50/s.