-
1. Re: Message Selector Performance in Persistent P2P Queue DB
genman Jan 3, 2004 3:36 PM (in response to jason.greene)In JBoss 3.2/3.0, every message that exists on disk has a so-called memory reference as well. This reference holds a subset of the fields, such as priority, message ID, expiration time, etc. Meaning, if you have 1,000,000 messages in some queue, JBoss holds on to 1,000,000 references in memory.
Thus, there is little point (with this model) to index anything on the DB, since the data isn't accessed in any special order.
Note that also in JBoss, messages with higher priority are always ordered before those of lower -- regardless of their age. If you do use a message selector, JBoss will do a full scan of the queue, but it's quite fast (even for 1,000,000 records) since it is done quickly in memory. (There are probably room for futher optimizations, as I expect there are corner cases that do badly.)
Anyway, there is little to gain by breaking up properties into their own columns, unless you need to use this data from a separate SQL query. -
2. Re: Message Selector Performance in Persistent P2P Queue DB
jason.greene Jan 6, 2004 10:10 AM (in response to jason.greene)"genman" wrote:
If you do use a message selector, JBoss will do a full scan of the queue, but it's quite fast (even for 1,000,000 records) since it is done quickly in memory. (There are probably room for futher optimizations, as I expect there are corner cases that do badly.)
I took a look at the source and it appears that this is not the case. While the fields you mentioned are cached, they are not used for the actual selector. When a P2P queue receive operation is invoked, the queue is scanned linearly and a selector is ran against the message headers.MessageReference m = (MessageReference) i.next(); if (s.test(m.getHeaders())) selection.add(m.getMessage());
This getHeaders() call not only loads the full headers, but also loads the entire message.
It appears the problem is acknowleged in the source:/** * We could optimize caching by keeping the headers but not the body. * The server will uses the headers more often than the body and the * headers take up much message memory than the body * * For now just return the message. */ public SpyMessage.Header getHeaders() throws JMSException { return getMessage().header; }
This means that unless the message cache is large enough to hold the entire table, a selector will always perform a massive scan and deserialization of the queue."genman" wrote:
Anyway, there is little to gain by breaking up properties to their own columns, unless you need to use this data from a separate SQL query.
It appears that a message header cache would be a simpler solution to implement, and will most likely bring a comparable performance increase. However, with this solution, header data and body data may need to be stored separately to save deserialization costs. Also, there is still an upper limit which is tied to the available memory in the system.
Separate queues seems to be the only way to go at this time.
Jason -
3. Re: Message Selector Performance in Persistent P2P Queue DB
jason.greene Jan 6, 2004 10:13 AM (in response to jason.greene)Sorry I forgot to enable BBCode in the last post....
Take 2:"genman" wrote:
If you do use a message selector, JBoss will do a full scan of the queue, but it's quite fast (even for 1,000,000 records) since it is done quickly in memory. (There are probably room for futher optimizations, as I expect there are corner cases that do badly.)
I took a look at the source and it appears that this is not the case. While the fields you mentioned are cached, they are not used for the actual selector. When a P2P queue receive operation is invoked, the queue is scanned linearly and a selector is ran against the message headers.MessageReference m = (MessageReference) i.next(); if (s.test(m.getHeaders())) selection.add(m.getMessage());
This getHeaders() call not only loads the full headers, but also loads the entire message.
It appears the problem is acknowleged in the source:/** * We could optimize caching by keeping the headers but not the body. * The server will uses the headers more often than the body and the * headers take up much message memory than the body * * For now just return the message. */ public SpyMessage.Header getHeaders() throws JMSException { return getMessage().header; }
This means that unless the message cache is large enough to hold the entire table, a selector will always perform a massive scan and deserialization of the queue."genman" wrote:
Anyway, there is little to gain by breaking up properties to their own columns, unless you need to use this data from a separate SQL query.
It appears that a message header cache would be a simpler solution to implement, and will most likely bring a comparable performance increase. However, with this solution, header data and body data may need to be stored separately to save deserialization costs. Also, there is still an upper limit which is tied to the available memory in the system.
Separate queues seems to be the only way to go at this time.
Jason -
4. Re: Message Selector Performance in Persistent P2P Queue DB
genman Jan 6, 2004 3:52 PM (in response to jason.greene)
You're right, it does have to fetch the entire message from DB to check the headers.
Optimimally, what it should do is be able to page out the message body and message headers to DB as separate columns. And then you would create a separate datastructure that gets persisted to a different database column and you would have to modify the persistence manager to fetch those parts separately.
Less optiminally would be to always store the message headers as part of the message reference. This would be a lot less coding and a lot less work, I think. The downside is that adding the message headers might take up quite a bit of memory, especially if the properties were quite large. It might be a good idea to have a configuration setting for this feature.
If you're willing to contribute code, I'm sure it would be most welcome. -
5. Re: Message Selector Performance in Persistent P2P Queue DB
jason.greene Jan 6, 2004 6:09 PM (in response to jason.greene)Sure I'll work on a prototype and contact the lead author of this component. It shouldn't take too long to develop.
Jason