Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Ruby On Rails > Настройка производительности ruby


Автор: ANTON_AL 20.12.2009, 17:31
Доброго дня!

Помогите, пожалуйста, в следующем вопросе:
Я выполняю миграцию данных, которая добавляет примерно 10000 записей в базу SQLite3
Данная операция выполняется вот уже около 5 минут. Я пишу это сообщение, а миграция всё идёт и идёт.

Во время миграции я для каждой записи случайным образом генерирую временной интервал (начальная и конечная дата). Может это даёт основную нагрузку ?
Код

def self.generate_random_dates
    
    # generate begin time
    y = 2009
    mo = 1 + rand( 11 )
    d = 1 + rand( 27 )
    h = rand( 23 )
    m = rand( 59 )
    s = rand( 59 )
    o = rand( 5 ) # UTC offset
    t1 = Time.utc( y, mo, d, h, m, s )    
        
    # generate end time
    h = rand(23)
    m = rand(59)
    s = rand(59)
    t2 = t1 + h*m*s
    
    d1 = DateTime.parse t1.to_s
    d2 = DateTime.parse t2.to_s
    return [d1, d2]
  end  


Смотрю в Process Monitor в Windows, вижу, что интерпретатор Ruby использует лишь 4 % процессорного времени.
Можно ли как-нибудь настроить ruby, чтобы он не стеснялся  smile и кушал столько, сколько потребуется ?

PS: Миграция закончилась
Код

==  AddTestData: migrating ====================================================
==  AddTestData: migrated (1106.2520s) ========================================

... слишком уж много времени для такой простой операции

Автор: shine 20.12.2009, 19:02
1) Выяснить действительное место кода которое тормозит расставив по коду миграции распечатки с выводом текущего времени.
2)Подозреваю что таким местом окажется не функция генерации случчайного числа а именно вставка в БД с коммитом после каждого микроинсерта. Обычно такое лечится инсертами в рамках одной большой транзакции или объединением нескольких инсертов на ввставку одной записи в один инсерт добавляющий несколько записей сразу. Для таких вещей есть специальные рельсовые плугины (гугл в помощь).  

Автор: source777 20.12.2009, 19:35
ANTON_AL
1) Почему используется SQLite3, а не MySQL?
2) Почему заполнение БД идёт из миграции? Миграции существуют для создания структуры БД и в случае необходимости могут выполнять обработку уже существующих данных.
3) Какова цель вызова: DateTime.parse t1.to_s ?
4) В принципе генерацию можно упростить до такого:
Код

def self.generate_random_dates
  t0 = Time.utc(2009, 1, 1)
  t1 = Time.at(t0.to_i + rand(31536000))
  t2 = Time.at(t1.to_i + rand(86400))
  [t1, t2]
end

Автор: ANTON_AL 25.12.2009, 01:55
1) Пока не определился с базой данных. Просто использую ту, которая настроена по умолчанию
2) Не вижу особых проблем с использованием миграций для добавления данных. Помоему, очень даже удобно, т.к. миграции можно отменить, почистив таблицы из метода self.down

В Ruby я пока не силён. Вижу, что коряво получилось генерить даты. В основном запара была с тем, что "Date object is immutable". Вот и приходилось танцевать с бубнами. А, оказывается, всё просто  smile 
Спасибо огромное за пример.

Автор: source777 25.12.2009, 15:52
Цитата(ANTON_AL @  25.12.2009,  01:55 Найти цитируемый пост)
Пока не определился с базой данных. Просто использую ту, которая настроена по умолчанию

Вставка данных в SQLite дело не быстрое, поэтому тут должен стоять выбор или создавать 10000 записей или использовать SQLite, но не делать это одновременно, как сделал ты.

Цитата(ANTON_AL @  25.12.2009,  01:55 Найти цитируемый пост)
Не вижу особых проблем с использованием миграций для добавления данных.

Это не значит, что их нет.   smile 
Каждый инструмент должен использоваться для того, для чего предназначен. Загружать демо-данные через миграции это абсолютно тоже самое, что забивать гвозди микроскопом. Прочитай http://guides.rubyonrails.org/migrations.html по миграциям, чтобы понять их предназначение.
Тем более, что с недавних пор в Rails даже не надо писать собственный rake-task для загрузки демо-данных, как это было принято раньше. См. http://railscasts.com/episodes/179-seed-data

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)