diff --git a/content/develop/clients/jedis/produsage.md b/content/develop/clients/jedis/produsage.md index eadd8c10bc..d78a94193e 100644 --- a/content/develop/clients/jedis/produsage.md +++ b/content/develop/clients/jedis/produsage.md @@ -15,12 +15,62 @@ title: Production usage weight: 6 --- -The following sections explain how to handle situations that may occur -in your production environment. +This guide offers recommendations to get the best reliability and +performance in your production environment. + +## Checklist + +Each item in the checklist below links to the section +for a recommendation. Use the checklist icons to record your +progress in implementing the recommendations. + +{{< checklist "prodlist" >}} + {{< checklist-item "#connection-pooling" >}}Connection pooling{{< /checklist-item >}} + {{< checklist-item "#client-side-caching" >}}Client-side caching{{< /checklist-item >}} + {{< checklist-item "#timeouts" >}}Timeouts{{< /checklist-item >}} + {{< checklist-item "#health-checks" >}}Health checks{{< /checklist-item >}} + {{< checklist-item "#exception-handling" >}}Exception handling{{< /checklist-item >}} + {{< checklist-item "#dns-cache-and-redis" >}}DNS cache and Redis{{< /checklist-item >}} +{{< /checklist >}} + +## Recommendations + +The sections below offer recommendations for your production environment. Some +of them may not apply to your particular use case. + +### Connection pooling + +Example code often opens a connection at the start, demonstrates a feature, +and then closes the connection at the end. However, production code +typically uses connections many times intermittently. Repeatedly opening +and closing connections has a performance overhead. + +Use [connection pooling]({{< relref "/develop/clients/pools-and-muxing" >}}) +to avoid the overhead of opening and closing connections without having to +write your own code to cache and reuse open connections. See +[Connect with a connection pool]({{< relref "/develop/clients/jedis/connect#connect-with-a-connection-pool" >}}) +to learn how to use this technique with Jedis. + +### Client-side caching + +[Client-side caching]({{< relref "/develop/clients/client-side-caching" >}}) +involves storing the results from read-only commands in a local cache. If the +same command is executed again later, the results can be obtained from the cache, +without contacting the server. This improves command execution time on the client, +while also reducing network traffic and server load. See +[Connect using client-side caching]({{< relref "/develop/clients/jedis/connect#connect-using-client-side-caching" >}}) +for more information and example code. ### Timeouts -To set a timeout for a connection, use the `JedisPooled` or `JedisPool` constructor with the `timeout` parameter, or use `JedisClientConfig` with the `socketTimeout` and `connectionTimeout` parameters: +If a network or server error occurs while your code is opening a +connection or issuing a command, it can end up hanging indefinitely. +You can prevent this from happening by setting timeouts for socket +reads and writes and for opening connections. + +To set a timeout for a connection, use the `JedisPooled` or `JedisPool` constructor with the `timeout` parameter, or use `JedisClientConfig` with the `socketTimeout` and `connectionTimeout` parameters. +(The socket timeout is the maximum time allowed for reading or writing data while executing a +command. The connection timeout is the maximum time allowed for establishing a new connection.) ```java HostAndPort hostAndPort = new HostAndPort("localhost", 6379); @@ -34,9 +84,33 @@ JedisPooled jedisWithTimeout = new JedisPooled(hostAndPort, ); ``` +### Health checks + +If your code doesn't access the Redis server continuously then it +might be useful to make a "health check" periodically (perhaps once +every few seconds). You can do this using a simple +[`PING`]({{< relref "/commands/ping" >}}) command: + +```java +try (Jedis jedis = jedisPool.getResource()) { + if (! "PONG".equals(jedis.ping())) { + // Report problem. + } +} +``` + +Health checks help to detect problems as soon as possible without +waiting for a user to report them. + ### Exception handling -The Jedis Exception Hierarchy is rooted on `JedisException`, which implements `RuntimeException`, and are therefore all unchecked exceptions. +Redis handles many errors using return values from commands, but there +are also situations where exceptions can be thrown. In production code, +you should handle exceptions as they occur. + +The Jedis exception hierarchy is rooted on `JedisException`, which implements +`RuntimeException`. All exceptions in the hierarchy are therefore unchecked +exceptions. ``` JedisException diff --git a/layouts/shortcodes/checklist-item.html b/layouts/shortcodes/checklist-item.html new file mode 100644 index 0000000000..6536881725 --- /dev/null +++ b/layouts/shortcodes/checklist-item.html @@ -0,0 +1,13 @@ +
  • + +{{- if index .Params 0 -}} +{{ .Inner }} +{{- else -}} +{{ .Inner }} +{{- end -}} +
    • \ No newline at end of file diff --git a/layouts/shortcodes/checklist.html b/layouts/shortcodes/checklist.html new file mode 100644 index 0000000000..685c3422d4 --- /dev/null +++ b/layouts/shortcodes/checklist.html @@ -0,0 +1,85 @@ +{{ $formId := index .Params 0 }} +
    + + + 0/, + + 0/, + + 0/ +
    + ( + 0/) +
    + \ No newline at end of file