Name: skT45625 Date: 04/25/2000
java version "1.2.1"
Classic VM (build JDK-1.2.1-003, green threads, sunwjit)
When using java sockts with the DataOutputStream class, load seems to DESTROY
performance. After several thousand data requests (of a custom protocol),
reading header / any information form a "new DataInputStream(s.getInputStream)"
becomes very slow. After adding profiling information, operations such as
readInt() are taking upwards of 300 milliseconds. The performance is good
initially, but after a short while (over the same socket) performance suffers.
the method readFully() seems to take less time than readInt under certain
circumstances, but both operations are unacceptably slow. A standard header
request can take over second in the following form:
public void init(Socket s) throws BrokerExc, IOException
{
if (s == null) {
System.err.println("Input socket null, Header not initialized.");
throw new BrokerExc("Input socket null, Header not initialized.");
}
m_sConnection = s;
DataInputStream dis = new
DataInputStream(m_sConnection.getInputStream());
int iVersion = dis.readInt();
if (iVersion != VERSION) {
System.err.println("Specified version does not match expected value:
" + iVersion + " / " + VERSION);
m_bInitialized = false;
throw new BrokerExc("Specified version does not match expected
value: " + iVersion + " / " + VERSION);
}
m_iHeaderLength = dis.readInt();
m_iMachineNameLength = dis.readInt();
m_iMessageNameLength = dis.readInt();
m_iDataLength = dis.readInt();
byte[] bMachineName = new byte[m_iMachineNameLength];
dis.readFully(bMachineName);
m_sMachineName = new String(bMachineName);
byte[] bMessageName = new byte[m_iMessageNameLength];
dis.readFully(bMessageName);
m_sMessageName = new String(bMessageName);
System.out.println("Consuming: " + consumePadding());
m_bInitialized = true;
System.out.println("Header was [VERSION, TotalLen, MachineLen, MessageLen,
DataLen]: [" + iVersion + ", " + m_iHeaderLength + ", " + m
_iMachineNameLength + ", " + m_iMessageNameLength + ", " + m_iDataLength + "]");
}
Is there any known workaround for the poor perfromance of this stream?
Our protocol is designed to be a lightweight message / data transfer protocol,
and to handle a huge amount of traffic, we expect a peak load of over a megabit
once we go live with this, and this issue constitutes an absolute roadblock.
(Review ID: 104099)
======================================================================