That is awesome news about 3.1! We'll definitely keep this in mind!
Gary
Eric Dalquist wrote:
For this portlet we're just looking at gathering enough information to
know who is using uPortal and some basic information about the
deployment. Gathering actual portal usage statistics centrally isn't
in the scope of the goal here, the daily login numbers mentioned for
phase 2 are pushing it already. The end goals is to be able to publish
semi-accurate numbers around how many deployments, how big they are
and what sort of environment they are using.
3.1 does include the database backed stats recorder which can be used
to gather all of that information. The hard part is aggregating it, we
have an aggregator written which will be going into Jasig incubation
in a few weeks. We track all sorts of stats overall and by portal
group. That includes portlet render counts, times, interactions, and
the same thing for tabs. Hopefully once the 3.1 release is out I'll
have some time to document the aggregation options and once that is
out we can get some folks writing reporting tools :)
-Eric
Gary Weaver wrote:
Eric,
I noticed that 2nd gen stats collection included login stats.
You might consider adding "IP unique" login stats to the general
logging stats.
It would be also cool to collect concurrent # session statistics, but
with the research I've done on that, I'm not sure whether there is a
consistent way of doing that.
However, you might consider not integrating any ability to send the
stats automatically, since there could be privacy concerns about that
functionality being there, even if it could be configured not to send
them. I think it would be better for the portal admin or a functional
owner of the portal to review those stats before approving them to be
sent (each time). One way to do this (maybe not the best) would be
for each the portal itself or JASIG send emails to that person to let
them review and send only the stats they want to. I know that it is
probably much easier to just automate sending of stats, but odds are
more people would feel comfortable with sending those stats if they
could look at them first and maybe choose which to send.
In the end though, I don't think that gathering stats at JASIG will
be of much help. I could see Unicon possibly wanting to focus on some
data like "they've had a significant drop of logins- maybe we should
see if they need assistance", but in the end if something like that
happens, the institution using uPortal probably already knows about
it and might get annoyed that it is being used for the purpose of
vetting potential need for assistance. And JASIG itself wouldn't
seem to benefit from these stats other than possibly being able to
advertise something like "the highest # logins/day we are aware of in
the wild is ~8000" to try to increase adoption. And there could be a
number of dev/test instances registered using the same config as
production, so load testing and lack of use of those could
significantly affect numbers. Finally people that are checking into
using uPortal are probably more interested in load testing results
and information to help them determine system requirements and
suggested architecture for a particular theoretical # users than
anything else.
While on the topic of stats collection in uPortal (not that it has to
do with JASIG stats collection):
* Internally we track a lot of login stats based on different
attributes of users: for a given time period we report total logins
and unique logins, " " " " " by career, " " " " " by grad year, daily
stats of total logins and unique logins for career and grad year
(Matt Young wrote our code to gather additional data and do all of
the previous reports btw), and then total and unique logins broken
down by month, and total logins and unique logins for career and grad
year broken down by month (I added those last 2 later). If those
types of reports (tapping into user data fed in via the SSO or LDAP)
could be part of uPortal itself, that would be cool for some portal
admins, I'd expect.
* In terms of stats collection, our customer would really like for
the portal to collect stats on usage of portlets including number of
times portlet viewed (per day, etc.) and what the user clicked on,
etc. Unfortunately this is much harder to track generically without
changes required to each portlet to store that data. If there was a
way to solve this, that would be excellent.
Hope this helps.
Thanks,
Gary
Eric Dalquist wrote:
The last uPortal steering committee meeting had some very good
feedback from several sources about Jasig needing to do a better job
keeping track of portal deployments. To that end there have been
some discussions on the IRC channel that I thought I'd post about
here. There is a wiki page describing the plan and design:
http://www.ja-sig.org/wiki/display/UPC/Automated+Portal+Registration
The first step is something that we're going to try and get into the
3.1.0 release. It will be a portlet designated for the admin view
that provides a simple form for the administrator to fill out some
information about their install and some checkboxes about
automatically discovered data. The admin can then submit this
information to a small webapp that will reside on www.ja-sig.org.
Handling the data would then be up to the steering committee to deal
with. Including this at the last minute is a tough call but as the
new code will be in no way critical for uPortal to run the risk
versus the reward is worth it.
We would very much like feedback on this though. Please review the
wiki page first and any comments, questions or suggestions are more
than welcome.
-Eric
--
Gary Weaver
Application and Database Services
Office of Information Technology
Duke University
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
