You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Ryan McKinley <ry...@squid-labs.com> on 2007/06/29 23:47:59 UTC
stax vs xpp XmlUpdateHandler
I just did some performance testing to compare the stax vs xpp
implementaion. As far as I can tell there is no real difference between
them.
Using solrj, this adds 10000 documents for each handler - running each
as an independent call.
STAX: 8631 8221 8525 8383 8487 = 42247
XPP: 8309 8438 8261 8794 8237 = 42039
How do you all feel about moving:
XmlUpdateRequestHandler -> XppUpdateRequestHandler
StaxUpdateRequestHandler -> XmlUpdateRequestHandler
then deprecating XppUpdateRequestHandler? This will urge people to use
the Stax implemenation sooner then later and should help iron out any
problems sooner then later.
thoughts?
Here is the actual test code:
public long makeRequests( String path, int cnt ) throws Exception
{
server.deleteByQuery( "*:*" );
server.optimize();
long now = System.currentTimeMillis();
UpdateRequest req = new UpdateRequest();
req.setPath( path );
for( int i=0; i<cnt; i++ ) {
SolrInputDocument doc = new SolrInputDocument();
doc.addField( "id", i+"" );
doc.addField( "name", "hello" );
for( int x=5; x<5; x++ ) {
doc.addField( "feature", "feature:"+x );
}
req.add( doc );
server.request( req );
req.clear();
}
server.commit();
long elapsed = System.currentTimeMillis() - now;
QueryResponse response = server.query( new SolrQuery( "*:*" ) );
if( cnt != response.getResults().getNumFound() ) {
throw new Exception( "did not add everything!" );
}
return elapsed;
}
Re: stax vs xpp XmlUpdateHandler
Posted by Yonik Seeley <yo...@apache.org>.
On 6/29/07, Ryan McKinley <ry...@gmail.com> wrote:
> > so we should test that use case (ie: <add> containing 10000 small
> > documents;
>
> For processing a single request with 10000 documents, the existing XPP
> update handler is faster then the new StaxUpdateHandler.
>
> XPP: 6888 6714
> STAX: 8665 8313
Have you tried Woodstox to see how it compares?
If you do more testing, in addition to Hoss' recommendations, I'd also
remove the unused elements (copyFields, dynamicFields) from the schema
(as well as testing w/o logging).
-Yonik
Re: stax vs xpp XmlUpdateHandler
Posted by Yonik Seeley <yo...@apache.org>.
On 6/29/07, Ryan McKinley <ry...@gmail.com> wrote:
> If I remove logging, the same test runs in:
>
> STAX: 6783 6834
>
> essentially equivalent to the XPP version
What about if you remove the logging for the XPP version too?
-Yonik
Re: stax vs xpp XmlUpdateHandler
Posted by Ryan McKinley <ry...@gmail.com>.
> so we should test that use case (ie: <add> containing 10000 small
> documents;
For processing a single request with 10000 documents, the existing XPP
update handler is faster then the new StaxUpdateHandler.
XPP: 6888 6714
STAX: 8665 8313
I looked into it, and the difference seems to be entirely in the logging
strategy. the XPP handler prints out a single line for all 10K docs:
INFO: added id={0,1,2,3,4,5,6,7,8,9,10,11,12,13,1...
the STAX one sends each document to the processor that logs the add
individually:
INFO: added id={0} in 28ms [29]
INFO: added id={1} in 3ms [33]
INFO: added id={2} in 1ms [35]
...
If I remove logging, the same test runs in:
STAX: 6783 6834
essentially equivalent to the XPP version
ryan
Re: stax vs xpp XmlUpdateHandler
Posted by Ryan McKinley <ry...@gmail.com>.
>
> I'm kinda out of the looop on the whole Stax/Xpp/Xml update parsing stuff
> ... am i remembering correctly the end game goal is to reduce/eliminate
> dependencies on XPP? (because .... ? .... stax is Java "standard"
> included out-of-the-box with java6? (i'm guessing))
>
For me the biggest reason is to de-couple the parsing from the actual
update processing. I need to do custom processing in between
(SOLR-269). Stax is a growing standard, so it seems like the right
choice if we are reworking document parsing. (depending on your
preference) It is a bit easier to work with and more readable.
With the parsing separated from indexing, it would be straightforward to
have a single UpdateRequestHandler that could read the content type and
pick how to parse the documents - using the same indexing
strategies/format/processor etc.
>
> A lot of people seem to be sending multiple documents at a time as well,
> so we should test that use case (ie: <add> containing 10000 small
> documents; <add> containg 100 medium documents; <add> containing 1 big
> document)
>
that makes sense. I don't claim the tests I ran are representative - i
just wanted to make sure the overall speeds are within the same ballpark.
this one sends 10000 docs together (with 10 text fields), then 10000
docs individually each with 100 text fields. Still not the most
scientific, but here it is:
STAX: 57642
XPP: 58012
@Override public void setUp() throws Exception
{
super.setUp();
// setup the server...
server = new EmbeddedSolrServer( SolrCore.getSolrCore() );
}
public SolrInputDocument createDocument( int id, int fcnt )
{
SolrInputDocument doc = new SolrInputDocument();
doc.addField( "id", id+"" );
doc.addField( "name", "hello" );
for( int x=5; x<fcnt; x++ ) {
doc.addField( "text", "this is just some & text with <> asgasdg;
"+x );
}
return doc;
}
public long makeRequests( String path, int cnt ) throws Exception
{
server.deleteByQuery( "*:*" );// delete everything!
server.optimize();
long now = System.currentTimeMillis();
UpdateRequest req = new UpdateRequest();
req.setPath( path );
// Send all the docs together
for( int i=0; i<cnt; i++ ) {
req.add( createDocument( i , 10 ) );
}
server.request( req );
req.clear();
// Send them one at a time
for( int i=0; i<cnt; i++ ) {
req.add( createDocument( i+cnt, 100 ) );
server.request( req );
req.clear();
}
server.commit();
long elapsed = System.currentTimeMillis() - now;
QueryResponse response = server.query( new SolrQuery( "*:*" ) );
if( (cnt*2) != response.getResults().getNumFound() ) {
throw new Exception( "did not add everything!" );
}
return elapsed;
}
/**
* query the example
*/
public void testExampleConfig() throws Exception
{
// Empty the database...
long time = makeRequests( "/update", 10000 );
System.out.println( "time: " + time);
}
Re: stax vs xpp XmlUpdateHandler
Posted by Chris Hostetter <ho...@fucit.org>.
: How do you all feel about moving:
: XmlUpdateRequestHandler -> XppUpdateRequestHandler
: StaxUpdateRequestHandler -> XmlUpdateRequestHandler
:
: then deprecating XppUpdateRequestHandler? This will urge people to use
: the Stax implemenation sooner then later and should help iron out any
: problems sooner then later.
I'm kinda out of the looop on the whole Stax/Xpp/Xml update parsing stuff
... am i remembering correctly the end game goal is to reduce/eliminate
dependencies on XPP? (because .... ? .... stax is Java "standard"
included out-of-the-box with java6? (i'm guessing))
: Here is the actual test code:
those are some fairly small documents ... we should probably test out some
bigger inputs.
A lot of people seem to be sending multiple documents at a time as well,
so we should test that use case (ie: <add> containing 10000 small
documents; <add> containg 100 medium documents; <add> containing 1 big
document)
for teh purpose of perf teesting the XML parsing it might also make sense
to use a schema where every field is ignored (ie: no analysys, no stored
values) to help isolate the parsing costs.
-Hoss
Re: stax vs xpp XmlUpdateHandler
Posted by Bill Au <bi...@gmail.com>.
I am also for replacing XPP with STAX. We did performance testing
between XPP and STAX for our Java Solr client and found there is only
a very small difference (XPP was about 3% faster).
Bill
On 6/30/07, Ryan McKinley <ry...@gmail.com> wrote:
> Yonik Seeley wrote:
> > On 6/29/07, Ryan McKinley <ry...@squid-labs.com> wrote:
> >> How do you all feel about moving:
> >> XmlUpdateRequestHandler -> XppUpdateRequestHandler
> >> StaxUpdateRequestHandler -> XmlUpdateRequestHandler
> >>
> >> then deprecating XppUpdateRequestHandler?
> >
> > +1
> >
> > I think we could remove the XppUpdateRequestHandler relatively quickly
> > to get rid of the XPP dependency. It's more of an implementation
> > detail and shouldn't be visible to most users.
> >
>
> I will go ahead and make this change. The XppUpdateRequestHandler will
> still be there if something is amiss. We should remove it (and the
> dependencies) before 1.3
>
> ryan
>
>
Re: stax vs xpp XmlUpdateHandler
Posted by Ryan McKinley <ry...@gmail.com>.
Yonik Seeley wrote:
> On 6/29/07, Ryan McKinley <ry...@squid-labs.com> wrote:
>> How do you all feel about moving:
>> XmlUpdateRequestHandler -> XppUpdateRequestHandler
>> StaxUpdateRequestHandler -> XmlUpdateRequestHandler
>>
>> then deprecating XppUpdateRequestHandler?
>
> +1
>
> I think we could remove the XppUpdateRequestHandler relatively quickly
> to get rid of the XPP dependency. It's more of an implementation
> detail and shouldn't be visible to most users.
>
I will go ahead and make this change. The XppUpdateRequestHandler will
still be there if something is amiss. We should remove it (and the
dependencies) before 1.3
ryan
Re: stax vs xpp XmlUpdateHandler
Posted by Yonik Seeley <yo...@apache.org>.
On 6/29/07, Ryan McKinley <ry...@squid-labs.com> wrote:
> How do you all feel about moving:
> XmlUpdateRequestHandler -> XppUpdateRequestHandler
> StaxUpdateRequestHandler -> XmlUpdateRequestHandler
>
> then deprecating XppUpdateRequestHandler?
+1
I think we could remove the XppUpdateRequestHandler relatively quickly
to get rid of the XPP dependency. It's more of an implementation
detail and shouldn't be visible to most users.
-Yonik