Гость
Войти | Профиль | Очистить
Map
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Производительность и количество FK в таблице / 25 сообщений из 43, страница 1 из 2
  1  все
09.02.2022, 18:57
    #40132904
Док
Док
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :)

Есть несколько таблиц-справочников
Код: sql
1.
2.
3.
TBL_PEOPLE (пациенты и работники ЛПУ)
TBL_REASON_VISIT (причина визита в ЛПУ)
TBL_JOB_POSITION (должности работников) ---> является detail для --->TBL_JOB_TITLE (список специальностей персонала)


и др.

и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE TBL_VISITMAIN (
    ID                    INTEGER NOT NULL,
    FK_PEOPLE             INTEGER NOT NULL,
    FK_OFFICE_CLINIC      INTEGER NOT NULL,
    FK_JOB_POSITION       INTEGER NOT NULL,
    FK_REASON_VISIT       INTEGER NOT NULL,
    DATEVISIT             DMN_DATETIME NOT NULL,
    <skiped>
);



Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT
  VM.DATEVISIT,
  JT.NAME ||' '||PM.LAST_NAME AS DOCTOR,
  'пациент '|| PV.LAST_NAME AS PATIENT
FROM TBL_PEOPLE PV
   INNER JOIN TBL_VISITMAIN VM ON (PV.ID = VM.FK_PEOPLE)
   INNER JOIN TBL_REASON_VISIT RV ON (VM.FK_REASON_VISIT = RV.ID)
   INNER JOIN TBL_JOB_POSITION JP ON (VM.FK_JOB_POSITION = JP.ID)
   INNER JOIN TBL_PEOPLE PM ON (JP.FK_PEOPLE = PM.ID)
   INNER JOIN TBL_JOB_TITLE JT ON (JP.FK_JOB_TITLE = JT.ID)
WHERE (PV.ID = :prmID)



Причем, справочники могут быть с блобами.

1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
=================
Док.
Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey):
FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2022, 22:42
    #40132960
DmSer
DmSer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Док,

выскажу чисто своё мнение.

1. Вовсе не обязательно поля-ссылки на другие таблицы оформлять как FK. Для начала можно оформить как простое поле, например REASON_VISIT_ID. Далее, если выяснится, что по нему требуется поиск, то можно добавить индекс. FK - это сущность опциональная. Если назвать поле REASON_VISIT_ID, то глядя на его название сразу понятно, куда оно ссылается и лишних FK-индексов городить не требуется. В MySQL лет десять не было никаких FK и все прекрасно жили.

2. Вместо того, чтобы городить ненужные FK-индексы в таблице транзакций, гораздо больше пользы реализовать составные индексы, например (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов.

2. Запрос к куче таблиц через INNER JOIN - это лохотрон.
Куда надёжнее строить запрос самостоятельно, начиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2022, 23:02
    #40132964
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
DmSerнапример (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов.
лабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам.
Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу.
DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).
опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.
Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2022, 23:28
    #40132968
DmSer
DmSer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
kdvлабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам.
Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу.

Вероятно, что это и требуется - найти по конкретному врачу (или группе врачей) либо по конкретному пациенту (или группе пациентов).

kdvопять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.

Намучался я в своё время с этими inner join. Постоянно у пользователей были проблемы с производительностью (в первую очередь из-за неактуальной статистики). В конце концов переделал все запросы на left join. Не помню ни одного случая, где бы left join (вместо inner join) не подошёл.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 06:27
    #40132996
fraks
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
kdv

DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).

опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.

Ну, во первых, именно тут именно inner - НЕ НУЖЕН. Тут как раз outer по смыслу подходит.
А во вторых, раз уж у нас такая ситуация когда мы пошли по ссылке, на которой не навешан FK, то и ссылка может привести к тыкву. И при inner у нас тогда и мастер-запись пропадет.
kdv

Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза.

Несколько раз напоровшись на ситуацию когда сервер при росте базы пытается "сделать мне лучше" и меняет план на совсем херовый я этих inner боюсь как огня. И всегда когда к данным цепляю справочники, делаю это по outer.
Бывают конечно исключения, но они - исключения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 06:29
    #40132997
fraks
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
И я всегда объявляю в базе FK, это неоднократно спасало от кривых данных или удаления записей с зависимостями.
Да, это не совсем бесплатно, но в половине случаев индекс нужен, а в остальных случаях - не так оно и мешает.
Зато самодокументированность и корректность данных.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 06:32
    #40132998
fraks
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
В моей микровселенной:
У справочников всегда есть первичный ключ с именем ID.
Поля-ссылки начинаются с ID_ и далее идет имя таблицы или некоторые другие исторически сложившиеся называния.

Код: plsql
1.
2.
3.
ID
ID_POST
ID_SKLAD
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 09:43
    #40133020
pastor
pastor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Док
Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :)

Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
...
1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
=================
Док.
Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey):
FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk)


всегда так делаю.
иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться

из камней - иногда приходится добавлять нолики, т.к. план может внезапно измениться
INNER JOIN TBL_PEOPLE PM ON (JP.FK_PEOPLE = PM.ID+0)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 10:05
    #40133029
Док
Док
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Спасибо за мнения. Т.е. пока резюме такое:
* Поменять inner на outer
* Добавление FK вместо составных ключей оправдано и оптимальнее всего

Все правильно?

Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали. По ID визита планируется редактирование записи и отправка ее в отчёт
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 10:16
    #40133033
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
ДокПоменять inner на outer

я бы не стал этого делать без острой необходимости.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:07
    #40133054
bsv9
bsv9
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Док,Добавление FK вместо составных ключей оправдано и оптимальнее всего
Не всегда. Я бы, например, очень подумал - добавлять или нет FK на маленький справочник, который не планируется расширять. Например, статус заявки: 1-Активная, 2-Отложена, 3-Удалена.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:09
    #40133055
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Док
Есть несколько таблиц-справочников
Код: sql
1.
2.
TBL_PEOPLE (пациенты и работники ЛПУ)
TBL_REASON_VISIT (причина визита в ЛПУ)

Хоть бы до T_ префикс сократил бы что ли...

Док
Код: sql
1.
TBL_JOB_POSITION (должности работников) ---> является detail для --->TBL_JOB_TITLE (список специальностей персонала)

Это должна быть "периодическая таблица" без требований уникальности к паре POSITION + NAME.

Док
и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д.

Надо объяснять для чего она вообще нужна, и если нужна, то может несколько?
Для хранимых агрегатов нет универсальных правил, увы. В топик призывается Дед.

Док
Код: sql
1.
2.
3.
4.
CREATE TABLE TBL_VISITMAIN (
    ID                    INTEGER NOT NULL,
    PEOPLE             INTEGER NOT NULL,
    FK_OFFICE_CLINIC      INTEGER NOT NULL,



2. Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы.
3. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
4. Причем, справочники могут быть с блобами.

1. ID_ лучше, чем FK_. Хотя это дело вкуса, конечно (если проект на одного - то пофиг).
2. Таблица c десятками внешних ключей должна автоматически вызывать подозрение.
Есть исключения - например, таблица, которая напарсила (или ещё откуда-то извлекла) всякое
безобразие, которое "плоское" и плохо раскладывается в несколько таблиц (разве что в ширину).
3. Нормальная конструкция. Если, конечно, на каждый чих делать не все 30 джойнов, а только нужные.
4. Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.

Док

1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
1. Вопрос неконкретен. См. выше про хранимые агрегаты.
2. Совпадающие поля в таблицах. Хотя ФБ вроде на них ругается с какой-то версии.
Мелочь, а неприятно. Впрочем, если соблюдать гигиену вегда использовать префиксы, то жить можно.
3. См. п.1. :) Для начала я бы не агрегировал всё подряд и добавил только те FK, которые
реально нужны. Авось и не понадобятся 30 ссылок. Во-вторых, сложность и громоздкость
резко увеличатся, если/когда у тебя вместо одной такой таблицы появится две - например,
TBL_AGG и TBL_AGG_DETAILS (потому что даты или несколько записей или просто потому что).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:15
    #40133059
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Док
* Добавление FK вместо составных ключей оправдано и оптимальнее всего
Да. Про "маленькие" справочники правильно подсказывают, хотя целостность данных может быть важнее.

Док
Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали.
Они у тебя как-то вшиты или формируются "построителем"/пользователем?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:16
    #40133061
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
pastor
иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться
Тут не понял. Можно подробнее?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:24
    #40133063
pastor
pastor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Гаджимурадов Рустам
pastor
иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться
Тут не понял. Можно подробнее?


Была в прайсе корова рыжая одна. Например, "Каток"
а потом стало "Физкультурно-оздоровительное катание для иных категорий граждан"

В статистике - одно и то же, а в ОФД уже ушло как ушло.

С диагнозами наверняка также. Или хуже. Был кровавый понос, а стало 10 разных категорий по МКБ.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 11:53
    #40133087
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло.

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

> С диагнозами наверняка также. Или хуже.
> Был кровавый понос, а стало 10 разных категорий по МКБ.

ХЗ, я бы делал новую запись,
опционально - со ссылкой на
старую, хоть 10 в цепочку.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 12:16
    #40133099
pastor
pastor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Гаджимурадов Рустам
pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло.

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

> С диагнозами наверняка также. Или хуже.
> Был кровавый понос, а стало 10 разных категорий по МКБ.

ХЗ, я бы делал новую запись,
опционально - со ссылкой на
старую, хоть 10 в цепочку.


может быть полное описание расчета проката или парковки например. или стринлист параметров на момент оформления. да что угодно.

пробовали делать истории, получение актуальной на момент времени и пр. - гемор.
компромисс между простотой пользования и возможностями разбора.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 12:41
    #40133105
ggreggory
ggreggory
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
pastor
Был кровавый понос, а стало 10 разных категорий по МКБ.


Хранение строковых данных в основной таблице раздует её слишком, тормозить будет.

Замените редактирование справочника созданием дубликата со скрытием старого. У новых записей основной таблицы будет новый вариант, у старых останется старый.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 13:26
    #40133123
pastor
pastor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
ggreggory
pastor
Был кровавый понос, а стало 10 разных категорий по МКБ.


Хранение строковых данных в основной таблице раздует её слишком, тормозить будет.

Замените редактирование справочника созданием дубликата со скрытием старого. У новых записей основной таблицы будет новый вариант, у старых останется старый.


а мне не жалко.
я даже логи запросов /ответов http храню. шоп було.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 13:38
    #40133130
Гаджимурадов Рустам
Гаджимурадов Рустам
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
pastor> может быть полное описание расчета проката или парковки например.
pastor> или стринлист параметров на момент оформления. да что угодно.

Ээээ и сколько (по времени и объемам) это всё безобразие хранится?

> пробовали делать истории, получение актуальной на момент времени и пр. - гемор.

Это да, нужно вьюхи/ХП плодить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 13:40
    #40133133
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
ДокТ.е. пока резюме такое:
* Поменять inner на outer
* Добавление FK вместо составных ключей оправдано и оптимальнее всего

Все правильно?

У тебя в запросе условие по полю из справочника. Безмозглое применение п.1 может
привести пушного зверька.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 13:58
    #40133149
pastor
pastor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Гаджимурадов Рустам
pastor> может быть полное описание расчета проката или парковки например.
pastor> или стринлист параметров на момент оформления. да что угодно.

Ээээ и сколько (по времени и объемам) это всё безобразие хранится?

> пробовали делать истории, получение актуальной на момент времени и пр. - гемор.

Это да, нужно вьюхи/ХП плодить.


5 лет минимум.
обычно - лет 10, до 50 гб, но там и фотки и все такое.

логи http - год,
логи действий пользователей, телеметрия - до ближайшего обновления БД
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 15:07
    #40133197
YuRock
YuRock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Гаджимурадов Рустам
Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.

Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же?
Такие сокращения - упыризм чистой воды.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 15:23
    #40133208
Мимопроходящий
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
YuRock
Гаджимурадов Рустам
Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.
Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же?
Такие сокращения - упыризм чистой воды.
так ты поди и OUTER после LEFT пишешь?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2022, 15:34
    #40133217
Ivan_Pisarevsky
Ivan_Pisarevsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Производительность и количество FK в таблице
Мимопроходящий
так ты поди и OUTER после LEFT пишешь?
всегда пишу кляузу "as" при указании алиаса для поля.
И? Я еще "не" или уже "тово"?

Запасаться попкорном или уже пора закрывать?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Производительность и количество FK в таблице / 25 сообщений из 43, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 2188ms
Закрыть
Start [/forum/topic.php?fid=40&mobile=1&tid=1559828]:
 0ms
get settings:
 127ms
get forum list:
 7ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 167ms
get topic data:
 6ms
get forum data:
 1ms
get page messages:
 1707ms
get tp. blocked users:
 1ms
others: 168ms
total:  2188ms
x
x
Закрыть


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