Wherein we write down some stuff that we know.

Various Data Points

August 15th, 2008

The end of year reports are being written and various folks have come to WEBD looking for what really happened on various systems. These numbers are based on our fiscal year which is from July 1st to June 30th.

University Home Page

  • 2007/08 – 9,289,385 visits as defined by Google Analytics

Yearly Unique Portal Logins (based on daily logs)

  • 2005/6 – 1,905,225
  • 2006/7 – 2,215,433
  • 2007/8 – 2,415,444

Yearly Total Portal Logins (based on daily logs)

  • 2005/6 – 3,377,752
  • 2006/7 – 4,089,277
  • 2007/8 – 4,359,887

Random

These numbers are based on whatever date range we happen to have numbers for.

  • We have 23 Spaces and 372 users in Confluence, our enterprise wiki.
  • 1,492 JIRA issues were created in the 2007/8 fiscal year.
  • 32,915 visits on January 29th, 2008 was our high water mark for the Portal
  • Portal browser stats (9/21/2007 – 6/30/2008) IE 60.47%, Firefox 29.53%, Safari 9.6%
  • Home page browser stats 2007/8 fiscal year – IE 76.18%, Firefox 23.47%, Safari 8.7%

Curious about anything else?

San Marcos Redesign

August 12th, 2008

Congrats to San Marcos on launching their new web site, powered by Cascade Server no less. Thanks to my automated system for grabbing screen shots I can get a historical perspective. Here is a QuickTime export of the shots:

CSU San Marcos Web Site (.mov)

Tracking the Applications You Develop

July 29th, 2008

Problem

There are a ton of applications being developed locally at your institution and you have no way of knowing who is doing what or how they are doing it. You don’t know what data they are pulling, where they are pulling it from, what they are gathering and where they are storing it all. You don’t know if you’re re-inventing a wheel that another department already developed. Worse, you don’t even really know what defines an “application.” Even if you did know all of those things, how would you keep that knowledge current? You, are in the dark.

Welcome. Unfortunately this isn’t a typical IK post where we go into detail on how to deal with a technical issue or show you pretty stat graphs. No, this is where I’m simply going to outline the issues associated with this problem and hope that somebody has already gone down this path…and that it didn’t lead to madness.

Defining an Application

Is a script an application? What about a script that takes form input and sends it to an e-mail address with no database involved at all? How small do you go? Before you start you need to agree on what makes an application. This, could take a while.

Finding Applications and Developers

Once you’ve establish what constitutes an application, now you have to find them and more importantly, the people that made them. It’s a typical problem and luckily one that has been solved before. You need to start as high as you can and start working your way down until you discover the technical people. You probably already know a good portion of these folks, but there are undoubtedly people you don’t know about that are developing and maintaining applications somewhere on campus. If you’re going to be thorough, you’ll need to find them.

Tracking

If you’ve tried to keep track of anything on campus you’ve most likely discovered that unless it’s fully automated, you have a problem. Scratch that. You have problems. Plural. You can ask people for updated information over e-mail, which will get you a few well-meaning responses and a lot of crickets. You can send out a spreadsheet for people to updated which will leave you in ‘multiple file revision’ Hell. You might even be so bold as to develop your own application that will allow people to update their own information online. You might even have asked at some point, “How hard can it be?” The problem is that no matter how easy you make this, you are essentially asking other people to do something for you, and therein lies the rub. How can you ask people to do this for you? This is more a people problem than a technology problem, but it’s a problem nonetheless.

Permissions

For the sake of argument, lets say that we’ve solved the people problem of getting updated information with the application we developed. Now, who gets to see what once they’ve gotten inside. If it is locked down so that people can only see their own information, you’ve created a system that requires them to do work with no real value to them. There is no real benefit in a person only seeing their own information. They’ll most likely want to have access to all the information so they can see what others are doing as well. That was the whole point of the application in the first place, right? So, you open the system and have no restrictions on who can see what. That idea is scary to a lot of people and more than likely they have valid reasons for being wary of this venture. Again, we’ve run into a people problem.

Summary

We have a blind spot on campus and we want to use technology to help illuminate ourselves to what is happening. The technology solution requires that campus agree on a definition, dedicating time to keep the information current, and who has access. These are things that must be dealt with by people. These are issues which no matter how much technology you throw at them, they will not go away.

Solutions?

Have you tackled this dragon? Did you win? If so, we would love to hear your story. Actually, we would love to hear your story even if you lost.

Portal Stats: The Term in Review

June 13th, 2008

At the start of the term, we looked at portal traffic on the first day of the term, in this case spring 2008. It was a busy day, to say the least. Now that we have data for the entire term, what more do we know?

  • The second day of school was the busiest day of the term for visits (not visitors, as define by Google Analytics), 32,915.
  • Monday after spring break had the highest total visitors, 18,391.
  • Saturday, March 15, the start of spring break was our least busy day for visits, 4,499.

Now, you might look at these numbers and say, “Pat, that’s exactly what we would expect to happen.” That is correct, but until you actually have the numbers, you don’t really know that your expectations of reality and reality itself match up. Now you do.

The numbers for the whole term look like this:

Google Analytics spring 2008

You might notice some abnormalities in our sparkline graphs. This is due to our introduction of tracking some popular “external links” during spring break. It will slightly distort our page view data for spring 2008, external links are tracked as views, but as long as we break our reporting into pre and post break segments we’ll be fine. Our visitor information remains consistent though.

The external link tracking is important in the portal so we know where people are going when they leave. Our portal strategy has never been to bring applications into the portal, just provide easy access. Before Google Analytics it was difficult for us to track that information. Now we track clicks to all major applications from the portal. That information should prove illuminating in the future.

Overall having Google Analytics in the portal is a big win for us. We’re still keeping all the raw log file information and doing our usual processing, but this wins hands down just for the amazing breadth of information we can look at now.

Tomcat SSL Performance Followup

April 2nd, 2008

Previously I talked about improving the SSL performance in Tomcat simply by upgrading the JVM. Here we have a somewhat not-to-scale chart showing how we did in a “real world” test. Last night at 6pm an application opened up and sent a flood of users to our authentication service (CAS). Last year we could not handle the flood. CAS stalled, which caused a flood of calls to the help desk. In the business, we call that less than optimal.

We’re rolling CAS on Java 6 now and SSL performance is no longer an issue.