You need dev, test, and live on separate boxes so that you can do capacity tests. When you are sending queries to find out the max rate before overload, you need to do that on dev or test, not live.
Also, you'll need to test new versions of Solr, so you need separate Solr installations. wunder On Dec 14, 2011, at 9:30 AM, Dave Stuart wrote: > Background: > > We have around 100 web sites of various sizes (in terms of indexable content) > and I'm trying to come up with the best architectural design from a > performance perspective. > - Each of the sites has a need for DEV, TEST and LIVE indices. > - The content on the sites divided into 5 groups (but its likely that there > will be more groups in future) which is similar enough to use the same > schema, solrconfig, synonyms, stopwords etc. > - From a search view they are distinct per website (i.e. only that sites > content should appear) . > - The indexing mechanism is the same for all sites (i.e. they all use the web > api) > - While not unlimited we have a fair bit of flexibility on servers (although > they are all virtual) > > > Questions: > - Is it better to > (a) have each site in it own core and webapp > e.g. /solr1/(DEV|TEST|LIVE) /solr2/(DEV|TEST|LIVE) etc > (b) have all the cores in one webapp > e.g. /solr1/(SITE1DEV|SITE1TEST|SITE1LIVE|SITE2DEV|SITE2TEST|SITE2LIVE) > etc > (c) have 3 cores per content group and have a filter query param in all > queries that only grabs that sites data > e.g./solr1/(CONTENTGRP1DEV|CONTENTGRP1TEST....). > (d) same as (c) except sharding across multiple servers > (e) have all the DEV's, TEST's and LIVE's on separate boxes with either the > (b) or (c) setup > eg. (b) box1: /solr1/(SITE1LIVE|SITE2LIVE...) c > /solr1/(ONTENTGRP1LIVE|ONTENTGRP2LIVE...) > > Thanks For the help > > > Regards, > > Dave > >
