Python脚本作为后台进程执行
我正在编写一个 python 脚本来充当应用程序和一些外部设备之间的“粘合剂”。该脚本本身非常简单，具有三个不同的过程：
- 请求数据（通过 UDP，从套接字连接）
- 接收响应（通过 UDP，从套接字连接） 处理
- 响应并将数据提供给第 3 方应用程序
但是，这将是对于多个（+/-200 种不同的）设备重复完成。因此，一旦到达设备#200，它将再次开始从设备#001请求数据。我在这里主要关心的是在执行脚本时不要让处理器陷入困境。
更新： 我使用三个线程来执行上述操作，每个线程对应上述每个进程。请求/响应是异步的，因为每个响应都包含我需要能够处理它的所有内容（包括发件人详细信息）。
有没有办法让脚本在后台运行并在执行任务时消耗尽可能少的系统资源？这将在 Windows 2003 机器上运行。
任何建议将不胜感激。
Im in the process of writing a python script to act as a "glue" between an application and some external devices. The script itself is quite straight forward and has three distinct processes:
- Request data (from a socket connection, via UDP)
- Receive response (from a socket connection, via UDP)
- Process response and make data available to 3rd party application
However, this will be done repetitively, and for several (+/-200 different) devices. So once its reached device #200, it would start requesting data from device #001 again. My main concern here is not to bog down the processor whilst executing the script.
UPDATE:
I am using three threads to do the above, one thread for each of the above processes. The request/response is asynchronous as each response contains everything i need to be able to process it (including the senders details).
Is there any way to allow the script to run in the background and consume as little system resources as possible while doing its thing? This will be running on a windows 2003 machine.
Any advice would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您对设备使用阻塞 I/O，则脚本在等待数据时不会消耗任何处理器。您使用多少处理器取决于您对数据进行何种类型的计算。
If you are using blocking I/O to your devices, then the script won't consume any processor while waiting for the data. How much processor you use depends on what sorts of computation you are doing with the data.
Twisted - Python 的最佳异步框架 - 将允许您以最少的占用来执行这些任务系统资源，尤其是如果您想“一次”处理多个设备，而不是仅仅在数百个设备之间进行循环处理（后者可能会导致周期时间过长，特别是如果存在某些设备将应答非常延迟，甚至偶尔无法应答并导致“超时”，根据经验，我建议在任何给定时间至少有半打设备“正在运行”，以避免这种过度情况-延误风险）。
Twisted -- the best async framework for Python -- would allow you do perform these tasks with the minimal hogging of system resources, most especially though not exclusively if you want to process several devices "at once" rather than just round-robin among the several hundreds (the latter might result in too long a cycle time, especially if there's a risk that some device will have very delayed answer or even fail to answer once in a while and result in a "timeout"; as a rule of thumb I'd suggest having at least half a dozens devices "in play" at any given time to avoid this excessive-delay risk).