Question

我一直在和PrintServiceLookup作战; lookupPrintServices(DocFlavor flavor, AttributeSet attributes)方法在初始导入时检测应用程序中的打印机速度太慢。拥有100多台网络打印机的客户端报告说，执行此代码的行为在第一次运行时性能很差。

在看到查找结果被缓存后，我最初在一个单独的线程中部署了一个虚拟查找（在启动时执行）。但是，对于特定客户端，此解决方案不起作用。

我目前没有他们的环境，也看不出导致确切性能问题的原因。

我正在尝试查看PrintService是否支持给定的MediaSizeName ，而执行DocFlavor和AttributeSet的查找。因此，我提取所有可用的PrintService和默认的PrintService：

private static final PrintService[] PRINTSERVICES = 
   PrintServiceLookup.lookupPrintServices(null, null);

private static final PrintService DEFAULTSERVICE = 
   PrintServiceLookup.lookupDefaultPrintService();

然后，从客户端请求中获取PrintService和MediaSizeName。最后，我问PrintService是否支持MediaSizeName：

private void checkPrintServiceForMediaSize(PrintService pservice) throws MediaSizeNotSupportedException{
     if(!pservice.isAttributeValueSupported(_mediaSizeName,null,null))
            throw new MediaSizeNotSupportedException("This media size is not supported by the selected printer.");
     }

API声明在使用null isAttributeValueSupported(Attribute attrval,DocFlavor flavor,AttributeSet attributes)和DocFlavor

调用AttributeSet时

此方法告知此Print Service是否支持给定的打印属性值以获取doc flavor和属性集的某种可能组合

并且到目前为止表现正常。但是，如果打印机支持所选页面大小，我不完全确定这是否是执行方式。

感谢您就此问题提供反馈和经验。

更新

在我实施我的方法的时候，我的工作站决定遇到严重的网络问题，这花了我一段时间才弄明白。最后，我的实现已经使用网络工具SoftPerfect Connection Emulator进行了测试（以模拟网络负载），结果没有显着改善。

我将继续测试并更新此问题。希望我能找到解决方案并在这里与人们分享。我猜的是初始查找：

private static final PrintService[] PRINTSERVICES = 
   PrintServiceLookup.lookupPrintServices(null, null);

仍然会导致问题。

更新2

beta版本最终在客户端环境中进行了测试，打印对话框的性能提高了约5倍（在相同的环境下，打印机的初始拉动现在大约需要1分钟，而大约5分钟）。最初的等待时间仍然不是可接受的时间，但是，我现在能做的最好。我们还从客户那里听说正在使用打印服务器并遵循评论中的建议（@Wardy），我将继续朝着这个方向前进。希望我们可以利用打印服务器的优势。

Answer 1

更积极的缓存。让客户端执行一次查找并在重新启动之间保持缓存。更好的是，将缓存保存到可供所有客户端访问的中央数据存储。

我假设网络打印机及其功能经常不会改变，但你必须最终更新缓存，但是＆＃34;谁＆＃34;和＃34;当＆＃34;取决于您的环境。

可以在后台运行当前发现的客户端对缓存进行更新，如果检测到更改，则更新缓存。如果你有一个连续运行的中央组件，这将是一个你可以检查固定间隔的好地方。

如果您有某种目录服务，可以在联系每台打印机之前将其打印机列表与您的缓存进行比较，以获得降低网络和CPU负载的能力。

Answer 2

如果打印机列表存储在LDAP中，您可以尝试使用LDAP查找打印机。

确定打印机是否可以在没有查找的情况下处理打印作业

2 个答案: