公司项目服务端是PHP，因为有个接口特别耗时（合并文件），我App请求总是超时，让负责服务端的同事改成异步处理，同事看起来挺为难的。
1 个赞
耗时的处理放到队列里 由其他程序处理 或者起协程
你说的这个异步跟多线程有关系吗
能开多线程吗？此时一位PHP仔面露难色 
可以试试把这部分代码改成Java或者python试试先
Java仔喜笑颜开，并提供MQ队列入和回调API出
这个耗时跟异步没关系我觉得，app等着结果呢。
补充下，App不需要等这个结果。
描述不严谨，图一乐吧
那就异步呗
试下 Swoole？
直接做成异步的，另起脚本处理合并。
简单点异步也不需要。你接口直接插表，然后脚本查表合并，并更新这条记录的状态。 脚本可以用supervisor做成守护进程。
你一定要多线程，试下swoole，workman之类的。比较好的选择是golang.
再多嘴一句：这个磁盘IO这么大的，真的不考虑脚本处理吗？
APP不需要等结果，那你管他超不超时的，确认下程序结果是不是预期的不就好了。超时可能是web服务器超时，或者php执行超时，也可能是你这边设置的超时时间太短。在你不需要等结果的情况下，只有php执行超时才是需要关注的。
swoole，workman也用不了多线程。
我觉得需要确认下合并文件这个耗时到底是不是php的性能问题。
1 个赞
我觉得问题的关键不在能不能异步，这种操作应该让开发人员自己决定。你只管说你需要什么结果就行，怎么实现你就别操心了吧。
文件分片上传之后，有个合并的操作，只是常规的耗时操作，不是性能问题。
我也不想干预，只是问题几天没处理了，上头催
这不是异步操作吗, 原生PHP貌似不支持多线程
性能问题看你怎么理解：
- 单纯从编程语言方面来说： PHP是 解释型语言，没有编译器，你每次请求都会把用到的文件加载到内存，然后逐行解析执行。相对其他语言编译成可执行文件，确实是性能不太好。
- 如果从“慢”方面来说，个人认为并不是。毕竟IO在那里，并且如果你用的库/代码写的不够好的话，确实会占用很大量的内存，但这不是php性能的问题。
这只能用异步任务了 即使是单个任务里面多线程目前也只有swoole可以一战