我遇到了使用Postgre SQL作为后端的医疗logging程序的问题。
几个办事处通过思科VPN连接到企业网站。 在企业中有一个ASA5055，大多数站点使用PIX。 我已经确定速度不是问题，因为我可以通过VPN以大约500KB / s的速度对称地通过netshare发送/接收文件。
我在一个testing帐户的软件上运行一个报告，显示一个简单的1页报告，如果它是一个PDF文件，它将运行总计大约50KB。 如果报告在LAN上运行，则会立即显示。 当远程运行时，即使在所有其他办公室都closures的情况下，没有任何其他事情正在通过隧道，也需要40-50秒。 使用这些信息，我认为报告的大小不超过200KB。 平均在100毫秒以下。
在此期间，我可以通过任务pipe理器观看networking界面，看起来报告正以5-10KB / s的速度“stream”到客户端。
服务器是2008R2 Enterprise，2x 4核心Xeon，56GB RAM。 系统似乎按预期运行，没有I / O错误。
究竟是什么原因或解决这个谜？ 有什么特别的，我应该看看进一步解决这个问题？
您可能会遇到延迟问题。 我已经看到数据库性能蹩脚的链接得到彻头彻尾的邪恶。 我的下一步是采取本地和远程连接的数据包跟踪（可能可以在数据库服务器上完成），并查看数据包之间的相对时间。 在两种情况下，一个stream中的单个文件的砰砰声可能会很快，如果事务需要客户端和服务器之间的一些来回的延迟，可能会导致吞吐量的下降。
正如Erik评论的那样，这个问题可能是延迟。
你可以尝试这个实验。 在服务器上的psql ，打开\timing并运行相关的SQL查询。 然后在服务器上再次运行，除了全时间运行psql：
time psql -c "SELECT ..."
我的理解是，前者将testing服务器内部的查询时间，而后者将包括连接开销，以及来回与客户端进行通信。 现在重复testing，但在VPN的另一端运行psql 。
\timing结果有很大的不同吗？ psql结果怎么样？ 这些答案应该有助于确认PostgreSQL中的问题，并且这是由于WAN延迟造成的。
除了可能调整networking连接的其他方式之外，如果情况的严重性值得进一步改进，则可以考虑使用PostgreSQL复制解决scheme，或者考虑客户端的caching备选scheme。
只有在获得大量小型SQL查询报告的情况下，延迟才可能成为问题的原因。 每个查询意味着至less一次往返服务器，并且不能并行运行，至less不能在同一个连接上运行。
另一方面，如果用几个大的SQL查询完成 ，则延迟是不相关的，因为到服务器的往返次数很less。 在这种情况下，速度与下载文件时差别不大，带宽是驱动因素。
要检查运行报表时运行多less个查询，可以在报表中临时设置PostgreSQL中的log_statement="all" 。 请参阅有关log_statement的文档。
或者通过反复查询pg_stat_activity系统视图来实时观察。