ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Правильное тестирование запросов
25 сообщений из 26, страница 1 из 2
  1  все
Правильное тестирование запросов
    #39046581
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
Доброе время суток.

Нужно протестировать несколько вариантов одного запроса на предмет времени выполнения.
Как правильно сбросить кэш итп между запросами дабы протестировать чисто? (хотелось бы ещё узнать в каких случаях кэш и прочие улучшалки скорости сбрасываются. Достаточно ли разрыва соединения, или нужна остановка сервера или и остановка не гарантирует очистку?) Порылся в доке по ключевым словат cache и кэш только коды ошибок. В исходниках выискивать думаю много время уйдёт пока разберусь. Подозреваю что просмотр плана выполнения тоже не совсем то что надо.
Подскажите или направьте пожалуйста.

Спасибо
...
Рейтинг: 0 / 0
09.09.2015, 10:54
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046594
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Mikhail Tchervonenko!
You wrote on 9 сентября 2015 г. 11:02:56:

Mikhail Tchervonenko> Достаточно ли разрыва соединенияисходи из архитектуры.
у SS кеш общий.
у CS и SC - нет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.09.2015, 11:03
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046601
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
МимопроходящийHello, Mikhail Tchervonenko!
You wrote on 9 сентября 2015 г. 11:02:56:

Mikhail Tchervonenko> Достаточно ли разрыва соединенияисходи из архитектуры.
у SS кеш общий.
у CS и SC - нет.


а программно никак?
...
Рейтинг: 0 / 0
09.09.2015, 11:06
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046602
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Mikhail Tchervonenko,

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

Файловый кеш нормально никак не сбросить. Но его можно отключить и мерить без него. Для этого надо выставить DefaultDbCachePages > FileSystemCacheThreshold.

Собственно зачем вам мерить без кеша, может быть наоборот делать замеры по второму прогону запроса, когда часть или все нужные страницы уже закешировались?

В тройке просмотр explain плана может рассказать очень многое, но для этого надо разбираться в методах доступа.
...
Рейтинг: 0 / 0
09.09.2015, 11:06
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046631
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
Симонов ДенисMikhail Tchervonenko,
......
Собственно зачем вам мерить без кеша, может быть наоборот делать замеры по второму прогону запроса, когда часть или все нужные страницы уже закешировались?

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

если честно, подошел коллега из немцев увидевший в моём коде distinct и заявил что distinct это зло, что надо либо group by использовать либо join итп, я как то раньше не парился по поводу запросов время выполнения которых очень мало, но раз указали
вот задался вопросом а что собственно в действительности быстрее
select distinct messetrm.idclt from messetrm
или
select messetrm.idclt from messetrm group by messetrm.idclt

хотел посмотреть в исходниках но после беглого анализа понял что общая картина требует больше времени на разбор, а время как всегда нет, по плану запроса выглядит одинаково
по времени тоже примерно одинаково
разница во времени незначительна и в пределах погрешности
потому важно исключить сторонние факторы
да и на будущее не помешает знать как тестировать
поскольку по FB я далеко не эксперт то по идее на такой вопрос правильный ответ знает только разработчик или правильный тест.
...
Рейтинг: 0 / 0
09.09.2015, 11:20
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046642
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Mikhail Tchervonenko!
You wrote on 9 сентября 2015 г. 11:22:23:

Mikhail Tchervonenko> подошел коллега из немцев увидевший в моём коде distinct и заявил что distinct это зло
у него ориентация нетрадиционная, или иные тараканы?
интересно просто, отчего у человека такие задвиги?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.09.2015, 11:23
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046664
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
МимопроходящийHello, Mikhail Tchervonenko!
You wrote on 9 сентября 2015 г. 11:22:23:

Mikhail Tchervonenko> подошел коллега из немцев увидевший в моём коде distinct и заявил что distinct это зло
у него ориентация нетрадиционная, или иные тараканы?
интересно просто, отчего у человека такие задвиги?

у него задвиг что он сторонний "спец" который писал для этой конторы уже 7 лет и в ус не дул а тут пришел ещё кто то и составил ему конкуренцию. Потому по любому поводу пытается поскрести пальцем и поставить на вид. Причем зачастую по поводу совершенно незначительному, но поскольку руководство не понимает что важно что нет ...

п.с. и надо сказать говнокода я у него видел уже несметное количество, но по соображениям политкоректности не бегу жаловаться на это начальству, опять же, что бы разобраться в том что он 7 лет ваял нужна его кооперация. Ничего не документировано, огромная база без слёз не глянеш причем он сам там уже перестаёт местами ориентироваться итп Но поскольку все худо бедно работает (хоть все и стонут, ежедневно нужно лезть в базу и что то править руками т.к. процесс не продуман до конца или просто неправильно написан) руководство считает что он хороший кодер, а мне склока тоже не нужна, помочь она никак не сможет а общему делу навредит. Поэтому если возражать то аргументированно.
вот собственно почему хочется правильно проверить
...
Рейтинг: 0 / 0
09.09.2015, 11:37
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046686
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Mikhail Tchervonenko!
You wrote on 9 сентября 2015 г. 11:43:53:

Mikhail Tchervonenko> вот собственно почему хочется правильно проверить
если в плане стоит SORT, то кешируй/не кешируй, а затраты на сортировку будут.
присоединяюсь к мнению Дениса, что для "тестирования скорости" отключать кеш, это уж слишком.
делай серию: 3-4 раза подряд, смотри статистику.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.09.2015, 11:47
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046751
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Mikhail Tchervonenko,

наоборот замеряй по второму выполнению.

distinct может выполняться только одним способом - это внешняя сортировка. group by может использовать внешнюю сортировку или навигацию по индексу (если на поле idclt есть индекс).

Каков будет результат конкретно у вас сказать трудно. Может выиграть как один так и другой метод. Зависит от того какой там у вас DefaultDbCachePages и TempCacheLimit, вмешается ли табличка со своими индексами целиком в кеш, вмешается ли сортировка в TempCacheLimit.

Когда лично у меня выигрывает distinct. Но здесь табличка большая 4 079 052 записей.

TempCacheLimit = 512M
DefaultDbCachePages = 32K

Код: sql
1.
2.
3.
4.
5.
 SELECT
     CODE_WORD_GENDER
 FROM
     WORD_DICTIONARY_EXT
 GROUP BY CODE_WORD_GENDER



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
План
PLAN (WORD_DICTIONARY_EXT ORDER FK_WORD_DICTIONARY_GENDER)

Select Expression
    -> Aggregate
        -> Table "WORD_DICTIONARY_EXT" Access By ID
            -> Index "FK_WORD_DICTIONARY_GENDER" Full Scan

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 18s 236ms
Среднее время на получение одной записи = 3 647,20 ms
Current memory = 559 799 136
Max memory = 559 845 656
Memory buffers = 32 768
Reads from disk to cache = 132 632
Writes from cache to disk = 0
Чтений из кэша = 12 238 433

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 9s 297ms
Среднее время на получение одной записи = 1 859,40 ms
Current memory = 559 798 224
Max memory = 559 845 656
Memory buffers = 32 768
Reads from disk to cache = 132 474
Writes from cache to disk = 0
Чтений из кэша = 12 238 433

Второй прогон уже лучше.

Код: sql
1.
2.
3.
4.
5.
 SELECT
     DISTINCT
     CODE_WORD_GENDER
 FROM
     WORD_DICTIONARY_EXT



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
План
PLAN SORT (WORD_DICTIONARY_EXT NATURAL)

Select Expression
    -> Unique Sort (record length: 24, key length: 8)
        -> Table "WORD_DICTIONARY_EXT" Full Scan

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 6s 709ms
Среднее время на получение одной записи = 1 341,80 ms
Current memory = 557 583 832
Max memory = 560 498 200
Memory buffers = 32 768
Reads from disk to cache = 32 924
Writes from cache to disk = 0
Чтений из кэша = 8 224 265

Без навигации по индексу количество чтений с диска намного меньше. Одни и те же
страницы не читаются многократно. Видим существенно лусшее время.

OK. Выключаем индекс в GROUP BY

Код: sql
1.
2.
3.
4.
5.
 SELECT
     CODE_WORD_GENDER+0
 FROM
     WORD_DICTIONARY_EXT
 GROUP BY CODE_WORD_GENDER+0



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
 План
PLAN SORT (WORD_DICTIONARY_EXT NATURAL)

Select Expression
    -> Aggregate
        -> Sort (record length: 40, key length: 12)
            -> Table "WORD_DICTIONARY_EXT" Full Scan

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 10s 420ms
Среднее время на получение одной записи = 2 084,00 ms
Current memory = 557 359 264
Max memory = 757 643 640
Memory buffers = 32 768
Reads from disk to cache = 33 075
Writes from cache to disk = 0
Чтений из кэша = 8 224 266

Ага чтений существено ниже чем в GROUP BY с навигацией по индексу,
но время стало больше. Вероятно сортировка перестала помешаться на диск.

dimitr,

почему в GROUP BY record length и key length стали больше чем в DISTINCT?
...
Рейтинг: 0 / 0
09.09.2015, 12:17
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046755
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Симонов Денис,

тьфу не на диск а в TempCacheLimit конечно
...
Рейтинг: 0 / 0
09.09.2015, 12:18
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046777
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
кстати интересное наблюдение,
в обоих случаях план выглядит как
PLAN SORT ((MESSETRM NATURAL))
при этом поле messetrm.idclt входит в prymary key (ALTER TABLE MESSETRM ADD CONSTRAINT PK_MESSETRM PRIMARY KEY (IDMTG, IDPRT, IDUSR, IDCLT, MTAG, TIMEVON);)
в обоих случаях:
select distinct messetrm.idclt from messetrm
select messetrm.idclt from messetrm group by messetrm.idclt
индекс не использовался

если с distinct, насколько память мне не изменяет, borland в IB6 в плане борьбы со своими багами тупо выключил дружбу с индексами то про в group by я незнал, это из той же песни?
...
Рейтинг: 0 / 0
09.09.2015, 12:26
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046796
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Mikhail Tchervonenko,

потому что твое поле это уже второй сегмент индекса. Был бы первый возможно подхватился бы. Читай здесь http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter122
...
Рейтинг: 0 / 0
09.09.2015, 12:34
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046800
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
точнее четвёртый
...
Рейтинг: 0 / 0
09.09.2015, 12:35
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046831
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
Симонов ДенисMikhail Tchervonenko,

потому что твое поле это уже второй сегмент индекса. Был бы первый возможно подхватился бы. Читай здесь http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter122

спасибо за ссылочку, ооооч. интересно.
...
Рейтинг: 0 / 0
09.09.2015, 12:49
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046841
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Mikhail Tchervonenko,

немного ошибся я. Про это написано в следующей главе http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter123
В общем это статья поможет много чего прояснить.
...
Рейтинг: 0 / 0
09.09.2015, 12:53
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046876
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
Симонов Денис,

ну в моём случае важна часть
авторИндексы могут быть простыми (односегментными) и составными (многосегментными или композитными). Следует отметить, что совокупность полей композитного индекса представляет собой единый ключ. Поиск в индексе может осуществляться как по ключу целиком, так и по его подстроке (подключу). Очевидно, что поиск по подключу допустим только для начальной части ключа (например, starting with или использование не всех сегментов композита). Если поиск осуществляется по всем сегментам индекса, то это называется полным совпадением (full match) ключа, иначе это частичное совпадение (partial match) ключа. Отсюда для композитного индекса по полям (A, B, C) следует, что:

он может быть использовать для предикатов (A = 0) или (A = 0 and B = 0) или (A = 0 and B = 0 and C = 0), но не может быть использован для предикатов (B = 0) или (C = 0) или (B = 0 and C = 0);
предикат (A = 0 and B > 0 and C = 0) приведет к частичному совпадению по двум сегментам, а предикат (A > 0 and B = 0) - к частичному совпадению всего по одному сегменту.


к своему стыду незнал этого момента применительно к FB

Dimitr,
интересно, а в 2.5 и 3й версии применительно к индексам и в контексте этой статьи что изменилось? статья 2006 года, и в ней есть упоминание что разработчики сейчас обсуждают возможность изменения или корректировки ошибок оптимизатора в будующих версиях. Эту бы статью переработать с учетом новых версий, а Dimitr? По сути это основополагающая информация при оптимизации производительности и планировании базы. По мне так эту статью надо бы целиком в русскую доку запихать. Тем более что она уже переведена. На аглицкий, думаю, тоже не проблема перевести.
...
Рейтинг: 0 / 0
09.09.2015, 13:12
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046891
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Mikhail Tchervonenkoк своему стыду незнал этого момента применительно к FB
а в каких СУБД это не так?

Mikhail Tchervonenkoинтересно, а в 2.5 и 3й версии применительно к индексам и в контексте этой статьи что изменилось? статья 2006 года, и в ней есть упоминание что разработчики сейчас обсуждают возможность изменения или корректировки ошибок оптимизатора в будующих версиях. Эту бы статью переработать с учетом новых версий, а Dimitr?
в статье и ошибки есть, и ложные упоминания того что хотели фиксить но не фиксили, ну и в 3-ке тоже кое-что поменялось. Собираюсь переписывать на зимних каникулах.
...
Рейтинг: 0 / 0
09.09.2015, 13:17
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046927
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Mikhail Tchervonenko,

Хочу заметить, что хотя изменения и есть, но всё же "работа оптимизатора" и "способы доступа к данным" это разные области.
Работа оптимизатора в том, чтобы наиболее эффективно подобрать способ доступа к данным, но никак не изменяет сами способы или их количество.
...
Рейтинг: 0 / 0
09.09.2015, 13:39
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046940
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
WildSery,

ну в трёшке появился способ соединения потоков HASH JOIN. В той статье он описан очень кратенько, потому как в FB его всё равно не было. Так что количество именно реализованных методов доступа всё же поменялось.
...
Рейтинг: 0 / 0
09.09.2015, 13:46
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046944
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов Дениспочему в GROUP BY record length и key length стали больше чем в DISTINCT?
key length больше, т.к. группировке надо учитывать нуллы (агрегаты их игнорируют)
record length больше, т.к. скорее всего включаются еще и dbkey + txnid (для ORDER BY они точно нужны, для GROUP BY может и нет - надо подумать)
...
Рейтинг: 0 / 0
09.09.2015, 13:47
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39046971
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
WildSery,

кстати есть там один новый метод доступа совсем не описанный. Он возникает при работе с оконными функциями.
...
Рейтинг: 0 / 0
09.09.2015, 14:01
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39047155
Фотография Mikhail Tchervonenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikhail Tchervonenko
Участник
Симонов ДенисWildSery,

ну в трёшке появился способ соединения потоков HASH JOIN. В той статье он описан очень кратенько, потому как в FB его всё равно не было. Так что количество именно реализованных методов доступа всё же поменялось.

а можно поподробнее про hash join?
яв доке по тройке на тему HASH только это нашел

докаДля соединения методом HASH в плане вместо директивы JOIN используется
директива HASH. В этом случае меньший (ведомый) поток целиком вычитывается
во внутренний буфер. В процессе чтения к каждому ключу связи применяется хеш-
функция и пара {хеш, указатель в буфере} записывается в хеш-таблицу. После чего
читается ведущий поток и его ключ связи опробируется в хеш-таблице.

Код: plsql
1.
2.
3.
4.
SELECT *
FROM students s
JOIN classes c ON c.cookie = s.cookie
PLAN HASH (c NATURAL, s NATURAL)


и текста весьма скупо, в каких случаях этот метод соединения оправдан?
...
Рейтинг: 0 / 0
09.09.2015, 16:05
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39047167
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Mikhail Tchervonenko,

в текущих бета-версиях он применяется вместо sort/merge join. К релизу будет выбираться либо hash, либо sort/merge - в зависимости от оценок. В следующей версии хеширование будет применяться к промежуточным цепочкам многоэтажных джойнов.
...
Рейтинг: 0 / 0
09.09.2015, 16:13
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39047171
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
а оправдан (в текущем коде, по крайней мере) как минимум когда нет индексов или нельзя их использовать (джойн по выражению)
...
Рейтинг: 0 / 0
09.09.2015, 16:15
| Ответить | Цитировать | Написать  
Правильное тестирование запросов
    #39047183
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Mikhail Tchervonenko,

Оправдано когда не возможно применить индекс. Иногда имеет смысл провоцировать явно.

В тройке HASH JOIN практически подменил MERGE JOIN. Используется ровно в тех же случаях. В большинстве случаев HASH JOIN дешевле MERGE JOIN за счёт отсутствия необходимости сортировки обоих потоков. Но есть исключения. Сейчас по факту в трёшке MERGE JOIN отключен вовсе. К релизу это может изменится.

Документация по языку SQL не обязана описывать методы доступа. HASH/MERGE JOIN там частично затронуты лишь потому что такие конструкции существуют в кляузе PLAN которая является частью оператора SELECT.
...
Рейтинг: 0 / 0
09.09.2015, 16:19
| Ответить | Цитировать | Написать  
25 сообщений из 26, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Правильное тестирование запросов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39046642&tid=1562633]:
 0ms
get settings:
 11ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 48ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 61ms
get tp. blocked users:
 2ms
others: 270ms
total:  431ms
созд. / загр.: 431ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]