Acegi Security System for Spring benchmark

I’ve recently used Acegi for a simple application and as I wanted to know how
much it loads the webapp I used JMeter to benchmark it. I’ve just spent less
than 30 min. to setup everything, so yake it as is, just a small idea of what
involves adding the Acegi filters to process the requests.

What I have used:

  • Tomcat 4.0.6
  • Acegi 0.7.0
  • JMeter 2.0.2

Acegi filters defined in web.xml:

  • A ProcessingFilter made by myself
  • HttpSessionIntegrationFilter
  • SecurityEnforcementFilter

Here there are the results of three tries, each one with the number of threads,
the ramp-up (delay between threads in seconds), and the loops (number of times
the test was executed). The url tested was not secured.

threads ramp-up loop  
50 1 10  
 
  average (ms.) deviation (ms.)  
Using Acegi 107 47 15%
Not using Acegi 93 82

threads ramp-up loop  
50 1 100  
 
average (ms.) deviation (ms.)  
Using Acegi 233 137 13%
Not using Acegi 206 125

threads ramp-up loop  
5 1 1000  
 
  average (ms.) deviation (ms.)  
Using Acegi 15 12 67%
Not using Acegi 9 12

You can see that the overhead of using Acegi is about 14% increase of access
time in every page when the load is high. When it’s low, the overhead is
higher, but not relevant.

ONess 0.5 bundled with Tomcat

After noticing that the compressed file was corrupt I’ve make available again the latest ONess version 0.5 bundled with Tomcat 5.0.30.

As I’ve said in a previous entry, it’s ready to run in less than a minute and uses hsqldb to avoid the need of setting up a database.

You can download from Sourceforge, uncompress, go to the “bin” dir and run startup.bat or startup.sh. After tomcat is up and running you can go to http://localhost:8080/ to check the web interface.

Acegi Security release 0.7.0 is out

The long awaited 0.7.0 relase of Acegi Security System for Spring is out. I’m happy to have contributed (just a bit) to this great project. And it is built with maven!!

Dear Spring Community

I’m pleased to announce the Acegi Security System for Spring release 0.7.0 is now available from http://acegisecurity.sourceforge.net. The project provides comprehensive security services for The Spring Framework. You can read about the features in detail at http://acegisecurity.sourceforge.net.

There are many changes, improvements and fixes in release 0.7.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). The major new feature areas are:

* Significant improvements to ACL security services

* AspectJ support (useful for instance-level security)

* Refactoring of ObjectDefinitionSources (especially useful for web URI security)

* Automatic propagation of security identity via RMI and HttpInvoker

* Integration with Servlet Spec’s getRemoteUser()

* Refactoring of Contacts sample to use the new ACL security services

* Additional event publishing (now includes authorisation, not just authentication)

* CVS restructure to use Maven as the build system

* A new project web site with FAQs, links to external articles etc

The new ACL security services deserve special mention, as they make it possible to develop applications that require complex instance-based security without any custom code. The entire configuration of such applications can be declared in the IoC container using standard Acegi Security services, so this should help significantly improve architecture and development time.

As per the Apache APR project versioning guidelines, this is a major release. We expect the next major release will be 1.0.0, although release 0.7.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page.

For Maven users, Acegi Security’s latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. We will also be adding release 0.7.0 and above to iBiblio.

We hope you find this new release useful in your projects.

Best regards

Ben

An evening with Googles Marissa Mayer

Alan Williamson posts a very interesting entry about a presentation from Marissa Mayer (Product Manager for Google).

  1. The prime reason the Google home page is so bare is due to the fact that the founders didn’t know HTML and just wanted a quick interface. Infact it was noted that the submit button was a long time coming and hitting the RETURN key was the only way to burst Google into life.
  2. Due to the sparseness of the homepage, in early user tests they noted people just sitting looking at the screen. After a minute of nothingness, the tester intervened and asked ‘Whats up?’ to which they replied "We are waiting for the rest of it". To solve that particular problem the Google Copyright message was inserted to act as a crude end of page marker.
  3. One of the biggest leap in search usage came about when they introduced their much improved spell checker giving birth to the "Did you mean…" feature. This instantly doubled their traffic, but they had some interesting discussions on how best to place that information, as most people simply tuned that out. But they discovered the placement at the bottom of the results was the most effective area.
  4. The infamous "I feel lucky" is nearly never used. However, in trials it was found that removing it would somehow reduce the Google experience. Users wanted it kept. It was a comfort button.
  5. Orkut is very popular in Brazil. Orkut was the brainchild of a very intelligent Google engineer who was pretty much given free reign to run with it, without having to go through the normal Google UI procedures, hence the reason it doesn’t look or feel like a Google application. They are looking at improving Orkut to cope with the loads it places on the system.
  6. Google makes changes small-and-often. They will sometimes trial a particular feature with a set of users from a given network subnet; for example Excite@Home users often get to see new features. They aren’t told of this, just presented with the new UI and observed how they use it.
  7. Google has the largest network of translators in the world
  8. They use the 20% / 5% rules. If at least 20% of people use a feature, then it will be included. At least 5% of people need to use a particular search preference before it will make it into the ‘Advanced Preferences’.
  9. They have found in user testing, that a small number of people are very typical of the larger user base. They run labs continually and always monitoring how people use a page of results.
  10. The name ‘Google’ was an accident. A spelling mistake made by the original founders who thought they were going for ‘Googol’
  11. Gmail was used internally for nearly 2years prior to launch to the public. They discovered there was approximately 6 types of email users, and Gmail has been designed to accommodate these 6.
  12. They listen to feedback actively. Emailing Google isn’t emailing a blackhole.
  13. Employees are encouraged to use 20% of their time working on their own projects. Google News, Orkut are both examples of projects that grew from this working model.
  14. This wasn’t a technical talk so no information regarding any infrastructure was presented however they did note that they have a mantra of aiming to give back each page with in 500ms, rendered.
  15. Quote: Give Users What They Want When They Want It
  16. Quote: Integrate Sensibly

Is maven so difficult?

Many people say that Maven is more difficult to use than Ant, I just don’t agree.

I don’t agree that Maven learning curve is steeper than Ant, the fact is that many people already know Ant, but for newbies Maven hides all the low level stuff and can focus in what they want to do instead of how to do it. It’s a kind of declarative (maven) vs procedural (ant) point of view. You only need to create scripts if you want to customize your building, and you can use ant for that.

And remember! Maven is not only about automatic dependency downloading and a beautiful autogenerated site, but also project build standarization (standards are good, aren’t they?)

Docbook and Maven: generating xhtml instead of html

While the CVS version of the maven sdocbook plugin already does it, if you want to generate xhtml instead of html with the latest 1.4.1 release, you only need to set the following properties (e.g. to project.properties).

maven.sdocbook.html.xsl=${maven.sdocbook.stylesheets.dir}/xhtml/docbook.xsl
maven.sdocbook.htmlchunk.xsl=${maven.sdocbook.stylesheets.dir}/xhtml/chunk.xsl

Docbook and Maven

I’ve released two new versions of the maven sdocbook plugin (note that it’s called sdocbook for historical reasons but it uses the full docbook, not the simplified one). The latest version allows the creation of pdf, html in a single page and html splitted in sections. It also allows the customization of the stylesheets used for transformation.

It’s as easy as running maven sdocbook after you put the docbook source in the sdocbook folder.

To generate the docbook when building the site just add this postGoal to your maven.xml.

    <postGoal name="site">
        <attainGoal name="sdocbook"/>
    </postGoal>

There are two projects where I’ve implemented the docbook transformation using all the features:

  • ONess
  • Acegi Security System for Spring

If you’d like to generate the docbook files as part of the maven generated site (with the navigation bar on the left, logos and footer), you can try the following goal after generating the docbook files, but before xdoc goal.

    <goal name="docbook2xdoc">
        <maven:get var="maven.sdocbook.generated.html"
            plugin="maven-sdocbook-plugin"
            property="maven.sdocbook.generated.html"/>
        <mkdir dir="${maven.gen.docs}/docbook2xdoc"/>

        <j:set var="maven.html2xdoc.dir.bak" value="${maven.html2xdoc.dir}"/>
        <j:set var="maven.gen.docs.bak" value="${maven.gen.docs}"/>

        <j:set var="maven.html2xdoc.dir" value="${maven.sdocbook.generated.html}"/>
        <j:set var="maven.gen.docs" value="${maven.gen.docs}/docbook2xdoc"/>
        <attainGoal name="html2xdoc:transform"/>

        <j:set var="maven.html2xdoc.dir" value="${maven.html2xdoc.dir.bak}"/>
        <j:set var="maven.gen.docs" value="${maven.gen.docs.bak}"/>
    </goal>