Removed Redis-specific things from conf file

Former-commit-id: 4d71929c6000b6a5ceb4793f9b3ee8c7576f4b71

keydb.conf

@@ -165,7 +165,7 @@ tcp-keepalive 300
 # tls-auth-clients no
 # tls-auth-clients optional
 
-# By default, a Redis replica does not attempt to establish a TLS connection
+# By default, a KeyDB replica does not attempt to establish a TLS connection
 # with its master.
 #
 # Use the following directive to enable TLS on replication links.
@@ -497,8 +497,8 @@ repl-diskless-sync-delay 5
 # -----------------------------------------------------------------------------
 # WARNING: RDB diskless load is experimental. Since in this setup the replica
 # does not immediately store an RDB on disk, it may cause data loss during
-# failovers. RDB diskless load + Redis modules not handling I/O reads may also
-# cause Redis to abort in case of I/O errors during the initial synchronization
+# failovers. RDB diskless load + KeyDB modules not handling I/O reads may also
+# cause KeyDB to abort in case of I/O errors during the initial synchronization
 # stage with the master. Use only if your do what you are doing.
 # -----------------------------------------------------------------------------
 #
@@ -581,7 +581,7 @@ repl-disable-tcp-nodelay no
 # repl-backlog-ttl 3600
 
 # The replica priority is an integer number published by KeyDB in the INFO
-# output. It is used by Redis Sentinel in order to select a replica to promote
+# output. It is used by KeyDB Sentinel in order to select a replica to promote
 # into a master if the master is no longer working correctly.
 #
 # A replica with a low priority number is considered better for promotion, so
@@ -648,7 +648,7 @@ replica-priority 100
 
 ############################### KEYS TRACKING #################################
 
-# Redis implements server assisted support for client side caching of values.
+# KeyDB implements server assisted support for client side caching of values.
 # This is implemented using an invalidation table that remembers, using
 # 16 millions of slots, what clients may have certain subsets of keys. In turn
 # this is used in order to send invalidation messages to clients. Please
@@ -657,22 +657,22 @@ replica-priority 100
 #   https://redis.io/topics/client-side-caching
 #
 # When tracking is enabled for a client, all the read only queries are assumed
-# to be cached: this will force Redis to store information in the invalidation
+# to be cached: this will force KeyDB to store information in the invalidation
 # table. When keys are modified, such information is flushed away, and
 # invalidation messages are sent to the clients. However if the workload is
-# heavily dominated by reads, Redis could use more and more memory in order
+# heavily dominated by reads, KeyDB could use more and more memory in order
 # to track the keys fetched by many clients.
 #
 # For this reason it is possible to configure a maximum fill value for the
 # invalidation table. By default it is set to 1M of keys, and once this limit
-# is reached, Redis will start to evict keys in the invalidation table
+# is reached, KeyDB will start to evict keys in the invalidation table
 # even if they were not modified, just to reclaim memory: this will in turn
 # force the clients to invalidate the cached values. Basically the table
 # maximum size is a trade off between the memory you want to spend server
 # side to track information about who cached what, and the ability of clients
 # to retain cached objects in memory.
 #
-# If you set the value to 0, it means there are no limits, and Redis will
+# If you set the value to 0, it means there are no limits, and KeyDB will
 # retain as many keys as needed in the invalidation table.
 # In the "stats" INFO section, you can find information about the number of
 # keys in the invalidation table at every given moment.
@@ -938,7 +938,7 @@ acllog-max-len 128
 #
 # replica-ignore-maxmemory yes
 
-# Redis reclaims expired keys in two ways: upon access when those keys are
+# KeyDB reclaims expired keys in two ways: upon access when those keys are
 # found to be expired, and also in background, in what is called the
 # "active expire key". The key space is slowly and interactively scanned
 # looking for expired keys to reclaim, so that it is possible to free memory
@@ -1011,63 +1011,17 @@ replica-lazy-flush no
 
 lazyfree-lazy-user-del no
 
-################################ THREADED I/O #################################
-
-# Redis is mostly single threaded, however there are certain threaded
-# operations such as UNLINK, slow I/O accesses and other things that are
-# performed on side threads.
-#
-# Now it is also possible to handle Redis clients socket reads and writes
-# in different I/O threads. Since especially writing is so slow, normally
-# Redis users use pipelining in order to speed up the Redis performances per
-# core, and spawn multiple instances in order to scale more. Using I/O
-# threads it is possible to easily speedup two times Redis without resorting
-# to pipelining nor sharding of the instance.
-#
-# By default threading is disabled, we suggest enabling it only in machines
-# that have at least 4 or more cores, leaving at least one spare core.
-# Using more than 8 threads is unlikely to help much. We also recommend using
-# threaded I/O only if you actually have performance problems, with Redis
-# instances being able to use a quite big percentage of CPU time, otherwise
-# there is no point in using this feature.
-#
-# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
-# threads, if you have a 8 cores, try to use 6 threads. In order to
-# enable I/O threads use the following configuration directive:
-#
-# io-threads 4
-#
-# Setting io-threads to 1 will just use the main thread as usual.
-# When I/O threads are enabled, we only use threads for writes, that is
-# to thread the write(2) syscall and transfer the client buffers to the
-# socket. However it is also possible to enable threading of reads and
-# protocol parsing using the following configuration directive, by setting
-# it to yes:
-#
-# io-threads-do-reads no
-#
-# Usually threading reads doesn't help much.
-#
-# NOTE 1: This configuration directive cannot be changed at runtime via
-# CONFIG SET. Aso this feature currently does not work when SSL is
-# enabled.
-#
-# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make
-# sure you also run the benchmark itself in threaded mode, using the
-# --threads option to match the number of Redis threads, otherwise you'll not
-# be able to notice the improvements.
-
 ############################ KERNEL OOM CONTROL ##############################
 
 # On Linux, it is possible to hint the kernel OOM killer on what processes
 # should be killed first when out of memory.
 #
-# Enabling this feature makes Redis actively control the oom_score_adj value
+# Enabling this feature makes KeyDB actively control the oom_score_adj value
 # for all its processes, depending on their role. The default scores will
 # attempt to have background child processes killed before all others, and
 # replicas killed before masters.
 #
-# Redis supports three options:
+# KeyDB supports three options:
 #
 # no:       Don't make changes to oom-score-adj (default).
 # yes:      Alias to "relative" see below.
@@ -1491,64 +1445,6 @@ latency-monitor-threshold 0
 #  specify at least one of K or E, no events will be delivered.
 notify-keyspace-events ""
 
-############################### GOPHER SERVER #################################
-
-# KeyDB contains an implementation of the Gopher protocol, as specified in
-# the RFC 1436 (https://www.ietf.org/rfc/rfc1436.txt).
-#
-# The Gopher protocol was very popular in the late '90s. It is an alternative
-# to the web, and the implementation both server and client side is so simple
-# that the KeyDB server has just 100 lines of code in order to implement this
-# support.
-#
-# What do you do with Gopher nowadays? Well Gopher never *really* died, and
-# lately there is a movement in order for the Gopher more hierarchical content
-# composed of just plain text documents to be resurrected. Some want a simpler
-# internet, others believe that the mainstream internet became too much
-# controlled, and it's cool to create an alternative space for people that
-# want a bit of fresh air.
-#
-# Anyway for the 10nth birthday of the KeyDB, we gave it the Gopher protocol
-# as a gift.
-#
-# --- HOW IT WORKS? ---
-#
-# The KeyDB Gopher support uses the inline protocol of KeyDB, and specifically
-# two kind of inline requests that were anyway illegal: an empty request
-# or any request that starts with "/" (there are no KeyDB commands starting
-# with such a slash). Normal RESP2/RESP3 requests are completely out of the
-# path of the Gopher protocol implementation and are served as usual as well.
-#
-# If you open a connection to KeyDB when Gopher is enabled and send it
-# a string like "/foo", if there is a key named "/foo" it is served via the
-# Gopher protocol.
-#
-# In order to create a real Gopher "hole" (the name of a Gopher site in Gopher
-# talking), you likely need a script like the following:
-#
-#   https://github.com/antirez/gopher2redis
-#
-# --- SECURITY WARNING ---
-#
-# If you plan to put KeyDB on the internet in a publicly accessible address
-# to server Gopher pages MAKE SURE TO SET A PASSWORD to the instance.
-# Once a password is set:
-#
-#   1. The Gopher server (when enabled, not by default) will still serve
-#      content via Gopher.
-#   2. However other commands cannot be called before the client will
-#      authenticate.
-#
-# So use the 'requirepass' option to protect your instance.
-#
-# Note that Gopher is not currently supported when 'io-threads-do-reads'
-# is enabled.
-#
-# To enable Gopher support, uncomment the following line and set the option
-# from no (the default) to yes.
-#
-# gopher-enabled no
-
 ############################### ADVANCED CONFIG ###############################
 
 # Hashes are encoded using a memory efficient data structure when they have a
@@ -1861,14 +1757,14 @@ rdb-save-incremental-fsync yes
 # Jemalloc background thread for purging will be enabled by default
 jemalloc-bg-thread yes
 
-# It is possible to pin different threads and processes of Redis to specific
+# It is possible to pin different threads and processes of KeyDB to specific
 # CPUs in your system, in order to maximize the performances of the server.
-# This is useful both in order to pin different Redis threads in different
-# CPUs, but also in order to make sure that multiple Redis instances running
+# This is useful both in order to pin different KeyDB threads in different
+# CPUs, but also in order to make sure that multiple KeyDB instances running
 # in the same host will be pinned to different CPUs.
 #
 # Normally you can do this using the "taskset" command, however it is also
-# possible to this via Redis configuration directly, both in Linux and FreeBSD.
+# possible to this via KeyDB configuration directly, both in Linux and FreeBSD.
 #
 # You can pin the server/IO threads, bio threads, aof rewrite child process, and
 # the bgsave child process. The syntax to specify the cpu list is the same as