工作中使用到apache的ftpserver,一直以为基于mina的它是异步非阻塞IO的,结果看了源码
发现,接收是这么写的
真是太失望了,这样一来,ftpserver处理客户请求的数据就取决于那个ExectorFilter中的线程池大小了,ftpserver用的是OrderExectorFilter的无参构造函数,默认池的最大值是16了。要是同时接收16个大文件的话,就没有能力处理新请求了,注意NioListener还是能够处理监听的,因为它跟ioserver用的不是一个线程池(我猜的)。只是socket连上后,就处在持续等待的状态,任你新来的ftp command是啥,都不处理。直到有一个大文件传输完成,腾出一个可用线程。
我觉得要整个基于mina的应用出来,怎么着您也得使用一下这个框架的特性,啥异步io呀,高性能呀,结果搞出这么个东东。当然apache还是NB的,我自己做不出来,只能用人家的,发发牢骚罢了,各位尽量拍,哈哈。
发现,接收是这么写的
while (true) {
从流中读
写文件
}
}}真是太失望了,这样一来,ftpserver处理客户请求的数据就取决于那个ExectorFilter中的线程池大小了,ftpserver用的是OrderExectorFilter的无参构造函数,默认池的最大值是16了。要是同时接收16个大文件的话,就没有能力处理新请求了,注意NioListener还是能够处理监听的,因为它跟ioserver用的不是一个线程池(我猜的)。只是socket连上后,就处在持续等待的状态,任你新来的ftp command是啥,都不处理。直到有一个大文件传输完成,腾出一个可用线程。
我觉得要整个基于mina的应用出来,怎么着您也得使用一下这个框架的特性,啥异步io呀,高性能呀,结果搞出这么个东东。当然apache还是NB的,我自己做不出来,只能用人家的,发发牢骚罢了,各位尽量拍,哈哈。
Apache FTPServer 异步 IO 实现与性能问题探讨
本文深入分析了 Apache FTPServer 使用 Mina 框架实现 FTP 服务时,关于异步非阻塞 I/O 的误解与实际表现之间的差异。讨论了在接收文件操作中,FTPServer 处理并发请求的能力受限于线程池大小的问题,以及这一设计对性能的影响。文章还提到,尽管 Apache FTPServer 在底层提供了强大的功能,但正确的配置与理解其内部机制对于实现高效、稳定的文件传输服务至关重要。

468

被折叠的 条评论
为什么被折叠?



