--
You received this message because you are subscribed to the Google Groups "SolrNet" group.
To post to this group, send email to sol...@googlegroups.com.
To unsubscribe from this group, send email to solrnet+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/solrnet?hl=en.
I run a very large, highly available site which is very dependant on
SolrNet and it has never failed to perform or be the fastest part of
the site. Also why would you ~want~ to pull back a few thousand
records in one request ? This is of no use to the user and Solr's
paging and filtering/faceting should eliminate the need for having to
pull a lot of fields and then apply logic to them. A lot of the time
if you are talking about a larger scaled site then other factors such
as load balancing and aggressive caching of the solr requests come
into play that effect core performance.
Don't get me wrong though, there is no reason why you shouldn't code
up the JSON parsers for SolrNet and it can only make the project
stronger and fully featured if stuff like this is committed although
the java binary format would be smaller still and if you were to
prioritise work then it should probably be that :D (I think there is a
branch for this already)
Well... simply put... parsing json is far quicker and is less
"bloated" than xml. Take a scenario where you have a very large index
and with a query pulling back a few thousand records,
a json response
from Solr will be substantially smaller over the network.
It is
increasingly being used to replace xml as the method of choice for
data transport over networks.... not just http calls from javascript.
Have a read through this article I came across yesterday:
http://www.codeproject.com/KB/IP/fastJSON.aspx
I appreciate the fact that implementing a new parser is a low priority
for you, but just because the performance is good enough for your
apps, doesn't mean it's good for other people out there who is using
your library in .net. Looking at some other posts, it seems to me
that there is quite a bit of interest in the json parser.....
if it's purely a case that you don't have enough time to implement a
json parser, then I'd be happy to help on that side and contribute the
code back....