On 28.07.2014 00:23, stefan2_at_apache.org wrote:
> Author: stefan2
> Date: Sun Jul 27 22:23:26 2014
> New Revision: 1613854
>
> URL: http://svn.apache.org/r1613854
> Log:
> On the authzperf branch: Very first step towards faster authz.
> Determine the user's aliases and group memberships once and
> then use this to evaluate rules in O(1).
>
> Right now, that information is constructed on the fly for each
> request and used from the existing matching code. This overhead
> will be eliminated in later commits. Right now, this is to
> introduce new, reviewable / testable code.
[...]
> +/*** Utilities. ***/
> +
> +/* We are using hashes to represent sets. This glorified macro adds the
> + * string KEY to SET. */
> +static void
> +set_add_string(apr_hash_t *set,
> + const char *key)
> +{
> + apr_hash_set(set, key, strlen(key), "");
> +}
svn_hash_sets. APR's default hash function avoids the strlen overhead
completely; our hash function already does the strlen.
> +/*** Users, aliases and groups. ***/
> +
> +/* Callback baton used with add_alias(). */
> +typedef struct add_alias_baton_t
> +{
> + /* Store the alias names here (including the '&' prefix). */
> + apr_hash_t *aliases;
> +
> + /* The user we are lookup up. */
Maybe change this to: "The user we lookup are up to look up"? :)
> +/* Return a hash set of all name keys (plain user name, decorated aliases
> + * and decorated group names) that refer to USER in the authz CONFIG.
> + * This include indirect group memberships. */
I'm confused (mostly by the lack of documentation of the structure of
the in-memory representation of the parsed authz file). Is your
intention to statically generate, at parsing time, a correlation between
each possible user name and the set of access control entries that are
valid for that user? I can easily imagine such a thing exploding in size
very quickly, even though most ACEs are not likely to ever be used
during the lifetime of the parsed authz representation.
That last is true for paths in the authz file, too; but memory required
for them is proportional to the number of paths in the authz file,
whereas for the user->ACE correlation, it's proportional to the nuber of
paths (ACEs) times the number of users.
(Of course, if I were writing this, I'd concentrate on the path lookup
tree first, and tackle users later ...).
-- Brane
--
Branko ÄŒibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com
Received on 2014-07-28 01:49:04 CEST