Re: Solritas in production
Just make really, really sure you don't allow queries like: .../solr/update?stream.body=*:* Best Erick On Sun, Aug 12, 2012 at 8:42 AM, george123 wrote: > Apologies to drag this conversation up. > > I want to share my experience. > > Im a code hacker, I have written about 10 lines of code in my life, but can > figure out most things and how they work, or how to get them to work. > > Im looking at deploying a vertical search engine. The data is a bit messy, > but im normalising it as best I can and solr just seems to handle it so > well. Who can argue with results in miliseconds. > > Now, I need to develop a front end. This is proving THE most difficult part > of my solr experience. > > My options are. > 1. Defailt Solritas/velocity > 2. Wrap this into a drupal or similar cms with solr functionality. > 3. Code this in php. > > I dont have the knowledge to code in php. I cant use a cms for a variety of > reasons, most of which are related to how it is handled in the database and > the format of my data not fitting to a cms's framework, so im left to look > at point 1 again. > > Im sure the knowledge in this forum is without question, but when I see > things like "not production ready" that doesnt mean much to me, someone > hacking out a website. Im bootstrapping so finding someone to code an option > 3 for me is a bit hard, even with offshore freelance help. > > If there was a set of steps to get Velocity working with my system that > would give me a solution. Alternatively, if the php (or other) code clients > coded a basic frontend template that guys like me could hack out that would > open up the solr framework to a wider range of people. > > Anyway, after reading this post, and the one on this blog > http://thoughtsasaservice.wordpress.com/2012/05/10/should-you-use-solritas-on-production/ > I think I am going to look down the path of this further. > > The biggest drawback to this I can see is that Velocity consumes more > memory, for me in my situation thats actually ok. Using host side tools like > apache httpd or varnish as has been suggested is something that is possible > in my situation - but a bolt on solution would be ideal. > > Hopefully my experience helps others. I wonder how many people like me > (wordpress/joomla template hackers at best) go to the apache solr project > and turn away because they cant figure out aspects, or they cant just > install a simple solution. > > Dont dump velocity, it ticks so many boxes. Please add to it! > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Solritas-in-production-tp3966191p4000661.html > Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solritas in production
Apologies to drag this conversation up. I want to share my experience. Im a code hacker, I have written about 10 lines of code in my life, but can figure out most things and how they work, or how to get them to work. Im looking at deploying a vertical search engine. The data is a bit messy, but im normalising it as best I can and solr just seems to handle it so well. Who can argue with results in miliseconds. Now, I need to develop a front end. This is proving THE most difficult part of my solr experience. My options are. 1. Defailt Solritas/velocity 2. Wrap this into a drupal or similar cms with solr functionality. 3. Code this in php. I dont have the knowledge to code in php. I cant use a cms for a variety of reasons, most of which are related to how it is handled in the database and the format of my data not fitting to a cms's framework, so im left to look at point 1 again. Im sure the knowledge in this forum is without question, but when I see things like "not production ready" that doesnt mean much to me, someone hacking out a website. Im bootstrapping so finding someone to code an option 3 for me is a bit hard, even with offshore freelance help. If there was a set of steps to get Velocity working with my system that would give me a solution. Alternatively, if the php (or other) code clients coded a basic frontend template that guys like me could hack out that would open up the solr framework to a wider range of people. Anyway, after reading this post, and the one on this blog http://thoughtsasaservice.wordpress.com/2012/05/10/should-you-use-solritas-on-production/ I think I am going to look down the path of this further. The biggest drawback to this I can see is that Velocity consumes more memory, for me in my situation thats actually ok. Using host side tools like apache httpd or varnish as has been suggested is something that is possible in my situation - but a bolt on solution would be ideal. Hopefully my experience helps others. I wonder how many people like me (wordpress/joomla template hackers at best) go to the apache solr project and turn away because they cant figure out aspects, or they cant just install a simple solution. Dont dump velocity, it ticks so many boxes. Please add to it! -- View this message in context: http://lucene.472066.n3.nabble.com/Solritas-in-production-tp3966191p4000661.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solritas in production
Solaritas was never intended to be used for production situations at all. It's reason for existing is to provide: 1> a way to show something prettier than the XML (or JSON or) responses to Solr queries for people just getting started. 2> a way to provide a very quick proof-of-concept/prototyping framework for _internal_ use. You can very rapidly produce reasonable looking results pages for your business folks, product managers, etc. It was never intended to be a customer-facing front end for Solr... FWIW Erick On Wed, May 9, 2012 at 6:39 AM, Marcelo Carvalho Fernandes wrote: > Now that you gave us more info about your project's requirements it's clear > to me that Solritas should not be used in your project. > > - > Marcelo Carvalho Fernandes > On 9 May 2012 04:56, "András Bártházi" wrote: > >> Hi, >> >> Solritas (Velocity Response Writer) is NOT intended for production use. The >> > simple reason, apart from that it is not production grade quality, is >> that >> > it requires direct access to the Solr instance, as it is simply a >> response >> > writer. You MUST use a separate front end layer above Solr and never >> expose >> > Solr directly to the world. So you should feel totally comfortable >> > continuing to use Solr over HTTP from PHP! >> >> >> Thanks for the response, we're agree. >> >> Here is our situation, a bit more detailed. >> >> I see only one reason to use Solritas: >> >> - a Solritas only solution, the architecture is more simple, and a bit >> faster as Symfony has 50-100 ms overhead >> >> But I see a lot for NOT using: >> >> - a very basic (and a bit outdated) documentation >> - it's 3-4 years old technology, but no mention on the net about it - >> I've found about 3 mentions to use it for prototyping, seems to be nobody >> using it, nobody has questions about it >> - have found no public site using it >> - it's a template engine based solution, it has no framework around it >> (like Symfony - I miss a lot of features), it's a view - and implementing >> logic in a view layer is not a best practice (some logic can be >> implemented >> using Java code, but it will still belong to the view layer, and >> practically) >> - it's a MODEL (a search query)->VIEW solution with almost no >> controller, Symfony is a full MVC framework >> - there can be only one search query on a page, and as we have pages >> with 3 different queries, and these pages are SEO related, it seems to be >> not possible to solve it with Solritas (using AJAX may be a solution if >> SEO >> would not be important) >> - we have a lot of PHP based logic (just some basic examples: processing >> URLs, generating titles), some needs database access as well, porting it >> to >> Velocity seems to be a huge task if it's possible at all >> - some parts, like our autosuggest solutions may be ported to Solritas >> easily, however it may need changing our quite complex client side >> JavaScript code, and seems to be a less maintainable situation for our >> programmers have direct access to the PHP code only >> - we have tasks those need the search engine, but have no frontend at >> all, like sending emails with search results based on saved queries, and >> previously sent results (do not send the same results again) >> >> I may have not listed all my points, but these may be show my point of >> view. >> >> Bye, >> Andras >>
Re: Solritas in production
Le 7 mai 2012 à 13:30, Marcelo Carvalho Fernandes a écrit : > Anything else? If fearing DoS attacks by too large queries (e.g. if having millions of documents), consider writing a query-component that can limit the queries. I believe that there's nothing else. paul
Re: Solritas in production
I would not use Solaritas unless for very rudimentary solutions and prototypes. Sent from my Mobile device 720-256-8076 On May 6, 2012, at 6:02 AM, András Bártházi wrote: > Hi, > > We're currently evaluating Solr as a Sphinx replacement. Our site has > 1.000.000+ pageviews a day, it's a real estate search engine. The > development is almost done, and it seems to be working fine, however some > of my colleagues come with the idea that we're using it wrong. We're using > it as a service from PHP/Symfony. > > They think we should use Solritas as a frontend, so site visitors will > directly use it, so no PHP will be involved, so it will be use much less > infrastructure. One of them said that even mobile.de using it that way (I > have found no clue about it at all). > > Do you think is it a good idea? > > Do you know services using Solritas as a frontend on a public site? > > My personal opinion is that using Solritas in production is a very bad idea > for us, but have not so much experience with Solr yet, and Solritas > documentation is far from a detailed, up-to-date one, so don't really know > what is it really usable for. > > Thanks, > Andras
Re: Solritas in production
Nothing against PHP. My suggestion is toward a simpler architecture and a fast go-live. I'm not suggesting Andreas to go-live with Solritas as it is. Of course there is some work to be done before doing it and I think this work would be faster and would take him to a simpler architecture than setting up and developing a PHP layer. Why add something new if what you have can be easily customized? Maybe we could create a "to do list" in order to start thinking of going live with Solritas: - if you are going to use a DIH with a database do not let the database configuration plain in data-config.xml. Let data-config.xml references a jndi of your database config. - in order to restrict access to the Solr admin interface, change authentication configuration in the solr war's web.xml.ve - have in mind that Solritas uses a template system (Velocity). It is limited in the way you wont be able to build backend processing with it. - fell free to customize Solritas layout using CSS3, HTML5, ajax and all client side stuff. - consider using and Apache httpd as a reverse proxy to restrict direct access to your solritas. -if you have a high traffic landing on you solritas, consider having a Varnish in front of it. Anything else? What do you think? - Marcelo Carvalho Fernandes On 7 May 2012 06:51, "Jan Høydahl" wrote: > Hi, > > Like wunder said, restricting URLs still requires physical access to the > app-server, and there are a handful of ways to cause harm which you may not > be aware of. The argument "he would not need to develop a PHP > site/application" is not true. Solritas is far from ready for production, > and not intended to either. Even if you moved the Solritas code to another > Tomcat instance to avoid direct Solr access, you would still need to put > extensive development effort into the Solritas templates before you could > call it a finished search front end. What is so bad with PHP after all? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > Solr Training - www.solrtraining.com > > On 7. mai 2012, at 02:50, Marcelo Carvalho Fernandes wrote: > > > Hi Jan, > > > > I would answer András exactly the oposite :-) I would like to understand > > and ask you something. > > > > Would you see any problem if he had a Apache Httpd configured as reverse > > proxy (no PHP in it) in front of Solr just to restrict user access to > only > > the Solritas's URL? This way Solr would not be directly exposed and he > > would not need to develop a PHP site/application. > > > > Maybe a Varnish layer would be even better as he has 1.000.000+ > pageviews a > > day. Again, no PHP in this scenario. > > > > What's your opinion about both solutions? > > > > Thanks in advance, > > > > > > Marcelo Carvalho Fernandes > > +55 21 8272-7970 > > +55 21 2205-2786 > > > > > > On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl > wrote: > > > >> Hi, > >> > >> Solritas (Velocity Response Writer) is NOT intended for production use. > >> The simple reason, apart from that it is not production grade quality, > is > >> that it requires direct access to the Solr instance, as it is simply a > >> response writer. You MUST use a separate front end layer above Solr and > >> never expose Solr directly to the world. So you should feel totally > >> comfortable continuing to use Solr over HTTP from PHP! > >> > >> -- > >> Jan Høydahl, search solution architect > >> Cominvent AS - www.cominvent.com > >> Solr Training - www.solrtraining.com > >> > >> On 6. mai 2012, at 14:02, András Bártházi wrote: > >> > >>> Hi, > >>> > >>> We're currently evaluating Solr as a Sphinx replacement. Our site has > >>> 1.000.000+ pageviews a day, it's a real estate search engine. The > >>> development is almost done, and it seems to be working fine, however > some > >>> of my colleagues come with the idea that we're using it wrong. We're > >> using > >>> it as a service from PHP/Symfony. > >>> > >>> They think we should use Solritas as a frontend, so site visitors will > >>> directly use it, so no PHP will be involved, so it will be use much > less > >>> infrastructure. One of them said that even mobile.de using it that way > >> (I > >>> have found no clue about it at all). > >>> > >>> Do you think is it a good idea? > >>> > >>> Do you know services using Solritas as a frontend on a public site? > >>> > >>> My personal opinion is that using Solritas in production is a very bad > >> idea > >>> for us, but have not so much experience with Solr yet, and Solritas > >>> documentation is far from a detailed, up-to-date one, so don't really > >> know > >>> what is it really usable for. > >>> > >>> Thanks, > >>> Andras > >> > >> > >
Re: Solritas in production
I do not share this reasoning at all. Of course a new UI would need to be developed, solr/itas is just an example. But that precisely is the interest of solr/itas, a view system that is easy to tune. I do not feel, at all, that it means that it is not production ready. There are a zillion ways to kill someone's server, some of them you sketched, which normal developers just have to accept as dangers. I barely see a difference between a solr/itas abuse such as see all params or a zillion requests or crawl. I also do not think that this answers the question of production readiness. I would more understand this question about the performance and potential leaks. paul Le 7 mai 2012 à 11:51, Jan Høydahl a écrit : > Hi, > > Like wunder said, restricting URLs still requires physical access to the > app-server, and there are a handful of ways to cause harm which you may not > be aware of. The argument "he would not need to develop a PHP > site/application" is not true. Solritas is far from ready for production, and > not intended to either. Even if you moved the Solritas code to another Tomcat > instance to avoid direct Solr access, you would still need to put extensive > development effort into the Solritas templates before you could call it a > finished search front end. What is so bad with PHP after all? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > Solr Training - www.solrtraining.com > > On 7. mai 2012, at 02:50, Marcelo Carvalho Fernandes wrote: > >> Hi Jan, >> >> I would answer András exactly the oposite :-) I would like to understand >> and ask you something. >> >> Would you see any problem if he had a Apache Httpd configured as reverse >> proxy (no PHP in it) in front of Solr just to restrict user access to only >> the Solritas's URL? This way Solr would not be directly exposed and he >> would not need to develop a PHP site/application. >> >> Maybe a Varnish layer would be even better as he has 1.000.000+ pageviews a >> day. Again, no PHP in this scenario. >> >> What's your opinion about both solutions? >> >> Thanks in advance, >> >> >> Marcelo Carvalho Fernandes >> +55 21 8272-7970 >> +55 21 2205-2786 >> >> >> On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl wrote: >> >>> Hi, >>> >>> Solritas (Velocity Response Writer) is NOT intended for production use. >>> The simple reason, apart from that it is not production grade quality, is >>> that it requires direct access to the Solr instance, as it is simply a >>> response writer. You MUST use a separate front end layer above Solr and >>> never expose Solr directly to the world. So you should feel totally >>> comfortable continuing to use Solr over HTTP from PHP! >>> >>> -- >>> Jan Høydahl, search solution architect >>> Cominvent AS - www.cominvent.com >>> Solr Training - www.solrtraining.com >>> >>> On 6. mai 2012, at 14:02, András Bártházi wrote: >>> >>>> Hi, >>>> >>>> We're currently evaluating Solr as a Sphinx replacement. Our site has >>>> 1.000.000+ pageviews a day, it's a real estate search engine. The >>>> development is almost done, and it seems to be working fine, however some >>>> of my colleagues come with the idea that we're using it wrong. We're >>> using >>>> it as a service from PHP/Symfony. >>>> >>>> They think we should use Solritas as a frontend, so site visitors will >>>> directly use it, so no PHP will be involved, so it will be use much less >>>> infrastructure. One of them said that even mobile.de using it that way >>> (I >>>> have found no clue about it at all). >>>> >>>> Do you think is it a good idea? >>>> >>>> Do you know services using Solritas as a frontend on a public site? >>>> >>>> My personal opinion is that using Solritas in production is a very bad >>> idea >>>> for us, but have not so much experience with Solr yet, and Solritas >>>> documentation is far from a detailed, up-to-date one, so don't really >>> know >>>> what is it really usable for. >>>> >>>> Thanks, >>>> Andras >>> >>> >
Re: Solritas in production
Hi, Like wunder said, restricting URLs still requires physical access to the app-server, and there are a handful of ways to cause harm which you may not be aware of. The argument "he would not need to develop a PHP site/application" is not true. Solritas is far from ready for production, and not intended to either. Even if you moved the Solritas code to another Tomcat instance to avoid direct Solr access, you would still need to put extensive development effort into the Solritas templates before you could call it a finished search front end. What is so bad with PHP after all? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 7. mai 2012, at 02:50, Marcelo Carvalho Fernandes wrote: > Hi Jan, > > I would answer András exactly the oposite :-) I would like to understand > and ask you something. > > Would you see any problem if he had a Apache Httpd configured as reverse > proxy (no PHP in it) in front of Solr just to restrict user access to only > the Solritas's URL? This way Solr would not be directly exposed and he > would not need to develop a PHP site/application. > > Maybe a Varnish layer would be even better as he has 1.000.000+ pageviews a > day. Again, no PHP in this scenario. > > What's your opinion about both solutions? > > Thanks in advance, > > > Marcelo Carvalho Fernandes > +55 21 8272-7970 > +55 21 2205-2786 > > > On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl wrote: > >> Hi, >> >> Solritas (Velocity Response Writer) is NOT intended for production use. >> The simple reason, apart from that it is not production grade quality, is >> that it requires direct access to the Solr instance, as it is simply a >> response writer. You MUST use a separate front end layer above Solr and >> never expose Solr directly to the world. So you should feel totally >> comfortable continuing to use Solr over HTTP from PHP! >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> Solr Training - www.solrtraining.com >> >> On 6. mai 2012, at 14:02, András Bártházi wrote: >> >>> Hi, >>> >>> We're currently evaluating Solr as a Sphinx replacement. Our site has >>> 1.000.000+ pageviews a day, it's a real estate search engine. The >>> development is almost done, and it seems to be working fine, however some >>> of my colleagues come with the idea that we're using it wrong. We're >> using >>> it as a service from PHP/Symfony. >>> >>> They think we should use Solritas as a frontend, so site visitors will >>> directly use it, so no PHP will be involved, so it will be use much less >>> infrastructure. One of them said that even mobile.de using it that way >> (I >>> have found no clue about it at all). >>> >>> Do you think is it a good idea? >>> >>> Do you know services using Solritas as a frontend on a public site? >>> >>> My personal opinion is that using Solritas in production is a very bad >> idea >>> for us, but have not so much experience with Solr yet, and Solritas >>> documentation is far from a detailed, up-to-date one, so don't really >> know >>> what is it really usable for. >>> >>> Thanks, >>> Andras >> >>
Re: Solritas in production
Hi, - Original Message - > Dne 6.5.2012 14:02, András Bártházi napsal(a): >> We're currently evaluating Solr as a Sphinx replacement. The >> development is almost done, and it seems to be working fine >> why you want to replace sphinx with solr? That's an interesting question. Until recently, I never saw any Sematext clients coming to us wanting to replace Sphinx. Then one company came to us with this request and I jokingly said how we never see people using Sphinx. Then suddenly, in the last few months, we've had a number of clients who mentioned Sphinx in one context or another. Is something (not) happening with Sphinx? Otis Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm
Re: Solritas in production
Hi, We're currently evaluating Solr as a Sphinx replacement. The >> >> development is almost done, and it seems to be working fine >> > why you want to replace sphinx with solr? > (is it ontopic here?) Solr+Lucene has far more features, and seems to be more extendable as well. - we had problems about speed related to faceting (while I know it can be implemented), Solr's faceting looks promising - we had to do some workaround to implement some other features on the site, the Solr version of these are simpler - and we miss a good solution for scalability and availability like Solr Cloud. Anyway, Sphinx works really well, but Solr seems to be better for us. Bye, Andras
Re: Solritas in production
Dne 6.5.2012 14:02, András Bártházi napsal(a): We're currently evaluating Solr as a Sphinx replacement. The development is almost done, and it seems to be working fine why you want to replace sphinx with solr?
Re: Solritas in production
Do not directly expose Solr to WWW traffic. It isn't designed for that. For example, the admin pages have no access controls. I can change my request parameters to request a million rows and put a huge load on your server. A few of those, and you are off the air. I can fetch your config, then send a command to DIH to do a full import. And so on. wunder On May 6, 2012, at 5:50 PM, Marcelo Carvalho Fernandes wrote: > Hi Jan, > > I would answer András exactly the oposite :-) I would like to understand > and ask you something. > > Would you see any problem if he had a Apache Httpd configured as reverse > proxy (no PHP in it) in front of Solr just to restrict user access to only > the Solritas's URL? This way Solr would not be directly exposed and he > would not need to develop a PHP site/application. > > Maybe a Varnish layer would be even better as he has 1.000.000+ pageviews a > day. Again, no PHP in this scenario. > > What's your opinion about both solutions? > > Thanks in advance, > > > Marcelo Carvalho Fernandes > +55 21 8272-7970 > +55 21 2205-2786 > > > On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl wrote: > >> Hi, >> >> Solritas (Velocity Response Writer) is NOT intended for production use. >> The simple reason, apart from that it is not production grade quality, is >> that it requires direct access to the Solr instance, as it is simply a >> response writer. You MUST use a separate front end layer above Solr and >> never expose Solr directly to the world. So you should feel totally >> comfortable continuing to use Solr over HTTP from PHP! >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> Solr Training - www.solrtraining.com >> >> On 6. mai 2012, at 14:02, András Bártházi wrote: >> >>> Hi, >>> >>> We're currently evaluating Solr as a Sphinx replacement. Our site has >>> 1.000.000+ pageviews a day, it's a real estate search engine. The >>> development is almost done, and it seems to be working fine, however some >>> of my colleagues come with the idea that we're using it wrong. We're >> using >>> it as a service from PHP/Symfony. >>> >>> They think we should use Solritas as a frontend, so site visitors will >>> directly use it, so no PHP will be involved, so it will be use much less >>> infrastructure. One of them said that even mobile.de using it that way >> (I >>> have found no clue about it at all). >>> >>> Do you think is it a good idea? >>> >>> Do you know services using Solritas as a frontend on a public site? >>> >>> My personal opinion is that using Solritas in production is a very bad >> idea >>> for us, but have not so much experience with Solr yet, and Solritas >>> documentation is far from a detailed, up-to-date one, so don't really >> know >>> what is it really usable for. >>> >>> Thanks, >>> Andras >> >> -- Walter Underwood wun...@wunderwood.org
Re: Solritas in production
Hi Jan, I would answer András exactly the oposite :-) I would like to understand and ask you something. Would you see any problem if he had a Apache Httpd configured as reverse proxy (no PHP in it) in front of Solr just to restrict user access to only the Solritas's URL? This way Solr would not be directly exposed and he would not need to develop a PHP site/application. Maybe a Varnish layer would be even better as he has 1.000.000+ pageviews a day. Again, no PHP in this scenario. What's your opinion about both solutions? Thanks in advance, Marcelo Carvalho Fernandes +55 21 8272-7970 +55 21 2205-2786 On Sun, May 6, 2012 at 7:42 PM, Jan Høydahl wrote: > Hi, > > Solritas (Velocity Response Writer) is NOT intended for production use. > The simple reason, apart from that it is not production grade quality, is > that it requires direct access to the Solr instance, as it is simply a > response writer. You MUST use a separate front end layer above Solr and > never expose Solr directly to the world. So you should feel totally > comfortable continuing to use Solr over HTTP from PHP! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > Solr Training - www.solrtraining.com > > On 6. mai 2012, at 14:02, András Bártházi wrote: > > > Hi, > > > > We're currently evaluating Solr as a Sphinx replacement. Our site has > > 1.000.000+ pageviews a day, it's a real estate search engine. The > > development is almost done, and it seems to be working fine, however some > > of my colleagues come with the idea that we're using it wrong. We're > using > > it as a service from PHP/Symfony. > > > > They think we should use Solritas as a frontend, so site visitors will > > directly use it, so no PHP will be involved, so it will be use much less > > infrastructure. One of them said that even mobile.de using it that way > (I > > have found no clue about it at all). > > > > Do you think is it a good idea? > > > > Do you know services using Solritas as a frontend on a public site? > > > > My personal opinion is that using Solritas in production is a very bad > idea > > for us, but have not so much experience with Solr yet, and Solritas > > documentation is far from a detailed, up-to-date one, so don't really > know > > what is it really usable for. > > > > Thanks, > > Andras > >
Re: Solritas in production
Hi, Solritas (Velocity Response Writer) is NOT intended for production use. The simple reason, apart from that it is not production grade quality, is that it requires direct access to the Solr instance, as it is simply a response writer. You MUST use a separate front end layer above Solr and never expose Solr directly to the world. So you should feel totally comfortable continuing to use Solr over HTTP from PHP! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 6. mai 2012, at 14:02, András Bártházi wrote: > Hi, > > We're currently evaluating Solr as a Sphinx replacement. Our site has > 1.000.000+ pageviews a day, it's a real estate search engine. The > development is almost done, and it seems to be working fine, however some > of my colleagues come with the idea that we're using it wrong. We're using > it as a service from PHP/Symfony. > > They think we should use Solritas as a frontend, so site visitors will > directly use it, so no PHP will be involved, so it will be use much less > infrastructure. One of them said that even mobile.de using it that way (I > have found no clue about it at all). > > Do you think is it a good idea? > > Do you know services using Solritas as a frontend on a public site? > > My personal opinion is that using Solritas in production is a very bad idea > for us, but have not so much experience with Solr yet, and Solritas > documentation is far from a detailed, up-to-date one, so don't really know > what is it really usable for. > > Thanks, > Andras
Solritas in production
Hi, We're currently evaluating Solr as a Sphinx replacement. Our site has 1.000.000+ pageviews a day, it's a real estate search engine. The development is almost done, and it seems to be working fine, however some of my colleagues come with the idea that we're using it wrong. We're using it as a service from PHP/Symfony. They think we should use Solritas as a frontend, so site visitors will directly use it, so no PHP will be involved, so it will be use much less infrastructure. One of them said that even mobile.de using it that way (I have found no clue about it at all). Do you think is it a good idea? Do you know services using Solritas as a frontend on a public site? My personal opinion is that using Solritas in production is a very bad idea for us, but have not so much experience with Solr yet, and Solritas documentation is far from a detailed, up-to-date one, so don't really know what is it really usable for. Thanks, Andras
