Removing obsolete pages (#916)

* Removing obsolete pages that are not in nav.

Also, cleaning up duplicate contents.

* Removing another obsolete adoc.

* Testing links.

docs/modules/ROOT/nav.adoc

@@ -18,9 +18,7 @@ include::pipelines:partial$nav.adoc[]
 include::query:partial$nav.adoc[]
 * Improving Query Performance
 ** xref:query:indexing-maps.adoc[]
-** xref:performance:data-affinity.adoc[]
 ** xref:performance:caching-deserialized-values.adoc[]
-** xref:performance:near-cache.adoc[]
 ** xref:data-structures:preventing-out-of-memory.adoc[]
 * SQL
 +

docs/modules/ROOT/pages/capacity-planning.adoc

@@ -44,7 +44,7 @@ For example, an application may plan for 10,000 user TPS but each user
 transaction may need to use Hazelcast 3 times during the execution. So the
 actual Hazelcast throughput would need to be 30,000 TPS. Similarly for latency, the answer
 should not be about end-to-end latency but the application-to-Hazelcast latency.
-* How many concurrent Hazelcast xref:configuration:jet-configuration.adoc[jobs] will the cluster run?
+* How many concurrent Hazelcast xref:pipelines:configuring-jobs.adoc[jobs] will the cluster run?
 * What is the approximation duration of a job?
 * When you use stream processing, what is the average approximation latency for processing of a single event?
 * What is the intended xref:pipelines:sources-sinks.adoc[sink] for your jobs (database, dashboard, file system, etc.)?

docs/modules/cluster-performance/pages/best-practices.adoc

@@ -1,4 +1,5 @@
 = Best Practices
+:page-aliases: performance:data-affinity.adoc, performance:near-cache.adoc, performance:back-pressure.adoc, performance:cpu-thread-affinity.adoc, performance:best-practices.adoc, performance:pipelining.adoc, performance:slowoperationdetector.adoc, performance:threading-model.adoc
 
 [[basic-recs]]
 == Basic Performance Recommendations
@@ -1200,7 +1201,7 @@ You can also combine those, e.g., `1,2,[5-7],[10,12,16]:2`.
 Note that, the syntax for CPU thread affinity shown above not only determines
 the mapping of CPUs to threads, it also determines the thread count.
 If you use CPU thread affinity, e.g., `hazelcast.io.input.thread.affinity`,
-then `hazelcast.io.input.thread.count` is ignored. See xref:performance:threading-model.adoc#io-threading[Threading Model] for more
+then `hazelcast.io.input.thread.count` is ignored. See <<threading-model, Threading Model>> for more
 information about specifying explicit thread counts.
 
 If you don't configure affinity for a category of threads, it means they can run on any CPU.
@@ -1473,51 +1474,4 @@ You can configure the purge interval and the retention time for each invocation.
 The purging removes each invocation whose retention time is exceeded.
 When all invocations are purged from a slow operation log, the log is deleted.
 
-== Caching Deserialized Values
-
-There may be cases where you do not want to deserialize some values in your Hazelcast map again which were already deserialized previously.
-This way your query operations get faster.
-This is possible by using the `cache-deserialized-values` element in your declarative Hazelcast configuration, as shown below.
-
-[tabs] 
-==== 
-XML:: 
-+ 
--- 
-[source,xml]
-----
-<hazelcast>
-    ...
-    <map name="myMap">
-        <in-memory-format>BINARY</in-memory-format>
-        <cache-deserialized-values>INDEX-ONLY</cache-deserialized-values>
-        <backup-count>1</backup-count>
-    </map>
-    ...
-</hazelcast>
-----
---
-YAML::
-+
---
-[source,yaml]
-----
-hazelcast:
-  map:
-    myMap:
-      in-memory-format: BINARY
-      cache-deserialized-values: INDEX-ONLY
-      backup-count: 1
-----
---	
-====
-
-The `cache-deserialized-values` element controls the caching of deserialized values.
-Note that caching makes the query evaluation faster, but it consumes more memory. This element has the following values:
-
-* NEVER: Deserialized values are never cached.
-* INDEX-ONLY: Deserialized values are cached only when they are inserted into an index.
-* ALWAYS: Deserialized values are always cached.
-
-If you are using xref:serialization:implementing-portable-serialization.adoc[Portable] / xref:serialization:compact-serialization.adoc[Compact] serialization or your map's in-memory format is `OBJECT` or `NATIVE`, then `cache-deserialized-values` element does not have any effect.