Hi,
What’s the purpose/benefit of naming shared memory zones in config
files?
Thanks,
Marcus.
On Mon, Sep 28, 2009 at 03:28:44PM +0300, Marcus C. wrote:
Hi,
What’s the purpose/benefit of naming shared memory zones in config files?
Its names are used in other directives. For example, you may have
several proxy_cache’s.
The second reason is Win32 uses named shared memory mapping.
However, it’s lamost impossible to use shared memory in Win32 due to
Vista ASLR.
On Mon, Sep 28, 2009 at 06:25:37PM +0300, Marcus C. wrote:
be different, and from what I gather, if you use the same name (and tag)
would be much neater than
proxy_cache_path /data/nginx/cache levels=1:2 key_zone=one:10m;
And overall wouldn’t lose any information that couldn’t be generated in
the background.
No, suppose the following:
proxy_cache_path /data/nginx/cache1 levels=1:2 keys_zone=ONE:10m;
proxy_cache_path /data/nginx/cache2 levels=1:2 keys_zone=TWO:10m;
location / {
proxy_cache ONE;
}
location /one/ {
proxy_cache ONE;
}
location /two/ {
proxy_cache TWO;
}
The second reason is Win32 uses named shared memory mapping.
However, it’s lamost impossible to use shared memory in Win32 due to
Vista ASLR.If you need to have named sections, it would be easy enough to generate
them sequentially (e.g. ngx_shms1, ngx_shms2…) whilst reading the
config file.
The zone name is also logged when zone is out of space.
Hi,
Igor S. wrote:
I understand their use in other directives, but I was just wondering why
you actually need them in the directives.
For example, if you define several proxy caches, then each one would
automatically use a different shared memory section. It seems
unnecessary to me to use names in the config file, since they’d always
be different, and from what I gather, if you use the same name (and tag)
for two shared memory sections, then you’ll get a conf error (correct me
if I’m wrong, though).
I feel that having the config like
proxy_cache_path /data/nginx/cache levels=1:2 10m;
or even
proxy_cache_path /data/nginx/cache 1:2 10m;
would be much neater than
proxy_cache_path /data/nginx/cache levels=1:2 key_zone=one:10m;
And overall wouldn’t lose any information that couldn’t be generated in
the background.
The second reason is Win32 uses named shared memory mapping.
However, it’s lamost impossible to use shared memory in Win32 due to
Vista ASLR.
If you need to have named sections, it would be easy enough to generate
them sequentially (e.g. ngx_shms1, ngx_shms2…) whilst reading the
config file.
Thanks,
Marcus.
On Mon, Sep 28, 2009 at 07:04:27PM +0300, Marcus C. wrote:
What about offering an alternative, clearer syntax? e.g.:
proxy_cache_path /data/nginx/cache1 1:2 ONE 10m;
In my opinion
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=ONE:10m
inactive=1h max_size=1g;
is clearer and more expansible: you just need to add new keywords.
Furthermore, this week I plan to refactor limit_zone module and
to change syntax of
limit_zone one $binary_remote_addr 10m;
to
limit_conn_zone $binary_remote_addr zone=one:10m;
on the analogy of
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
Igor S. wrote:
I understand their use in other directives, but I was just wondering why
And overall wouldn’t lose any information that couldn’t be generated in
}location /one/ {
proxy_cache ONE;
}location /two/ {
proxy_cache TWO;
}
I see.
What about offering an alternative, clearer syntax? e.g.:
proxy_cache_path /data/nginx/cache1 1:2 ONE 10m;
The zone name is also logged when zone is out of space.
Ok, that’s useful.
Thanks,
Marcus.
Igor S. wrote:
In my opinion
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=ONE:10m
inactive=1h max_size=1g;is clearer and more expansible: you just need to add new keywords.
I see your point, I just personally prefer the shorter syntax, and if
you are familiar with the syntax, I think it’s quicker to read
proxy_cache_path /data/nginx/cache 1:2 ONE 10m 1h 1g;
How about offering both? You could have a syntax that included the
key/value pairs and one that had the shorter syntax with a specific
ordering. That would mean that admins could choose the version they
prefer.
Just an idea.
Thanks,
Marcus.
I do not think that short syntax is good, suppose:
proxy_cache_path /data/nginx/cache 1:2 ONE 10m 20m 50m;
Sure, I can see why it could be confusing, but that’s why I’m suggesting
both as an option, and leave it up to whoever manages the server to
decide whether they want the longer or shorter syntax. I think there
will be others than just myself who would prefer a shorter syntax as an
option.
You could also write the above as
proxy_cache_path /data/nginx/cache 1:2 ONE 10M 20m 50M
which helps to differentiate between the time and keys zone size, or you
could have
proxy_cache_path /data/nginx/cache 1:2 ONE:10M 20m 50M
to link the shm name with size, which might make it easier to remember
the order if you have to.
Marcus.
On Mon, Sep 28, 2009 at 07:51:38PM +0300, Marcus C. wrote:
proxy_cache_path /data/nginx/cache 1:2 ONE 10m 1h 1g;
How about offering both? You could have a syntax that included the
key/value pairs and one that had the shorter syntax with a specific
ordering. That would mean that admins could choose the version they prefer.Just an idea.
I do not think that short syntax is good, suppose:
proxy_cache_path /data/nginx/cache 1:2 ONE 10m 20m 50m;
Hello!
On Mon, Sep 28, 2009 at 11:39:49PM +0300, Marcus C. wrote:
proxy_cache_path /data/nginx/cache 1:2 ONE 10M 20m 50M
which helps to differentiate between the time and keys zone size, or
you could haveproxy_cache_path /data/nginx/cache 1:2 ONE:10M 20m 50M
to link the shm name with size, which might make it easier to
remember the order if you have to.
Using more than two or three positioned arguments are error-prone
and just silly. It’s hard to remember their intended order, it’s
impossible to change order and/or remove one of them if needed
later for some reason, you may add new arguments to the end only,
there is no good way to provide defaults. In this particular case
it will be impossible to detect some errors in arguments order,
too (as time and size declarations may be identical.
Having two possible notations allowed will make things even worse as
you’ll have to a) remember both as administrator to be able to read
configs b) distinguish them reliably in parsing code.
Speaking particularly about proxy_cache_path:
There was at least 2 changes in it’s arguments since introduction.
With current syntax it was hardly even noticeable. With proposed
“short” notation it would likely require each and every config
rewrite or introduction of another directive (with
proxy_cache_path left as legacy).
Maxim D.
p.s. I understand that you want to do things better. But
suggested change is bad. Really.
Maxim D. wrote:
Speaking particularly about proxy_cache_path:
There was at least 2 changes in it’s arguments since introduction.
With current syntax it was hardly even noticeable. With proposed
“short” notation it would likely require each and every config
rewrite or introduction of another directive (with
proxy_cache_path left as legacy).
Well actually I’d say that re-writes of configurations in general would
be required, with one notable exception, no more than if you use
key/value pairs. If you’re adding options, then you don’t need to
change the order, and just add the options onto the end. If you drop an
option, then you’d need to change the config anyway. The only real
problem with changes is if an option were dropped, and the ordering of
the options were such that an old configuration could be interpreted as
a new configuration without errors, but with unintended behaviour. I
think this case would be rare, though.
Maxim D.
p.s. I understand that you want to do things better. But
suggested change is bad. Really.
Maybe. I totally understand where you’re coming from, and I’m torn
between the two options, but I still feel the shorter syntax is nicer.
Of course the advantage of OS software is that I can go and write a
patch if I want to do things differently.
Thanks Igor and Maxim for taking the time to share your views on this.
Marcus.