exec() 调用的开销?

发布于 2024-10-20 12:29:57 字数 544 浏览 4 评论 0原文

我有一个 Web 脚本,它是 Perl 程序的简单包装器:

#!/bin/sh
source ~/.myinit // pull in some configurations like [PRIVATE_DIR]
exec [PRIVATE_DIR]/myprog.pl

这实际上只是为了更好地划分代码,因为主程序 (myprog.pl) 在具有不同配置模式的不同机器上运行,并且不必这样做更干净为每个安装更新它。然而,我愿意为了效率而牺牲清洁度。

所以问题是,考虑到网络服务器可能会非常频繁地访问它(我们一次有 1000 个用户),这个额外的 sh exec() 调用是否会增加任何不可忽略的开销?我之所以这么问,是因为我知道人们不遗余力地将程序嵌入到 httpd 中以避免进行额外的 fork/exec 调用。我的假设是,这是由于被调用的程序的开销(例如 mod_perl 绕过了极其缓慢的 perl 启动),而不是调用本身的过程。这样说准确吗?

我尝试对此进行基准测试,但无法获得所需的分辨率来查看它是否会产生影响。对此的任何建议也将不胜感激。

谢谢!

I have a web script that is a simple wrapper around a perl program:

#!/bin/sh
source ~/.myinit // pull in some configurations like [PRIVATE_DIR]
exec [PRIVATE_DIR]/myprog.pl

This is really just to keep the code better compartmentalized, since the main program (myprog.pl) runs on different machines with different configuration modes and it's cleaner to not have to update that for every installation. However, I would be willing to sacrifice cleanliness for efficiency.

So the question is, does this extra sh exec() call add any non-negligible overhead, considering it could be hit by the webserver quite frequently (we have 1000s of users on at a time)? I ask, because I know that people have gone to great lengths to embed programs into httpd to avoid having to make an extra fork/exec call. My assumption has been that this was due to the overhead of the program being called (eg mod_perl bypasses the extremely slow perl startup), not the process of calling itself. Would that be accurate?

I've tried to benchmark this but I can't get the resolution I need to see if it makes a difference. Any advice on that would also be appreciated.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

勿忘初心 2024-10-27 12:29:57

尝试测试一下?

假设您有一个与生产分开的测试环境。

(这有点模糊,真正的测试人员将能够详细说明如何改进)

  • 在紧密循环中运行当前的 2 级设计,使用相同的参数运行 100,000 次? 1,000,000? ...

  • 然后“修复”您的代码,以便直接调用 perl,使用与上面相同的参数,循环相同的计数。

  • 捕获两次运行的性能统计数据。两者之间的差异应该(大致)是额外调用的成本。

如果成功,我很高兴看到结果:-)

(标签=测试的帖子比标签=基准的帖子多)

我希望这会有所帮助。

PS,由于您似乎是新用户,如果您得到的答案对您有帮助,请记住将其标记为已接受,或给它一个+(或-)作为有用的答案

Try a test?

Assuming you have a test environmentn separate from production.

(and this is a little vague, and real testers will be able to amplify how to improve on this)

  • Run your current 2 level design in a tight loop, using the same param for 100,000? 1,000,000? ...

  • Then 'fix' your code so the perl is called directly, with the same params as above, looping for same count.

  • Capture performance stats for both runs. The diff between the two should be (roughly) the cost of the extra call.

If this works out, I'd appreciate seeing the results on this:-)

(There are many more posts for tag=testing than tag=benchmark)

I hope this helps.

P.S. as you appear to be a new user, if you get an answer that helps you please remember to mark it as accepted, or give it a + (or -) as a useful answer

妳是的陽光 2024-10-27 12:29:57

Perl 程序很容易从 shell 脚本接管一些环境变量,请参阅 让 perl 执行 shellscript & 的答案接管环境变量
使用此功能根本不需要 exec,这应该减轻您对 exec 开销的所有担忧。 :-)

It's easy for a perl program to take over some envars from a shell script, see the answer to Have perl execute shellscript & take over env vars.
Using this there is no need for exec at all which should alleviate all your worries about exec overhead. :-)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文