Sunday, January 14, 2007

Tenant Based Applications; NovaJUG November meeting

Hugh Brien works for the Wiley Technology Division of Computer Associates, which does Web application performance monitoring (HTTP & J2EE). They also provide HTTP traffic monitoring at the IP level, measuring true response times all the way to the browser.

Having introduced himself, Brien began explaining the tenant based application model. The application is a tenant in a large building; just like a hosting environment, the application lives in a larger infrastructure.

He used Salesforce.com as the example, not because he wanted to sell Salesforce, but because it is the best known example of Software as a Service.

Brien contrasted the cost of SaaS with the cost of hosting your own applications: hardware, software & maintenance , overhead, personnel, and bandwidth. Other than Salesforce, SaaS providers include Netsuite (SRM/ERP Solution) and RightNow (SRM Solutions). Possible new players include SAP (which is going to build its own JVM and Brien indicated that SAP is not easy to work with), Oracle, and some others.

He said that Salesforce offers a comprehensive set of web services API’s for: JAVA, .Net, PHP, and Ruby.

Here, Brien began a demonstration using NovaJUG meeting attendees as an example. From my notes:
simple application w/ context
- add object
->call it a class
description
class w/ enrollment & topic
enable reports
add fields
new
custom fields

text based topic

just use metadata

drop down list to add fields - all schema automatically generated

(Here, someone asked if Salesforce was a black box and therefor if you wanted to host your own application, that you would be out of luck. Brien said yes.)

Brien continued the demonstration.

From my notes:

Salesforce
add data available via web services:
.Net
jsp
Ruby
java
PHP

Samples can be downloaded from the Salesforce website.

After the Salesforce demonstration, Brien spoke briefly about Wiley Technology’s web application performance monitoring. It seems everyone makes the same mistakes, either pig in the python (one big slow call), or Death by a thousand cuts (too many little calls).

Brien discussed the need for building a proper ratio of work threads to database connections. He said the out of box connection defaults are too low.

Brien recommended JMeter as a good load tester, and advised that testing at the five user level for a couple of hours would tell you a lot.

No comments: