问题标签 [starman]

我有自己的书面中间件，称为身份验证和会话，其中身份验证中间件生成会话密钥并在成功身份验证后将会话信息保存在 cookie 中。

现在使用上面的 cookie 会话中间件提取会话信息并实现会话管理。

但不知何故，我无法序列化上述中间件，这样我就可以在 Session 中间件中获取 Authentication 中间件创建的 cookie。

我试图构建它们如下 -

身份验证中间件简单地将用户验证到某个数据库，并在成功时生成会话密钥并将其保存在 cookie 中。

会话中间件看起来像 -

我调用中间件有什么问题吗？

我有很多基于框架的CGIweb 应用程序apache2，它们具有复杂的驱动接口和相应的 perl 后端。jQueryUICGI::Application

对于用户来说，它看起来像这样：

1. //localsrv.lan/some_report_xls
2. //localsrv.lan/some_insert_db
3. //localsrv.lan/some_perl_plsql_stuff 等...

现在我想打开那些应用程序psgi，这很容易，并以某种方式运行它们Apache->ProxyPass/Starman

• 我应该为每个应用程序运行 Starman，并为所有应用程序使用大量端口吗？
• 我应该以某种方式使用映射 urlPlack::App::URLMap以及如何使用？
• 我是否应该从数百个应用程序中创建一个应用程序来使用 Starman 运行它
• 还有另一种方法吗？

我对分叉后每个孩子的构造函数有疑问。例如：

此代码有效，但这是不好的做法。我想创造类似的东西

我希望有人向我解释它如何通过像 Starman 或 Feersum 这样的 prefork-server 工作（但是一个人“Audrey Tang”告诉我 Feersum 这不是一个好主意）

所以 - 谢谢你的回答

我正在运行一个以 Starman (v0.4014) 和 ngynx 作为前端代理的 Dancer (v1.3202) 应用程序。我注意到负载均衡器每隔几个小时就会出现一个巨大的延迟峰值，我想知道是否是工作人员达到了他们的请求限制并重新启动。延迟从平均 30 毫秒到 1000 毫秒或更多。我检查了 MongoDB，没有长时间运行的查询。--max-requests 实际上对工人做了什么，当工人达到这个限制时会发生什么？

在启用 SSL 之前，我的设置运行良好。

这个

工作正常，但这：

不 - 生成此错误：

在每一个请求。

在 AWS 的 Ubuntu 16.04.2 LTS 上运行 perl 5，版本 22，subversion 1

端口似乎转发正常：

嗨stackoverflow用户，

我正在使用： - Perl - Dancer - Starman - Camelcade - Intellij

我用 Web 应用程序构建了一个容器。我配置了 Camelcade 所需的环境变量。当我运行调试时：

• perl -d:Camelcadedb web.pl

它只调试启动 perl 文件，该文件调用 Dancer，然后在 Dancer 和 Starman 运行时完成，但并非所有 Web 应用程序都处于调试模式，因为当我调用某个端点时它不是调试。我的想法是当我调用 URL 并且它有一个断点时，它就停在那里。有人可以给出一个想法，这是怎么回事？

我提出的这个问题促使我探索将我的 FastCGI 脚本直接连接到 NGINX，而不是使用 Apache 的反向代理。我使用我在网上找到的一些代码成功地修改了我的 FastCGI 脚本以作为守护进程运行：

它可以工作，但据我所知，这与 mod_fcgid 相比有一个明显的缺点：我有一个正在运行的进程，它一次处理一个请求，如果该进程终止，则没有任何东西可以启动它。在 Stack Overflow 上引用了正确剥离工作人员的代码，但所引用的网站不可避免地似乎已经离线，就像 FastCGI 自己的网站一样。

所以，我试图弄清楚我需要添加什么，并且——请原谅双关语——弄清楚我是否需​​要在这条路上分叉。如果我正确理解我的问题，以下是我正在尝试考虑的选项：

1. 直接实现某种分叉机制，理想情况下，它似乎应该（1）将请求扔给一个进程/线程/工作者——也许一个可以为多个请求保持活动状态——并继续为下一个请求做好准备请求和（2）足够独立于工人，如果工人出了问题，它不会关闭整个系统，直到我抓住它并重新启动主进程（例如自动重启进程）。如果这可以简单可靠地完成，这似乎具有巨大的吸引力，因为代码已经与 FastCGI 一起使用。

2. 放弃直接 FastCGI 并转换为 PSGI 并使用应用程序服务器来处理这些事情。鉴于我正在使用 Perl，我猜 Starman 是合乎逻辑的选择，尽管我一直在阅读 uwsgi 的 PSGI 支持，它在“暴君皇帝”模式下听起来几乎是理想的，它可以运行具有不同权限的进程，自动重新启动丢失的进程等

选项 1 看起来很有趣，因为它需要对我现有的代码进行最少的修改，而且在没有 FastCGI 的情况下启动的 FastCGI 脚本仍然像普通的 CGI 脚本一样工作。（当流量非常低的网站使用此代码时，我不会在 FastCGI 下运行此代码）。

不过，选项 2 感觉它可能更“现代”。例如，至少 PSGI 文档似乎仍然在线，并且使用 Starman 或 uwsgi 似乎他们可以处理我需要的背景内容，这可能比我自己编写系统更好。缺点：我的代码需要两个启动脚本：一个供启用 PSGI 的站点使用，另一个用于仍在 CGI 中运行的站点。

更新：继续探索选项 1，我通读了这个关于 Perl 的教程，fork()这似乎有点相关。如果我选择选项 1，使用fork中断每个 FastCGI 请求是一个好方法吗？我认为我将面临分叉爆炸的风险，尽管如果我跟踪分叉的数量并发布wait() if ($forks > 10);，也许这将是一种安全的方法？（或者也许Parallel::ForkManager用来监视该过程。）或者使用类似的东西Thread::Queue并将FastCGI请求对象传递给已经可靠建立的线程集会更安全和/或更有效吗？似乎有很多我可能会忽略的陷阱，然后让我回到是否应该选择选项 2。