从我一开始工作时，每次在linux下启动weblogic总会发现有这样一句日志：
<Unable to load performance pack. Using Java I/O instead. Please ensure that libmuxer library is in :……
一直都没太在意，以为所谓的“performance pack”只是weblogic的一个“增强组件”一样。直到最近在对新到的一批机器做压力测试的时候才发现了问题。
场景是这样：
3台Dell 的R900型号服务器，4 x?Xeon E7430,32G内存，装64位jdk 1.5.0_22和weblogic 9 MP 4，weblogic的JVM分配8G内存。在LoadRunner加到每台机器67并发的时候，整个系统响应奇慢无比，平均响应时间达到了17s左右， 但是server的load值并不高，并且weblogic后端提供其他服务的server则很闲。这是无法忍受的性能问题。用visual vm连上去一看，发现有大量的线程处于等待状态，也就是说，weblogic自己忙不过来了。
事后仔细想了一下，难道真的跟传说中的“performance pack”加载失败，导致weblogic使用java io进行通信致使性能严重下降？在网上google了一番，还真是这样子，据说最严重能导致30%左右的性能下降（Refer1 Refer2 ）。知道了问题原因，就能迎刃而解了。
首先根据网上的一些资料，看了一下weblogic安装目录下weblogic92/server/native/linux目录里Native IO所依赖的libmuxer.so，发现该目录下有一个i686的子目录。这是很不正常的现象，因为我使用的是64位jdk，按理说应该是一个类似 x86_64这样的目录才对。
于是乎重装了一下weblogic，重建了域，发现问题依旧。于是又去Oracle的网站看了一下，在weblogic下载页面读到这样一段话：
To use WebLogic Server with 64-bit JVM’s on Linux and Solaris or to use WLS on other supported
platforms, use the WebLogic Server generic installer listed under “Additional Platforms”.
再看看自己的安装介质，文件名赫然是server924_linux32.bin。怪不得，我一开始用的介质都不对。重新下载了 server924_generic.jar（题外话：weblogic 9.x版本的generic.jar在oracle官方下载页面已经无法下载。咨询了一下Oracle的人，得知可以在此处 下载），然后按照说明使用命令
java -Xmx1024m -d64 -jar server924_generic.jar
进行安装。安装完成后，再看${WL_HOME}/weblogic92/server/native/linux路径下，已经是x86_64目录 了:)。然后给目录里的各个文件添加了可执行权限，创建了新的域。然后再启动weblogic，发现还是报“Unable to load performance pack”。我彻底郁闷了。
又想了一下，既然native io相关的文件都已经正确了，还无法正确加载，会不会是某个环境变量影响了weblogic去正确的目录内寻找文件导致的呢？
打开了跟创建域有关的脚本看了看，发现创建域的时候会依赖一个叫做LD_LIBRARY_PATH的变量。而该变量恰恰在我们的场景里用来指向一个 应用需要JNI调用的so文件路径。看来就是因为LD_LIBRARY_PATH被“污染”，导致了weblogic无法正确加载native io library了。直接把项目需要的so文件放到了${JAVA_HOME}/jre/lib/amd64/下，去掉了用环境变量声明的形式，然后再启动 weblogic，没再出现“Unable to load performance pack”，说明Native IO加载成功了:)
然后又对weblogic进行了一些相关的优化，比如jvm参数的调整等等。再进行压力测试时，平均响应时间已经降到了1.9s左右，性能提高了 10倍左右，相当不错了。1.9秒虽然还没有达到最理想的响应时间，但是通过进一步调整jvm参数，并结合优化代码，肯定还会有更好的表现。