PyPI - amps-python-client - Versions diffs - 5.3.4.1__zip → 5.3.4.2__zip - Mend

amps-python-client 5.3.4.1zip → 5.3.4.2zip

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (917) hide show

amps-python-client-5.3.4.1/docs/python/html/chapters/performance-tips.html DELETED Viewed

@@ -1,499 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
-  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
-  <head>
-    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-    <title>13. Performance Tips and Best Practices &#8212; Python Developer Guide develop
- documentation</title>
-    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
-    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
-    <script type="text/javascript">
-      var DOCUMENTATION_OPTIONS = {
-        URL_ROOT:    '../',
-        VERSION:     'develop',
-        COLLAPSE_INDEX: false,
-        FILE_SUFFIX: '.html',
-        HAS_SOURCE:  true,
-        SOURCELINK_SUFFIX: '.txt'
-      };
-    </script>
-    <script type="text/javascript" src="../_static/jquery.js"></script>
-    <script type="text/javascript" src="../_static/underscore.js"></script>
-    <script type="text/javascript" src="../_static/doctools.js"></script>
-    <link rel="index" title="Index" href="../genindex.html" />
-    <link rel="search" title="Search" href="../search.html" />
-    <link rel="next" title="14. Migrating from Earlier Python Implementations" href="moving-from-python-lite.html" />
-    <link rel="prev" title="12. Advanced Topics" href="advanced-topics.html" />
-  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
-  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
-  </head>
-  <body role="document">
-  <div class="document">
-      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
-        <div class="sphinxsidebarwrapper">
-            <p class="logo"><a href="../index.html">
-              <img class="logo" src="../_static/flag_logo.png" alt="Logo"/>
-            </a></p>
-  <h3><a href="../index.html">Table Of Contents</a></h3>
-  <ul>
-<li><a class="reference internal" href="#">13. Performance Tips and Best Practices</a><ul>
-<li><a class="reference internal" href="#measure-performance-and-set-goals">Measure Performance and Set Goals</a></li>
-<li><a class="reference internal" href="#use-haclient-and-heartbeating-where-appropriate">Use HAClient and Heartbeating Where Appropriate</a></li>
-<li><a class="reference internal" href="#simplify-message-format-and-contents">Simplify Message Format and Contents</a></li>
-<li><a class="reference internal" href="#measure-serialization-and-deserialization">Measure Serialization and Deserialization</a></li>
-<li><a class="reference internal" href="#use-content-filtering-where-possible">Use Content Filtering Where Possible</a></li>
-<li><a class="reference internal" href="#use-asynchronous-message-processing">Use Asynchronous Message Processing</a></li>
-<li><a class="reference internal" href="#use-hash-indexes-where-possible-for-sow-queries">Use Hash Indexes Where Possible for SOW Queries</a></li>
-<li><a class="reference internal" href="#use-a-failed-write-handler-and-exception-listener">Use a Failed Write Handler and Exception Listener</a></li>
-<li><a class="reference internal" href="#reduce-bandwidth-requirements">Reduce Bandwidth Requirements</a><ul>
-<li><a class="reference internal" href="#tune-batch-size-for-sow-queries">Tune Batch Size for SOW Queries</a></li>
-<li><a class="reference internal" href="#conflate-fast-changing-information">Conflate Fast-Changing Information</a></li>
-<li><a class="reference internal" href="#minimize-bandwidth-for-updates">Minimize Bandwidth for Updates</a></li>
-<li><a class="reference internal" href="#conflate-queue-acknowledgments">Conflate Queue Acknowledgments</a></li>
-<li><a class="reference internal" href="#use-a-transaction-log-when-monitoring-publish-failures">Use a Transaction Log When Monitoring Publish Failures</a></li>
-<li><a class="reference internal" href="#combine-conflation-and-deltas">Combine Conflation and Deltas</a></li>
-</ul>
-</li>
-<li><a class="reference internal" href="#limit-unnecessary-copies">Limit Unnecessary Copies</a></li>
-<li><a class="reference internal" href="#manage-publish-stores">Manage Publish Stores</a></li>
-<li><a class="reference internal" href="#use-the-server-logs-to-help-troubleshoot">Use the Server Logs to Help Troubleshoot</a></li>
-<li><a class="reference internal" href="#work-with-60east-as-necessary">Work with 60East as Necessary</a></li>
-</ul>
-</li>
-</ul>
-<div class="relations">
-<h3>Related Topics</h3>
-<ul>
-  <li><a href="../index.html">Documentation overview</a><ul>
-      <li>Previous: <a href="advanced-topics.html" title="previous chapter">12. Advanced Topics</a></li>
-      <li>Next: <a href="moving-from-python-lite.html" title="next chapter">14. Migrating from Earlier Python Implementations</a></li>
-  </ul></li>
-</ul>
-</div>
-<div id="searchbox" style="display: none" role="search">
-  <h3>Quick search</h3>
-    <form class="search" action="../search.html" method="get">
-      <div><input type="text" name="q" /></div>
-      <div><input type="submit" value="Go" /></div>
-      <input type="hidden" name="check_keywords" value="yes" />
-      <input type="hidden" name="area" value="default" />
-    </form>
-</div>
-<script type="text/javascript">$('#searchbox').show(0);</script>
-        </div>
-      </div>
-      <div class="documentwrapper">
-        <div class="bodywrapper">
-          <div class="body" role="main">
-  <div class="section" id="performance-tips-and-best-practices">
-<h1>13. Performance Tips and Best Practices<a class="headerlink" href="#performance-tips-and-best-practices" title="Permalink to this headline">¶</a></h1>
-<p>This chapter presents tips and techniques for writing high-performance
-applications with AMPS. This section presents principles and approaches
-that describe how to use the features of AMPS and the AMPS client
-libraries to achieve high performance and reliability.</p>
-<p>Specific techniques (for example, the details on how to write a message
-handler) are described in other parts of the AMPS documentation and
-referenced here. Other techniques require information specific to the
-application (for example, determining the minimum set of information
-required in a message), and are best done as part of your application
-design.</p>
-<p>All of the recommendations in this section are general guidelines. There
-are few, if any, universal rules for performance: at times, a design
-decision that is absolutely necessary to meet the requirements for an
-application might reduce performance somewhat. For example, your
-application might involve sending large binary data that cannot be
-incrementally updated. That application will use more bandwidth per
-message than an application that sends 100-byte messages with fields
-that can be incrementally updated. However, since the application
-depends on being able to deliver the binary payloads, this difference in
-bandwidth consumption is a part of the requirements for the application,
-not a design decision that can be optimized.</p>
-<div class="section" id="measure-performance-and-set-goals">
-<h2>Measure Performance and Set Goals<a class="headerlink" href="#measure-performance-and-set-goals" title="Permalink to this headline">¶</a></h2>
-<p>The most important tools for creating high performance applications that
-use AMPS are clear goals and accurate measurement. Without accurate
-measurement, it&#8217;s impossible to know whether a particular change has
-improved performance or not. Without clear goals, it&#8217;s difficult to know
-whether a given result is sufficient, or whether you need to continue
-improving performance.</p>
-<p>60East recommends that your measurements include baseline metrics for
-the part of your message processing that does not involve AMPS. As an
-example, imagine your task is to reduce the amount of time that elapses
-between when an order is sent and when the processed response is
-received from 100ms in total to 85ms in total. To achieve this
-reduction, you might first measure the processing that your application
-performs on the order. If that processing consumes 65ms, the most
-effective optimization may be to improve the order processing. On the
-other hand, if processing an order consumes 15ms, then optimizing
-message delivery or network utilization may be the most effective way to
-meet your goals.</p>
-<p>When measuring performance, simulate your production environment as
-closely as possible. For example, AMPS is highly parallelized, so
-sending a pattern of subscriptions and publishes from a single test
-client that would normally come from 20 clients will produce a very
-different performance profile. Likewise, AMPS can typically perform at
-rates that fill the available bandwidth. Performance measured on a 1GbE
-connection may be very different than performance measured over a 10GbE
-connection. Consider the characteristics of your data, and the number of
-messages you expect to store and process. A 1GB data set consisting of 1
-million records will perform differently than a 1GB data set consisting
-of 10 million records, or a 1GB data set consisting of 100 records.</p>
-<p>When collecting information about performance, 60East recommends
-enabling persistence for the Statistics Database (<code class="docutils literal"><span class="pre">stats.db</span></code>), so you
-can easily collect historical data on both AMPS and the operating
-system. For example, a dip in performance correlated with high CPU and
-memory usage at the same time each day may be correlated with other
-activity on the system (such as cron jobs or close of business
-processing). In a situation like that, where the performance reduction
-is based on factors external to the AMPS application, the overall system
-metrics captured in <code class="docutils literal"><span class="pre">stats.db</span></code> can help you re-create the external
-state and understand the state of the system as a whole. AMPS collects
-the statistics in memory by default, and persisting that data into a
-database does not typically have a measurable effect on performance
-itself, but makes measuring and tuning performance much easier.</p>
-<p>For performance testing, 60East recommends using dedicated hardware for
-AMPS to eliminate the effects of other processes. If dedicated hardware
-is not available and other processes are consuming resources, 60East
-recommends disabling AMPS NUMA tuning to ensure that AMPS threads do not
-unnecessarily compete with other processes during performance tuning.</p>
-</div>
-<div class="section" id="use-haclient-and-heartbeating-where-appropriate">
-<h2>Use HAClient and Heartbeating Where Appropriate<a class="headerlink" href="#use-haclient-and-heartbeating-where-appropriate" title="Permalink to this headline">¶</a></h2>
-<p>Not every application that uses AMPS requires high availability and the
-ability to automatically fail over if connectivity is lost or an instance
-of AMPS is offline. For applications that do need automatic reconnection,
-60East strongly recommends using the <code class="docutils literal"><span class="pre">HAClient</span></code> and setting heartbeating
-for the client to effectively detect disconnection.</p>
-<p>When using the <code class="docutils literal"><span class="pre">HAClient</span></code> and heartbeating, there are two important
-guidelines to follow:</p>
-<ul class="simple">
-<li>Do not replace the disconnect handler on the <code class="docutils literal"><span class="pre">HAClient</span></code>. The
-disconnect handler is responsible for reconnection, resubscription, and
-so on. If you need to detect disconnection, use a connection state listener.</li>
-<li>Set the interval for heartbeating to approximately one-half the time
-that the application can tolerate interruption in message flow. Notice
-that it&#8217;s not possible for the <code class="docutils literal"><span class="pre">HAClient</span></code> to tell the difference
-between an interruption in message flow caused by a server going offline
-and interruptions caused by an increase in latency due to network
-saturation or so on, so the interval should be somewhat larger than the
-highest expected latency between AMPS and the application. Last, but
-not least, if the application uses asynchronous message handling, the
-interval should also be set to a value larger than the maximum amount
-of time expected for the message handler to process a single message.</li>
-</ul>
-</div>
-<div class="section" id="simplify-message-format-and-contents">
-<h2>Simplify Message Format and Contents<a class="headerlink" href="#simplify-message-format-and-contents" title="Permalink to this headline">¶</a></h2>
-<p>AMPS supports a wide range of message types, and is capable of filtering
-and processing large and complex messages. For many applications, the
-simplicity of being able to use messages that contain the full
-information is the most important consideration. For other applications,
-however, achieving the minimum possible latency and the maximum possible
-network utilization is important enough to warrant choosing a simplified
-message format.</p>
-<p>To simplify message contents, carefully consider the information that
-downstream processors require. If a downstream process will not use
-information in the message, there is no need to send the information.
-For example, consider an application that provides orders from a UI. In
-such an application, the object that represents the order often contains
-information relevant to the local state of the application that is not
-relevant to a downstream system. Rather than simply serializing the full
-object, your application may perform better if you serialize only the
-fields that a downstream system will take action on.</p>
-<p>To simplify message format, choose the simplest format that can convey
-the information that your application needs. The general principle is
-that the simpler the message format is, the more quickly AMPS and client
-libraries can parse messages of that type. Likewise, the more
-complicated the structure of each message is, the more work is required
-to parse the message. For the highest levels of performance, 60East
-recommends keeping the message structure simple and preferring message
-formats such as NVFIX, BFlat, or flattened JSON (structured as key/value
-pairs) as compared with more complicated formats such as XML or BSON.</p>
-</div>
-<div class="section" id="measure-serialization-and-deserialization">
-<h2>Measure Serialization and Deserialization<a class="headerlink" href="#measure-serialization-and-deserialization" title="Permalink to this headline">¶</a></h2>
-<p>When creating baseline performance numbers, measure
-serialization and deserialization performance independent
-of the AMPS server or client libraries.</p>
-<p>This can help you to:</p>
-<ul class="simple">
-<li>Understand the baseline performance of creating
-and processing message data under ideal conditions
-(that is, where there is no application processing,
-networking, routing, etc. involved).</li>
-<li>Easily compare the application-side performance of
-different message formats or different message
-layouts within a single format.</li>
-</ul>
-<p>When testing this performance, it is helpful to
-use data similar to the data that the application
-will actually process during a business day, at
-the volumes the application would typically
-process. This will help you understand the
-performance of serialization and deserialization
-for this specific application. For example,
-a library for working with a given message format
-might be less efficient when processing
-messages with a large number of string fields in
-a deeply-nested structure, but your application
-might exchange only numeric data in a relatively flat
-structure. Likewise, the library for a given format
-could be efficient for processing a small number of
-fields, but have lower performance for a message
-type with hundreds of fields.</p>
-<p>As with all performance testing, the more closely
-the test environment matches the actual data
-and volumes of a production environment, the
-more helpful those measurements will be for
-understanding system performance.</p>
-</div>
-<div class="section" id="use-content-filtering-where-possible">
-<h2>Use Content Filtering Where Possible<a class="headerlink" href="#use-content-filtering-where-possible" title="Permalink to this headline">¶</a></h2>
-<p>AMPS content filtering helps your application perform better by ensuring
-that your application only receives the messages that it needs. Wherever
-possible, we recommend using content filtering to precisely specify
-which messages your application needs. In particular, if at any point
-your application is receiving a message, parsing the message, and then
-determining whether to act on the message or not, 60East recommends
-using content filters to ensure that your application only receives
-messages that it needs to act on.</p>
-</div>
-<div class="section" id="use-asynchronous-message-processing">
-<h2>Use Asynchronous Message Processing<a class="headerlink" href="#use-asynchronous-message-processing" title="Permalink to this headline">¶</a></h2>
-<p>The synchronous message processing interface is straightforward, and
-presents a convenient interface for getting started with AMPS.</p>
-<p>However, the <code class="docutils literal"><span class="pre">MessageStream</span></code> used by the synchronous interface makes a
-full copy of each message and provides it from the background reader
-thread to the thread that consumes the message. This memory overhead and
-synchronization between the reader thread and consumer thread happens
-regardless of whether the application needs all of the header fields in
-the message or even processes the message. The <code class="docutils literal"><span class="pre">MessageStream</span></code> also
-does not take into account the speed at which your program is consuming
-messages, and will read messages into memory as fast as the network and
-processor allow. If your application cannot consume messages at wire
-speed, this can lead to increasing memory consumption as the application
-falls further behind the <code class="docutils literal"><span class="pre">MessageStream</span></code>.</p>
-<p>Most applications see improved performance by using a
-<code class="docutils literal"><span class="pre">MessageHandler</span></code>. With this approach, the <code class="docutils literal"><span class="pre">MessageHandler</span></code> does
-minimal work. If more extensive processing is needed, the
-<code class="docutils literal"><span class="pre">MessageHandler</span></code> dispatches the work to another thread: but it does
-this only when the work is necessary, and it only saves the part of the
-message needed to accomplish the work.</p>
-</div>
-<div class="section" id="use-hash-indexes-where-possible-for-sow-queries">
-<h2>Use Hash Indexes Where Possible for SOW Queries<a class="headerlink" href="#use-hash-indexes-where-possible-for-sow-queries" title="Permalink to this headline">¶</a></h2>
-<p>When querying a SOW, hash indexes on SOW topics are supported for exact
-matching on string data as described in the <em>AMPS User Guide</em>. A hash
-index can perform many times faster than a parallel query. If the query
-pattern for your application can take advantage of hash indexes, 60East
-recommends creating those hash indexes on your SOW topics.</p>
-<p>More recent versions of AMPS can use hash indexes for a wider variety of
-filters. When planning your queries, review the SOW queries section of
-the <em>AMPS User Guide</em> for the version you are using for guidelines on
-the optimizations available in that version.</p>
-</div>
-<div class="section" id="use-a-failed-write-handler-and-exception-listener">
-<h2>Use a Failed Write Handler and Exception Listener<a class="headerlink" href="#use-a-failed-write-handler-and-exception-listener" title="Permalink to this headline">¶</a></h2>
-<p>In many cases, particularly during the early stages of development,
-performance problems can point to defects in the application. Even after
-the application is tuned, monitoring for failure is important to keep
-applications running smoothly.</p>
-<p>60East recommends always installing a failed write handler if your
-application is publishing messages. This will help you to quickly
-identify cases where AMPS is rejecting publishes due to entitlement
-failures, message type mismatches, or other similar problems.</p>
-<p>60East recommends always installing an exception listener if your
-application is using asynchronous message processing. This will help you
-to identify and correct any problems with your message handler. An
-exception listener should typically log the message received
-and return.  If recovery is needed, the listener should set a
-flag for another thread to process rather than attempting to
-recover on the thread that calls the exception listener.</p>
-</div>
-<div class="section" id="reduce-bandwidth-requirements">
-<h2>Reduce Bandwidth Requirements<a class="headerlink" href="#reduce-bandwidth-requirements" title="Permalink to this headline">¶</a></h2>
-<p>In many applications that use AMPS, network bandwidth is the single most
-important factor in overall performance. Your application can use
-bandwidth most efficiently by reducing message size. For example, rather
-than serializing an entire object, you might serialize only the fields
-that the remote process needs to act on, as mentioned above. Likewise,
-rather than sending one message that contains a collected set of
-information that processors will need to extract, consider sending a
-message in the units that processors will work with. This can reduce
-bandwidth to processors substantially. For example, rather than sending
-a single message with all of the activity for a single customer over a
-given period of time (such as a trading day), consider breaking out the
-record into the individual transactions for the customer.</p>
-<div class="section" id="tune-batch-size-for-sow-queries">
-<h3>Tune Batch Size for SOW Queries<a class="headerlink" href="#tune-batch-size-for-sow-queries" title="Permalink to this headline">¶</a></h3>
-<p>As described in the <a class="reference external" href="../../../python/html/chapters/sow.html#setting-batch-size">section on SOW batch size</a>, tuning the batch size for
-SOW queries can improve overall performance by improving network
-utilization. In addition, because the AMPS header is only parsed once
-per batch, a larger batch size can dramatically improve processing
-performance for smaller messages.</p>
-<p>The AMPS clients default to a batch size of <code class="docutils literal"><span class="pre">10</span></code>. This provides
-generally good performance for most transactional messages (such as
-order records or inventory records). For large messages, particularly
-messages greater than a megabyte in size, a batch size of <code class="docutils literal"><span class="pre">1</span></code> may
-reduce memory pressure in the client and improve performance.</p>
-<p>With smaller messages (for example, message sizes of a few hundred
-bytes), 60East recommends measuring performance with larger batch sizes
-such as <code class="docutils literal"><span class="pre">50</span></code> or <code class="docutils literal"><span class="pre">100</span></code> . For large messages, reducing the batch size
-may improve overall performance by requiring less memory consumption on
-the AMPS server.</p>
-</div>
-<div class="section" id="conflate-fast-changing-information">
-<h3>Conflate Fast-Changing Information<a class="headerlink" href="#conflate-fast-changing-information" title="Permalink to this headline">¶</a></h3>
-<p>If your data source publishes information faster than your clients need
-to consume it, consider using a conflated topic. For example, in a
-system that presents a user interface and displays fast-moving data, it
-is common for the data to change at a rate faster than the user
-interface can format and render the data. In this case, a conflated
-topic can both reduce bandwidth and simplify processing in the user
-interface.</p>
-</div>
-<div class="section" id="minimize-bandwidth-for-updates">
-<h3>Minimize Bandwidth for Updates<a class="headerlink" href="#minimize-bandwidth-for-updates" title="Permalink to this headline">¶</a></h3>
-<p>If your application uses a SOW and processes frequent updates, consider
-using delta publish and delta subscribe to reduce the size of the
-messages transmitted. These features are designed to minimize bandwidth
-while still providing full-fidelity data streams.</p>
-</div>
-<div class="section" id="conflate-queue-acknowledgments">
-<h3>Conflate Queue Acknowledgments<a class="headerlink" href="#conflate-queue-acknowledgments" title="Permalink to this headline">¶</a></h3>
-<p>The AMPS clients include the ability to conflate acknowledgments back
-to AMPS as queue messages are processed. Using these features, with an
-appropriate <code class="docutils literal"><span class="pre">max_backlog</span></code>, can reduce the amount of network traffic
-required for acknowledgments.</p>
-</div>
-<div class="section" id="use-a-transaction-log-when-monitoring-publish-failures">
-<h3>Use a Transaction Log When Monitoring Publish Failures<a class="headerlink" href="#use-a-transaction-log-when-monitoring-publish-failures" title="Permalink to this headline">¶</a></h3>
-<p>When a topic is not covered by a transaction log, AMPS returns
-acknowledgment messages for every publish that requests one. This
-ensures that each message is acknowledged, even when AMPS has no
-persistent record of the messages in the topic. However, acknowledging
-each message requires more network traffic for each publish message.</p>
-<p>When a topic is covered by a transaction log, AMPS conflates persisted
-acknowledgments. Conflation is possible in this case because AMPS has a
-full record of the messages and does not have to store additional state
-to conflate the acknowledgments. With conflated acknowledgments, AMPS
-will send a success acknowledgment periodically that covers all
-messages up to that point. If a message fails, AMPS immediately sends
-the conflated success acknowledgment for all previous messages and the
-failure acknowledgment for the failed message.</p>
-</div>
-<div class="section" id="combine-conflation-and-deltas">
-<h3>Combine Conflation and Deltas<a class="headerlink" href="#combine-conflation-and-deltas" title="Permalink to this headline">¶</a></h3>
-<p>In many cases, using an approach that combines delta publishes to a SOW
-with delta subscriptions to a conflated topic can dramatically reduce
-bandwidth to the application with no loss of information.</p>
-</div>
-</div>
-<div class="section" id="limit-unnecessary-copies">
-<h2>Limit Unnecessary Copies<a class="headerlink" href="#limit-unnecessary-copies" title="Permalink to this headline">¶</a></h2>
-<p>One of the most effective ways to increase performance is to limit the
-amount of data copied within your application.</p>
-<p>For example, if your message handler submits work to a set of processors
-that only use the <code class="docutils literal"><span class="pre">Data</span></code> and <code class="docutils literal"><span class="pre">Bookmark</span></code> from a <code class="docutils literal"><span class="pre">Message</span></code>, create a
-data structure that holds only those fields and copy that information
-into instances of that data structure rather than copying the entire
-<code class="docutils literal"><span class="pre">Message</span></code>. While this approach requires a few extra lines of code, the
-performance benefits can be substantial.</p>
-<p>When publishing messages to AMPS, avoid unnecessary copies of the data.
-For example, if you have the data in a byte array, use the <code class="docutils literal"><span class="pre">publish</span></code>
-methods that use a byte array rather than converting the data to a
-string unnecessarily. Likewise, if you have the data in the form of a
-string, avoid converting it to a byte array where possible.</p>
-</div>
-<div class="section" id="manage-publish-stores">
-<h2>Manage Publish Stores<a class="headerlink" href="#manage-publish-stores" title="Permalink to this headline">¶</a></h2>
-<p>When using a publish store, the Client holds messages until they are
-acknowledged as persisted by AMPS, as determined by the replication
-configuration for the AMPS instance.</p>
-<p>In the event that an instance with <code class="docutils literal"><span class="pre">sync</span></code> replication goes offline,
-the publish store for the Client will grow, since the messages are not
-being fully persisted. To avoid this problem, 60East recommends that an
-instance that uses <code class="docutils literal"><span class="pre">sync</span></code> replication always configure Actions to
-automatically downgrade the replication link if the remote instance goes
-offline for a period of time, and upgrade the link when the remote
-instance comes back online.</p>
-<p>Further, 60East recommends that, where possible, a publisher is
-provisioned with enough storage to hold its complete publish stream
-for the amount of time that a destination may be offline or
-unavailable without downgrading from <code class="docutils literal"><span class="pre">sync</span></code> replication to
-<code class="docutils literal"><span class="pre">async</span></code> replication. For example, if the server considers a downstream
-system to be unreachable if it has not acknowledged a replicated message
-in 60 seconds, and the server checks this threshold every 10 seconds,
-then a publisher should plan that, at any time, the publisher may need
-to retain approximately 70 seconds worth of published messages. This is
-calculated as the 60 seconds threshold that the server has established for a
-destination to run behind, plus the 10 second interval at which the server
-checks whether the destination is within the threshold. Also notice
-that, with a configuration like this, a downstream replication destination
-could run as much as 59 seconds behind indefinitely. A publisher should
-be provisioned to be able to run effectively in a &#8220;worst case&#8221; (or nearly
-&#8220;worst case&#8221;) scenario for an extended period of time.</p>
-<p>See the &#8220;High Availability and Replication&#8221; chapter in the <em>User Guide</em>
-for more information on replication, sync and async acknowledgment
-modes, and the Actions used to manage replication.</p>
-</div>
-<div class="section" id="use-the-server-logs-to-help-troubleshoot">
-<h2>Use the Server Logs to Help Troubleshoot<a class="headerlink" href="#use-the-server-logs-to-help-troubleshoot" title="Permalink to this headline">¶</a></h2>
-<p>When troubleshooting problems with an application that uses AMPS, the
-server-side logs often provide the most helpful information. For example,
-<code class="docutils literal"><span class="pre">trace</span></code> level logging shows the data that is flowing through AMPS.
-Log messages at <code class="docutils literal"><span class="pre">info</span></code> level show events as incoming connections,
-commands from clients, and so on. When questions arise about how the server
-and application interact, the server logs often contain the information.</p>
-<p>60East recommends that an AMPS instance used for development and testing
-log at <code class="docutils literal"><span class="pre">trace</span></code> level, and that a server used for production log at
-<code class="docutils literal"><span class="pre">info</span></code> level, with the ability to log at <code class="docutils literal"><span class="pre">trace</span></code> level when necessary
-for investigating any problems that may arise.</p>
-<p>When a command does not have the expected result, or an application
-reports an error, the fastest way to understand the problem is often
-to review the <code class="docutils literal"><span class="pre">trace</span></code> level logging for the instance.  See the
-<strong>AMPS User Guide</strong> for details on configuring logging and common
-patterns for searching for information in AMPS logs.</p>
-</div>
-<div class="section" id="work-with-60east-as-necessary">
-<h2>Work with 60East as Necessary<a class="headerlink" href="#work-with-60east-as-necessary" title="Permalink to this headline">¶</a></h2>
-<p>60East offers performance advice adapted for your specific usage through
-your support agreement. Once you&#8217;ve set your performance goals, worked
-through the general best practices and applied the practices that make
-sense for your application, 60East can help with detailed performance
-tuning, including recommendations that are specific to your use case and
-performance needs.</p>
-</div>
-</div>
-          </div>
-        </div>
-      </div>
-    <div class="clearer"></div>
-  </div>
-    <div class="footer">
-      &copy;2022, 60East Technologies, Inc..
-      |
-      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.5.3</a>
-      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-    </div>
-  </body>
-</html>

amps-python-client 5.3.4.1__zip → 5.3.4.2__zip

amps-python-client 5.3.4.1zip → 5.3.4.2zip