在同一个 Web 应用程序中运行 Sentry 客户端和服务器会如何影响性能？
我正在考虑为我的 Django 项目设置 Sentry，但我想知道是否将 Sentry 服务器与我的主 Web 应用程序一起安装，还是安装在单独的 Web 实例中。
我能想到的在同一个 Web 应用程序中使用 Sentry 的好处是：
- 易于设置和维护（一个 Web 应用程序而不是两个，并且不需要安装 eventlet 等）
- 易于管理员使用（例如，使用与 webapp 管理员相同的帐户）
Sentry 文档建议此处 和此处运行它同一个 webapp 会降低 webapp 的服务质量，但是具体是如何降低的呢？
- 当没有错误发生时，Sentry 会减慢 Web 应用程序的速度吗？
- 如果发生很多错误（例如每分钟 10 个），Web 应用程序是否会变得非常慢？
I'm looking into setting up Sentry for my Django project, but I was wondering whether to install the Sentry server along with my main webapp, or in a separate web instance.
The benefits I can think of for having Sentry in the same webapp would be:
- Ease of setup and maintenance (one webapp instead of two, and not needing to install eventlet, etc.)
- Ease of use for admins (e.g. logging into Sentry with the same accounts as the webapp admin)
The Sentry docs suggest here and here that running it in the same webapp will bring down the webapp quality of service, but how, specifically?
- Could Sentry slow the webapp down when no errors are occurring?
- Could the webapp become extremely slow if many errors are occurring (say, 10 per minute)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非发生错误，Sentry 不会执行任何操作，即使发生错误，对响应时间的影响也可以忽略不计——嗯，至少与系统上任何其他类型的日志记录一样可以忽略不计。不过，一般来说，这不会对您的应用程序产生影响。
文档提到的集成 Sentry 会出现问题的场景是在高并发环境中以及必须提供 QoS（服务质量）的环境中。让我更详细地讨论一下这些内容。
第一，高并发。在这里，您的网站获得了如此多的流量，以至于 1) 您必须将服务器剥离到只剩下骨头才能处理请求（例如 Twitter 或 Facebook），或者 2) 负载足以使您的服务器崩溃（尽管是 Digg 效应）现在可能需要重命名），在这种情况下，您也将失去 Sentry 访问权限。
其次，QoS影响。在服务器上混合应用程序意味着更多的故障点。如果您的 Django 项目中存在错误，它可能会导致 Sentry 崩溃，从而使诊断变得更加困难。或者相反，如果 Sentry 中出现问题，您的 Django 项目可能会随之崩溃，从而导致潜在的访客、销售、广告收入等损失。
问题实际上不在于性能（尽管这很重要），这实际上是关于职责分离和减少故障点。如果您正在运行一个小型网站，那么您可能不会太关心这一点。但是，对于像 Disqus（Sentry 的开发者）这样的网站来说，隔离的 Sentry 服务器是必要的。
Sentry doesn't do anything unless an error occurs, and even then, the impact on response time is negligible -- well, at least as negligible as any other type of logging on the system. In general, though, this is not going to have an effect on your app.
The scenarios the docs refer to where integrated Sentry would be a problem are in high-concurrency environments and those where QoS (quality of service) is a must. Let me go into those in a bit more detail.
First, high-concurrency. Here, your website is getting so much traffic that 1) you must strip the server to bare bones just to handle requests (think Twitter or Facebook) or 2) the load is sufficient to bring your server to its knees (Digg-effect, though that probably needs to be renamed now), in which case you'll lose Sentry access as well.
Second, QoS impact. Mixing apps on a server means more points of failure. If there's a bug in your Django project, it can potentially take down Sentry with it, making it much more difficult to diagnose. Or conversely, if something blows up in Sentry, it might take your Django project down with it, resulting in potential lost visitors, sales, ad-revenue, etc.
The issue really isn't so much performance (although that is important), it's really about separation of duties and reducing points of failure. If you're running a small site, that's probably not of much concern to you. But, for sites like Disqus (who make Sentry), a segregated Sentry server is a necessity.