Hi All, I''ve been playing around with Instiki, using mysql as a backend so I can populate the pages and revisions tables with data. This data will later be edited in Instiki, but there is too much of it to end by hand. I have just under 15K rows in the revisions and pages tables. My problem is that although Instiki appears to work okay, it just dies out when it tries to list all the pages. Is this a problem that other people have when they have this many (actually not much) rows of data? I don''t have much to go with for debugging, since I am just learning ruby - the production log file isn''t helpful, I get Processing WikiController#list (for 127.0.0.1 at 2006-08-11 12:55:48) [GET] Parameters: "action"=>"list", "controller"=>"wiki", "web"=>"humandiseaseontology" Which never returns. Instiki goes nuts, sucking up close to 100% of CPU and I have to feed it -9 just to kill the process. Mysql logs look okay. Anybody have any idea what''s going on? -John
Hi- On 8/22/06 11:37 AM, "John Osborne" <j-osborne at northwestern.edu> wrote:> Hi All, > > I''ve been playing around with Instiki, using mysql as a backend so I can > populate the pages and revisions tables with data. This data will later > be edited in Instiki, but there is too much of it to end by hand. I have > just under 15K rows in the revisions and pages tables. > > My problem is that although Instiki appears to work okay, it just dies > out when it tries to list all the pages. Is this a problem that other > people have when they have this many (actually not much) rows of data? > > I don''t have much to go with for debugging, since I am just learning > ruby - the production log file isn''t helpful, I get > > Processing WikiController#list (for 127.0.0.1 at 2006-08-11 12:55:48) [GET] > Parameters: "action"=>"list", "controller"=>"wiki", > "web"=>"humandiseaseontology" > > Which never returns. Instiki goes nuts, sucking up close to 100% of CPU > and I have to feed it -9 just to kill the process. Mysql logs look okay. > Anybody have any idea what''s going on?My production Instiki has about 2K rows in pages + revisions and my "All Pages" does take about 10 seconds. I do have Postgres on the backend rather than MySQL. I did notice that "All Pages" seems slower in 0.11 (db version) than 0.10, but given the sparse information available, I don''t really know what it could be.> > -John > _______________________________________________ > Instiki-users mailing list > Instiki-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/instiki-users-- Daryl http://itsallsemantics.com "Hell, there are no rules here-- we''re trying to accomplish something." -- Thomas A. Edison
Daryl Richter wrote:> My production Instiki has about 2K rows in pages + revisions and my "All > Pages" does take about 10 seconds. I do have Postgres on the backend rather > than MySQL. > > I did notice that "All Pages" seems slower in 0.11 (db version) than 0.10, > but given the sparse information available, I don''t really know what it > could be. > >Thanks Daryl, I was poking around a bit and ran into this: http://blog.zmok.net/articles/2006/08/14/full-text-search-in-ruby-on-rails Right now I''m running mysql on the backend (I gave up on Postgres and my mysql issues went away when I switched from 3.23 to 5) and assuming Instiki is doing a full text search using mysql that could be our problem. I don''t know if there are any plans to add Ferret to Instiki...? -John
On 8/22/06 6:08 PM, "John Osborne" <j-osborne at northwestern.edu> wrote:> Daryl Richter wrote: >> My production Instiki has about 2K rows in pages + revisions and my "All >> Pages" does take about 10 seconds. I do have Postgres on the backend rather >> than MySQL. >> >> I did notice that "All Pages" seems slower in 0.11 (db version) than 0.10, >> but given the sparse information available, I don''t really know what it >> could be. >> >> > Thanks Daryl, I was poking around a bit and ran into this: > http://blog.zmok.net/articles/2006/08/14/full-text-search-in-ruby-on-rails > > Right now I''m running mysql on the backend (I gave up on Postgres and my > mysql issues went away when I switched from 3.23 to 5) and assuming > Instiki is doing a full text search using mysql that could be our > problem. I don''t know if there are any plans to add Ferret to Instiki...?Not that I know of, though I (and John Whitley) have been (very slowly) trying to start working on the Instiki code base. Am I correct in thinking that your problem was fixed by adding a MySQL full-text index?> > -John > >-- Daryl http://itsallsemantics.com "2 + 2 = 5, for sufficiently large values of 2." -- Ron Jeffries
>> Thanks Daryl, I was poking around a bit and ran into this: >> http://blog.zmok.net/articles/2006/08/14/full-text-search-in-ruby-on-rails >> >> Right now I''m running mysql on the backend (I gave up on Postgres and my >> mysql issues went away when I switched from 3.23 to 5) and assuming >> Instiki is doing a full text search using mysql that could be our >> problem. I don''t know if there are any plans to add Ferret to Instiki...? >> > > Not that I know of, though I (and John Whitley) have been (very slowly) > trying to start working on the Instiki code base. > > Am I correct in thinking that your problem was fixed by adding a MySQL > full-text index? >I hesitate to say yes since I haven''t done any performance metrics but I do know this. I added an index in mysql: CREATE UNIQUE INDEX name_index ON pages (name); and for the first time one of my searches in my full (~15K) page database completed. I''ll try to poke around a bit more and get something more definitive. The search still ran for a long time (15 seconds?) but I''m impressed that active record and/or mysql knew enough to use the index. I''m guessing ferret is a better (and db independent) solution though, but I haven''t investigated that yet. What plans do you and John have for the code base? -John