Сроки выхода 6-сборки UTM 5.2.1

XoRe · Сообщение **XoRe** » Пн апр 14, 2008 16:06

2Lex:
Не видите особого смысла знать, будет ли устойчиво работать новый функционал?
Ну проверьте хоть на создание 100 таблиц с ежедневными периодами.
У меня есть мысль дифференцировать таблицы суточными интервалами.
Чтобы при запуске месячного отчета проверялся не один 2-гигабайтный файл, а 30 10-20 мегабайтных.
Помоему это неплохой способ увеличить быстродействие.
Хотелось бы, чтобы биллинг смог справиться с этой задачей.

Сообщение **Lex** » Пн апр 14, 2008 16:15

XoRe писал(а):2Lex:
Не видите особого смысла знать, будет ли устойчиво работать новый функционал?
Ну проверьте хоть на создание 100 таблиц с ежедневными периодами.
У меня есть мысль дифференцировать таблицы суточными интервалами.
Чтобы при запуске месячного отчета проверялся не один 2-гигабайтный файл, а 30 10-20 мегабайтных.
Помоему это неплохой способ увеличить быстродействие.
Хотелось бы, чтобы биллинг смог справиться с этой задачей.

Мы проведем тестирование на стенде, но могу сказать, что предложенная схема не улучшит а ухудшит быстродействие. То время, которое выигрывается тем, что таблицы очень маленькие, будет теряться при склеивании данных. С самим механизмом при большом количестве архивов ничего не случится. Если он нормально работает на 10 архивах, то будет так же работать и на 100.

XoRe · Сообщение **XoRe** » Вт апр 15, 2008 10:26

2Lex:
Ну просто в таком случае я не вижу способов заставить формироваться отчет за приемлемое время.
Вы сами как считаете, нормально, когда отчет по трафику за месяц по группе в 1000 пользователей делается за 10-12 часов?

Ata-man

Отчет по трафику по группе тормозит совсем по другой причине - на форуме неоднократно обсуждалось. Мы сейчас формируем такие отчеты собственным скриптом. (С помощью админки отчет за предыдущий месяц по 300 клиентам в спец.группе снимается минимум 6 часов, а с помощью скрипта 1.5 минуты)

#!/bin/sh

#group 220 - clients group 1
#group 270 - clients group 2

START=`date +%s`

from_day="01"
from_month="03"
from_year="2008"
from_hour="00"
from_min="00"
from_sec="00"

to_day="01"
to_month="04"
to_year="2008"
to_hour="00"
to_min="00"
to_sec="00"

FROM_DATE=`date -v"$from_day"d -v"$from_month"m -v"$from_year"y -v"$from_hour"H -v"$from_min"M -v"$from_sec"S +%s`
TO_DATE=`date -v"$to_day"d -v"$to_month"m -v"$to_year"y -v"$to_hour"H -v"$to_min"M -v"$to_sec"S +%s`

GRP="270"

echo ""
echo "Global traffic report on group=$GRP"
echo ""

/usr/local/bin/mysql -u root UTM5 <<EOF
SELECT Q1.t_class AS "Class", sum( Q1.sum_in_bytes ) AS "Bytes", sum( Q1.sum_in_rub ) AS "RUB" \
FROM ( SELECT users_groups_link.user_id, users_groups_link.group_id FROM users_groups_link \
WHERE users_groups_link.group_id=$GRP ) AS Q2, \
( SELECT users_accounts.account_id, users_accounts.uid, users.login \
FROM users_accounts, users WHERE users_accounts.uid=users.id ) AS Q3, \
( SELECT discount_transactions_iptraffic_all.account_id, discount_transactions_iptraffic_all.t_class, \
sum( bytes ) AS sum_in_bytes, sum( discount ) AS sum_in_rub \
FROM discount_transactions_iptraffic_all \
WHERE discount_date >= $FROM_DATE \
AND discount_date < $TO_DATE \
GROUP BY discount_transactions_iptraffic_all.account_id, discount_transactions_iptraffic_all.t_class \
ORDER BY discount_transactions_iptraffic_all.account_id, discount_transactions_iptraffic_all.t_class \
) AS Q1 WHERE Q2.user_id=Q3.uid AND Q1.account_id=Q3.account_id \
GROUP BY Q1.t_class \
ORDER BY Q1.t_class \
;
QUIT
EOF

STOP=`date +%s`

let TIMED=$STOP-$START >/dev/null

echo ""
echo "Script working of $TIMED seconds"
echo ""

GRP - id группы, диапазон задается переменными from_* и to_*.

Выдает сумму за трафик, скачанный данной группой клиентов и объем трафика в байтах.

XoRe · Сообщение **XoRe** » Вт апр 15, 2008 15:39

2Ata-man:
Я в курсе, что utm в отчетах по группам вытаскивает данные по одному пользователю.
В отчетах с детализацией уровня debug это хорошо видно.
SELECT запросы так "тык, тык, тык" идут каждые 40 секунд)
После аггрегации на каждый запрос уходит по 5 секунд.
Кстати напоминает одну цитату на башорге )

В свое время я игрался с такими запросами.
Пытался все сделать через 1 запрос с конструкцией типа WHERE account_id IN ( 1 2 3 ... ).
И все равно делалось медленно.
Но видать хреново игрался )

В общем спасибо за код.
+1 костыль )

Сообщение **Lex** » Вт апр 15, 2008 16:10

Могу сказать, что в 5.2.1-006 формирование отчета по группе переработано и скорость его генерации сравнима со скоростью генерации отчета по всем пользователям в системе.

Magnum72

Lex писал(а):Могу сказать, что в 5.2.1-006 формирование отчета по группе переработано и скорость его генерации сравнима со скоростью генерации отчета по всем пользователям в системе.

Давайте я задам последние три вопроса и вы меня добьете окончательно:

1) скажите вы структуру таблиц уже поправили или можно открывать тред и пытатся всем миром оптимизировать индексы и таблицы?

2) биллинг научился получать и реагировать на ответы мускула об ошибках и роллбаках?

3) В этом месяце выйдет 006 ?

SOLDIER

Свои 2 цента. В версии 006 вы, по обычной своей практике не "включили" ошибки, которые выплывали в версии 5.1.0-015 и устранённые в версии 5.1.0-016, но почему-то всплывшие в версии 5.2.1 -005? У меня есть ощущение, что у вас есть группа, которую я бы назвал "грабленаступатели". Которые спецом вносят ошибки устранённые ранее. Ей Богу, нельзя так. Вообще - я бы держал такую группу. Во времена разгула философии (18-19 век) было учение философа Бернштейна. Суть которого была в следующем - "движение - всё, конечная цель - ничто". Перефразирую - "бабло-всё, и для этого все способы хороши (даже внедрение - если угодно - повторение - старых ошибок)".

Wishmaster

Magnum72 писал(а):
Lex писал(а):Могу сказать, что в 5.2.1-006 формирование отчета по группе переработано и скорость его генерации сравнима со скоростью генерации отчета по всем пользователям в системе.
Давайте я задам последние три вопроса и вы меня добьете окончательно:

1) скажите вы структуру таблиц уже поправили или можно открывать тред и пытатся всем миром оптимизировать индексы и таблицы?

2) биллинг научился получать и реагировать на ответы мускула об ошибках и роллбаках?

3) В этом месяце выйдет 006 ?

Имхо, даже при положительном ответе на вопрос №3, пункт №1 будет совершенно не лишним..

)

XoRe · Сообщение **XoRe** » Ср апр 16, 2008 00:46

2Magnum72:
Могу посоветовать спросить в техподдержке.
Во всяком случае на 1 и 3 вопросы, заданные прямо, мне ответили.
Идея насчет темы про оптимизацию мне нравится.

banec · Сообщение **banec** » Пн апр 21, 2008 14:42

и что ответили?

XoRe · Сообщение **XoRe** » Пн апр 21, 2008 17:24

Я хз насчет того, могу ли я распостранять это.
Поэтому скажу так:
Можно открывать тред и пытатся всем миром оптимизировать индексы и таблицы )

Kayfolom

Добавлю своих предложений, их есть у меня

Посмотрел структуру монстров discount_transactions_all и discount_transactions_iptraffic_all. Думаю есть куда работать. Правда всю жизнь имел дело с MSSQL, но думаю принципы везде одинаковы.
discount_transactions_all :
1. Поле comment varchar 255 - содержит массу одних и тех же записей, может их вынести в отдельную табличку и связать с полем посредством id ? Да и тип varchar по моему программерскому опыту уменьшает быстродействие в несколько раз при select и на порядок при insert\update. Формат UTF-8 раздувает varchar в 2-4 раза, но это только к кирилице относится, хотя не знаю как в мускуле он реализован. Если по тупому в лоб, то содержимое comment - это примерно 25% размера таблицы.
2. Булевские (Boolean) поля, к примеру is_canceled, вместо родного мускульного TINYINT размером 1 байт используются int размером 11
3. Типы полей int (account_id, service_id, service_type, discount_period_id, slink_id) тоже втыкнуты необоснованно. Врядли полю account_id нужен верхний предел 4294967295. Вполне хватило бы SMALLINT (от 0 до 65535).

discount_transactions_iptraffic_all
1. Булевские (Boolean) поля...
2. discount_date и discount_date_hour, discount_date_day, discount_date_month. Не совсем понял логику разработчиков, но судя по всему discount_date_hour, discount_date_day, discount_date_month это результат работы GetHour(discount_date), GetDay(discount_date) и GetMonth(discount_date) соответственно. В любом языке программирования стоимость вызова данных функций эквивалентна десятку операций сложения. Не проще ли это делать в ядре, чем хранить в мускуле лишние 33 байта (~6% размера записи), не говоря уже о затратах на селекты, инсерты.

Вот. Поправте если я ошибаюсь. Никогда профилинг мускульных баз не делал, может в нем все иначе работает.

Magnum72

1. Поле comment varchar 255 - содержит массу одних и тех же записей, может их вынести в отдельную табличку и связать с полем посредством id ? Да и тип varchar по моему программерскому опыту уменьшает быстродействие в несколько раз при select и на порядок при insert\update. Формат UTF-8 раздувает varchar в 2-4 раза, но это только к кирилице относится, хотя не знаю как в мускуле он реализован. Если по тупому в лоб, то содержимое comment - это примерно 25% размера таблицы.

Лучше делать как enum и в нем перечислить все встречающиеся варианты..

2. Булевские (Boolean) поля, к примеру is_canceled, вместо родного мускульного TINYINT размером 1 байт используются int размером 11

тоже enum

3. Типы полей int (account_id, service_id, service_type, discount_period_id, slink_id) тоже втыкнуты необоснованно. Врядли полю account_id нужен верхний предел 4294967295. Вполне хватило бы SMALLINT (от 0 до 65535).

э это плохая идея у меня уже под 30000 абонентов, а если использовать доп аккаунты как буфер при смене тарифа в середине месяца их еще больше будет... но согласен что миллион за глаза.

discount_transactions_iptraffic_all
1. Булевские (Boolean) поля...
2. discount_date и discount_date_hour, discount_date_day, discount_date_month. Не совсем понял логику разработчиков, но судя по всему discount_date_hour, discount_date_day, discount_date_month это результат работы GetHour(discount_date), GetDay(discount_date) и GetMonth(discount_date) соответственно. В любом языке программирования стоимость вызова данных функций эквивалентна десятку операций сложения. Не проще ли это делать в ядре, чем хранить в мускуле лишние 33 байта (~6% размера записи), не говоря уже о затратах на селекты, инсерты.

Как мне объяснили в техподдержке по этому поводу: в постгресе нет таких функций поэтому для совместимости воткнули лишние 33 байта

ЗЫ можно убить автоинкремент и индекс на id в таблице discount_transactions_iptraffic_all она все равно берется строго как в discount_transactions_all

[/quote]

Kayfolom

Magnum72 писал(а):discount_transactions_iptraffic_all
1. Булевские (Boolean) поля...
2. discount_date и discount_date_hour, discount_date_day, discount_date_month. Не совсем понял логику разработчиков, но судя по всему discount_date_hour, discount_date_day, discount_date_month это результат работы GetHour(discount_date), GetDay(discount_date) и GetMonth(discount_date) соответственно. В любом языке программирования стоимость вызова данных функций эквивалентна десятку операций сложения. Не проще ли это делать в ядре, чем хранить в мускуле лишние 33 байта (~6% размера записи), не говоря уже о затратах на селекты, инсерты.

Как мне объяснили в техподдержке по этому поводу: в постгресе нет таких функций поэтому для совместимости воткнули лишние 33 байта

Дык GetHour(discount_date), GetDay(discount_date) и GetMonth(discount_date), или аналоги, есть в любом языке программирования, проще перенести эти вычисления в ядро.