Navigation

groonga-httpd is a program to communicate with a Groonga server using
the HTTP protocol. It functions as same as
Groonga HTTP server. Although Groonga HTTP server has
limited support for HTTP with a minimal built-in HTTP server,
groonga-httpd has full support for HTTP with an embedded nginx. All standards-compliance and features provided
by nginx is also available in groonga-httpd.

groonga-httpd has an Web-based administration tool implemented with HTML and
JavaScript. You can access to it from http://hostname:port/.

Specifies whether Groonga database is created automatically or not. If
the value is on and the Groonga database specified by
groonga_database doesn't exist, the Groonga
database is created automatically. If the Groonga database exists,
groonga-httpd does nothing.

If parent directory doesn't exist, parent directory is also created
recursively.

The default value is on. Normally, the value doesn't need to be
changed.

Specifies the base path in URI. Groonga uses
/d/command?parameter1=value1&... path to run command. The form
of path in used in groonga-httpd but groonga-httpd also supports
/other-prefix/command?parameter1=value1&... form. To support the
form, groonga-httpd removes the base path from the head of request URI
and prepend /d/ to the processed request URI. By the path
conversion, users can use custom path prefix and Groonga can always
uses /d/command?parameter1=value1&... form.

Nomally, this directive isn't needed. It is needed for per command
configuration.

Here is an example configuration to add authorization to
shutdown command:

For example, there is a tool that analyzing your query log. It can
detect slow queries from your query log. There is a tool that
replaying same queries in your query log. It can test the new Groonga
before updating production environment.

For optimum performance, set this to be equal to the number of CPUs or cores. In
many cases, Groonga queries may be CPU-intensive work, so to fully utilize
multi-CPU/core systems, it's essential to set this accordingly.

Specifies the base path of query cache in the http, server or
location block.

It's recommended that you specify this configuration when you use
multi-workers configuration.

If the base path is specified, you can use persistent cache instead of
on memory cache. If you use persistent cache, workers share query
cache. It's efficient for multi-workers configuration because the same
response is cached only once in multiple workers.

There is one more merit for persistent cache. You don't need to warm
up cache after groonga-httpd is restarted. Persistent cache isn't
cleared when groonga-httpd is down. groonga-httpd can use existing
persistent cache again.

The default value is off. It means that persistent cache is
disabled. On memory cache is used. On memory cache is independent in
each worker. It's not efficient for multi-workers configuration
because two or more workers may keeps the same response separately.

Persistent cache is a bit slower than on memory cache. Normally, the
difference has little influence on performance.

You must specify the base path on memory file system. If you specify
the base path on disk, your cache will be slow. It's not make sense.

Groonga has query cache feature for select
command. The feature improves performance in many cases.

Query cache feature works well on groonga-httpd except you use
cache_limit command on 2 or more
workers. Normally, cache_limit command
isn't used. So there is no problem on many cases.

Here is a description about a problem of using
cache_limit command on 2 or more workers.

Groonga's query cache is available in the same process. It means that
workers can't share the cache. If you don't change cache size, it
isn't a big problem. If you want to change cache size by
cache_limit command, there is a problem.

All standard HTTP modules are available. HttpRewriteModule is
disabled when you don't have PCRE (Perl Compatible Regular
Expressions). For the list of standard HTTP modules, see
http://wiki.nginx.org/Modules.