On 06/07/2010, at 3:39 PM, gmoniey wrote: > I've got the delayed deltas working on my machine (as well as upgraded > sphinx/ts), but I had a couple of questions before I go to production. > > 1. I've noticed that there is a ThinkingSphinx.remote_sphinx config > field. I was wondering if this needs to be set to true for my setup (I > have 2 site machines, one of which has searchd running on it, so only > 1 machine is really remote). I thought that all that needed to be done > was to address/port for the production section of sphinx.yml.
It's best to set remote_sphinx to true at the end of your environment.rb (with some logic for the environment) - the reason this is needed is that Thinking Sphinx looks for the pid file to confirm Sphinx is running - and when Sphinx is on a different machine, it can't do that. Setting this to true makes TS assume Sphinx is always running. > 2. Are there any best practices for running the delayed_delta job? > Cron, inittab, etc. Maybe something like god or monit is a better fit? As it should be constantly running, instead of run at a regular interval (otherwise, cron would be a good fit). > 3. Does the delayed delta job need to be restarted to retrieve updates > (i.e. adding new searchable models). Definitely a good idea to restart the queue after any structural changes. Cheers -- Pat > > Thanks. > > On Jun 29, 7:48 pm, Pat Allan <[email protected]> wrote: >> In Delayed Job 1.8.5, it looks it checks for jobs every 5 seconds, but you >> can change that: >> >> Delayed::Worker.sleep_delay = 2 >> >> I assume it's the same in the 2.x releases (when I last checked, I don't >> think the code had changed that dramatically). >> >> -- >> Pat >> >> On 30/06/2010, at 12:41 PM, gmoniey wrote: >> >> >> >>> I see...I guess my only option is to go with delayed jobs. From what I >>> have read in the docs, the delayed_delta job is a long living process >>> which periodically checks for delta objects. Do you have any details >>> on how often it wakes up and processes deltas? Is possible to set this >>> field? >> >>> Thanks. >> >>> arash >> >>> On Jun 29, 6:35 pm, Pat Allan <[email protected]> wrote: >>>> Yup, that's exactly the problem you'd be facing. >> >>>> -- >>>> Pat >> >>>> On 30/06/2010, at 11:30 AM, gmoniey wrote: >> >>>>> Hi Pat, >> >>>>> Thanks for responding. I would like to stay away from delayed deltas >>>>> as we need items to be added to the indexes in realtime. If the index >>>>> files are accessible by all servers, is the issue then contention over >>>>> the same files when attempting to update the deltas? >> >>>>> On Jun 29, 5:55 pm, Pat Allan <[email protected]> wrote: >>>>>> When you're dealing with multiple servers, the best delta approach is >>>>>> delayed deltas - and so you have the delayed job queue running on the >>>>>> same machine that your index files (and probably searchd) are located on. >> >>>>>> That way, all the Sphinx files and processes are in one place, and delta >>>>>> requests get put into the database, and then are handled by the queue. >> >>>>>> -- >>>>>> Pat >> >>>>>> On 30/06/2010, at 10:45 AM, gmoniey wrote: >> >>>>>>> I'm transitioning my app to a multiple server setup, and I am trying >>>>>>> to figure out what the best approach is. From what I gather, the >>>>>>> following should be fine: >> >>>>>>> 1. Run searchd on 1 machine, and have it point to indexes on a nas >>>>>>> (which is accesible by all machines) >>>>>>> 2. Point other machines to the 1 searchd instance. >> >>>>>>> My concern/confusion is with deltas; from what I have read on the >>>>>>> other posts, the delta indexing may fail, but I'm not quite sure why. >>>>>>> Is it that multiple apps may be trying to write to the same files on >>>>>>> the nas? >> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Thinking Sphinx" group. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]. >>>>>>> For more options, visit this group >>>>>>> athttp://groups.google.com/group/thinking-sphinx?hl=en. >> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Thinking Sphinx" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group >>>>> athttp://groups.google.com/group/thinking-sphinx?hl=en. >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Thinking Sphinx" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/thinking-sphinx?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Thinking Sphinx" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/thinking-sphinx?hl=en. > -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en.
