> 1) I made my principal lazy, i.e. it only contains an UUID and loads > everything from the DB as required. This shaved off about 30%, but it still > left about 700 bytes. > 2) Turning off encryption isn't a biggie, it only reduced the cookie size a > few tens of bytes, so I turned it back on.
That was my suspicion, but I haven't tested it, so I wasn't sure. Thanks for reporting your findings. > 3) I wrote my own Serializer, and this was the whopper: just by simply > serializing nothing but the UUID (with the appropriate magic numbers), I was > able to squeeze the cookie size from 700 bytes to 74 bytes (!) while > encryption was on. This is a good result, and should also make my website a > bit snappier since there is no longer a need to transfer huge cookies. This > suggests that the default HashMap serialization *is* actually a lot of > overhead for simple usecases, and it might be a good idea to figure out > something lighter. Interesting. SimplePrincipalCollection is basically a wrapper around a LinkedHashMap (key: realm name, value: LinkedHashSet of principals (objects) from that realm). the JDK's HashMap.java and HashSet.java (both of which write the Java object serialization readObject/writeObject used by their Linked* subclasses) appear to be pretty efficient: HashMap serializes 2 'metadata' ints (table.length, size) and then the key/value pairs. HashSet serializes 3 'metadata fields' (capacity, loadFactor, size). So if you have a Map of Sets like SimplePrincipalCollection, then you'd have 5 metadata fields + the raw data - which really isn't a lot. I'm surprised to see that this results in an entire order of magnitude difference for your particular data set. That's a big deal! Given that the JDK's implementation seems to be pretty efficient, I'm not entirely sure that we could do much for SimplePrincipalsCollection to meet the general case of working in all applications. We also haven't had any other reports related to this yet, so I think its really because of the Amazon ELB (i.e. browsers can handle cookies of the default size no problem). But if you'd like to help out to try to make it more efficient, we'd love the help! I'd be curious if you could find something - it sounds like you might already have a test harness up for testing, at which point it'd be a simple test to change SimplePrincipalCollection's readObject/writeObject and see what happens. If you try this, please let us know! > Considering that I have only a single Realm with a single Principal, I assume > that doing stuff like this is safe? Shiro never adds any principals on its > own to the PrincipalCollection? Are there any events in which I would have > Principals I did not control? Well, it's safe in that scenario only (one realm with one principal). Shiro never adds anything to the PrincipalCollection itself - the PrincipalCollection is there to represent what is returned from realms only. If Shiro needs to add anything regarding Subject state, it currently always does that by using the Session. But if you ever change your app in the future to support more than one realm or principal, this might cause you (or someone else) quite a headache if it isn't documented extremely well ;) Best, -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com
