Project Progress Report

Just to keep the blog active I’ll give a brief progress report.  Basically I have completed the main body or the report document using nearly all of the 15000 word allowance.  I have proofread the document twice now so it is in fairly good order.  There are several appendices that must now be written including a glossary and the section on future research projects.  While the report has a reasonable amount of references I should also go through and see it I can provide support for some of the statements I have made.

The next obvious focus for the project is designing the final presentation.  Thought needs to be given as to what will be included and what will be excluded.  Once the presentation is complete it will be important to practice and ensure that it is the correct length.  Thought too should be given to some of the questions that may be asked after its conclusion.

With regard to the report I will get a couple of other opinions.  Paul has already part read it for me and found it mostly ok.  My mum will read it for me too.  I have also made an appointment at the library to go over it with someone.

Project Progress Report

I know that there is probably no one reading this blog but I consider it worthwile putting on paper (or the internet as the case may be) exactly where I am in terms of project completion.

As things stand I have completed the testing phase of my project and should no longer need to use the lab. What little testing I do now will be only for the purposes of verification if certain observations are unclear.

As for my progress through the report I have completed the first draft. The draft is totally unproofread and contains much that needs improvement. I expect to spend the following two weeks proofing and improving this draft.

The final stage of the project will be preparing for the presentation. This will be considered and time alloted once the report is complete.

Tomcat is faster than GlassFish

A slight worry in the back of my mind was that close tie between JSP and the server platform it is run under. In order to gain further information I spent today installing and running tests against GlassFish to compare with Tomcat.

The findings of this exercise were very simple: Tomcat is faster. This is as I suspected all along since Tomcat is purely a JSP capable shell wheras GlassFish is a complete enterprise capable application server.

Another useful thing I found out today is that PHP no longer supports ISAPI. Since people seemed of mixed opinion as to whether FastCGI or ISAPI should be used this a useful bit of information. Whether it is better or not FastCGI is the only supported technology that will work at speed.

A case for denormalisation

For various reasons I carried out two sets of tests against to similar pages.  One page retrieves data from only one table in the database.  The other page retrieves data by bridging between several tables.  The results changed from around 2ms to 40ms leaving a huge difference to be accounted for merely in the DBMS creating the joins.

If time is available (and I think it is) it will be interesting to investigate whether this result can be improved by introducing a denormalised field in the database.  I suspect this to be rather easy but in reality would also require some complex logic to be executed on update (probably as a trigger).

A little too late…

In the course of writing my report I discovered that I had not thoroughly tested all of the options for PHP.  At the time what I had tested was considered sufficient.  With the benefit of hindsight I now consider that view incorrect.  That point aside there appears to be a lot of contention as to whether ISAPI or FastCGI is in fact the better way to run PHP.  There was even suggestion that it may vary depending on what a script is doing.

Another thing I never tested was how JSP runs under other competing products.  This is not so much of a problem since Tomcat is the primary environment under which it is run.

Despite being too late to gather significant data under any other environment it would be good to finish the project work by testing how PHP and JSP perform under each installation type.  The reason for doing this last is that it requires an alteration to the server state which could in turn affect the results.

A successful day

Yesterday morning I noted on the blog what pages I had tested and those that I had yet to test.  I am pleased to say that I gathered test data for each of the remaining items yesterday.  This mitigates my need to spend time programming and testing unless further tests are designed.

Since I don’t have any further work that requires the lab immediately I am going to spend today focused on the report.

Wrapping Up…

So far in my project I have gathered data for the following:

• The Categories page with MySQL and SQL Server
• The Products page with MySQL
• The Purchase page with MySQL and SQL Server
• An arbitrary page which makes heavy use of an array
• Web server performance with a HTML only request

The data that I have gathered so far has given me a fairly good idea of the performance implications of each language.  To complete the data gathering for my project I would like to run the following:

• The Products page with SQL Server
• The Item page (individual product view) with either SQL Server or MySQL
• The Categories page with a query string against MySQL and SQL Server

Once I have gathered this data the testing phase of my project should be complete.  With this data in hand I will be able to change focus to report writing and work on completing the project.

Remaining Tasks

I have collected a reasonable amount of data thus far in my project.  I intend to collect a little more before I change focus to the report.

One particular task that I need to design and run is a page which uses classes and objects to do something.  I have decided to combine this with my individual product page in the interest of saving time.

Otherwise I want to run the categories pages with an incoming query string.  Preferably I would run a more complex page but I don’t have one and am rapidly running out of available time for prototype building and testing.

Products Page with MySQL

I realised that I had not actually tested the products page with MySQL because the first time I ran the tests the timer was not functioning correctly.  So I spent some time today running these tests.

The outcomes were very close and slightly inexplicable.  It would seem that PHP works better when you are doing a cross table query.  Why on earth this would be the case I have no idea.  Anyway PHP and ASP.NET are pretty close while JSP as usual had a slightly better time.

On the basis of these results alone I wouldn’t be able to make any recommendation except that it appears that JSP makes better use of the CPU.

The Answer?

I have spent the morning trying to solve yesterdays conundrum as to why PHP does better on the products page.  The answer appears to lie in the Prepare() method called in ASP.NET and a similar method called in JSP.  Although Microsoft says that the Query method (in their PHP interface) “prepares” the statement it doesn’t seem to be calling a server side prepare.

I theorise that the server side preparation of the statement is taking longer because it is a comparatively complex query.  In addition it does not appear that PHP is in fact calling the server side prepare.  If this is the case the test pages are not identical and the test is invalid.

The solution appears to be in removing the call to the prepare statement.  Without this statement the ASP.NET and PHP pages run in pretty well identical times.  Go one step further and use simple dynamic SQL and you find that ASP.NET runs better than PHP as is normally expected.

For the moment I will ignore this page and attempt to focus my energy on pages where I will get useful data.  I am now going to run tests on the categories page but with an input query string.