You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/06/17 19:47:43 UTC
DO NOT REPLY [Bug 17762] -
JNI problems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=17762>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17762
ken@kensystem.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ken@kensystem.com
------- Additional Comments From ken@kensystem.com 2005-06-17 19:47 -------
(In reply to comment #8)
> I think people should just avoid JNI for now. It doesn't give any performance
> boost anyway.
Huhh?!? Sorry, I just have to comment..
Please compare the performance (should I say penalty) of *not* using JNI... The
last time I tested (and also just now), shoveling long byte streams through
ServletResponse.getOutputStream() __completely___ brings the native apache
server to a grinding hault (full CPU usage, e.g. D-O-S). My test on a 2GHZ box
of a file download via FileInputStream -> getOutputStream() (4096 buffer)
*pinned* the CPU (the Apache process, specifically), yet could only sustain a
mere 1-2 MBytes/second.
When I compared jni performance a year or two ago (when I could get it to work),
this performance hit was marginal or negligible as I recall. And other JNI based
servers (right now) also have no such performace hit.
I concede that this isn't neccsarily the socket channels architecture's fault
(perhaps it just need to be buffered/optimized on the mod_jk side?), but still...
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org