ReSQL.ru
     
powered by simpleCommunicator - 2.0.36     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Ускорение работы растущей базы данных Firebird через приложение на Delphi
25 сообщений из 243, страница 3 из 10
  3  все
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113067
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Наталья87
А к чему плохому это может привести?
К тормозам, которые вы пытаетесь избежать. Вам уже ответили Сибиряков и kdv. Это идиотизм - запускать при каждом запуске программы долгую тяжелую операцию.

Наталья87
Ну не буду тогда это делать. Тем более похоже на то, что sweep не очень то и нужен раз все компы и так выключаются раз в сутки.

Он как раз очень нужен. Ведь это единственный вариант собрать мусор для вас (кроме backup-restore, что еще дольше), раз вы программу не можете переделать в пристойное состояние.

Наталья87
Но set statistics index при каждом 10-м запуске программы (чтобы не нервировать пользователей - при каждом запуске не стоит, наверное это делать) ведь не повредит?

Повредит по тем же причинам - бесполезные тормоза.
Статистику чаще всего достаточно считать один раз - после наполнения базы данными.
Либо вообще 0 раз, если создавать индексы после наполнения базы данными (как делает restore, например).
У вас, видимо, ни разу не считалась на той базе, на которой помогло ускорить.
Да, бывают случаи, когда полезно статистику обновить раз в месяц или около того. Накопление данных может изменить статистику и планы. Но это не ваш случай.
Ну и делать это нужно на сервере, опять же, ночью, ведь это тормозит, а у вас этого нет.

Хотите, раз для вас это допустимо (базы у вас, я так понял, крохотные), делайте backup-restore еженедельно, да и всё. Отмечайте в реестре дату последнего успешного, и проверяйте, чтоб это был 7-й день с тех пор.
Запускайте только на компьютере, где база.
Предварительно остановив службу Firebird и переименовав файл базы.
Ну, что ж. Зато не надо swwep запускать и set stat :))
...
Рейтинг: 0 / 0
19.11.2021, 11:43
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113074
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
X11пишущая транзакция - для записи данных и она - максимально короткая.
а потом приходит какой-нибудь чел, лезет ИБЭкспертом в промышленную базу с 500 одновременных пользователей, выполняет там какой-нибудь запрос и бросает ИБЭксперт на пару суток.
И через сутки-двое начинаются вопли "у нас всё тормозит". Если в конторе есть кто-то умный, который знает про mon$ - смотрит и находит негодяя по IP, ИБэксперт отрубают, и дают тому канделябром по башке.
Иногда после этого пишут скрипт, который раз в 1-2 часа отрубает все коннекты, где имя процесса - ibexpert.exe.
Как-то так.
...
Рейтинг: 0 / 0
19.11.2021, 12:04
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113076
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
kdv
Наталья87,

Тут проблема в том, что если
- в однопользовательском варианте вы можете и свип запускать из приложения (не через гфикс), и бэкап делать тоже (не через гбак).
- в многопользовательском приложении запускать гбак или гфикс, или пересчитывать статистику через какие-то интервалы - значит у вас в КАЖДОМ приложении такое возможно, а значит вы будете "долбить" сервер этими задачами, причем только в момент работы пользователей. В многопользовательском случае по любому нужен админ, и настройка бэкапов и свипов именно на сервере.

p.s. так что там с 22397719


Ну у нас "сервер" только в кавычках. Не какая-то там высоконагруженная система, а программка на 1-3 компьютера. Ну максимум 8. Там где больше 3 компьютеров по любому есть какой нибудь админ и наверное автоматические свипы не нужны ...
...
Рейтинг: 0 / 0
19.11.2021, 12:05
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113101
энди
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
энди
Участник
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?
...
Рейтинг: 0 / 0
19.11.2021, 13:25
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113104
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
YuRocksweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 13:33
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113106
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.
...
Рейтинг: 0 / 0
19.11.2021, 13:42
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113107
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
Dimitry Sibiryakov

YuRocksweep interval можно отключить тогда (через gfix установить 0)

Не надо обезьянам давать ЭТУ гранату. Уже были прецеденты - угробит базу.


И правда - да пусть чистится и автоматически тоже. Жалко чтоли.
А как базу можно этим угробить? Разве что тормозить база начнёт.
А угробить базу из практики можно если нет ИБП и мигает свет, либо бэд-блоки на винте, либо очень редко - при сбоях оперативной памяти.
...
Рейтинг: 0 / 0
19.11.2021, 13:45
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113108
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Наталья87А как базу можно этим угробить? Разве что тормозить база начнёт.

Да, именно тормозить начнёт. До такой степени, что разработчика увольняют, а
систему мигрируют на другую СУБД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 13:47
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113109
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
X11
DmSer
Сталкивались с такими проблемами. Знаем. Решается просто: разделяем транзакции для чтения и записи. Для чтения можно использовать длинную транзакцию, она не повлияет на накопление мусора в БД. Для записи используем короткие транзакции, которые запускаем только на момент записи в БД. Мусор в этом случае не копится. База не тормозит.


Зачем дальнейшая дискуссия и танцы з бубном после этого сообщения?

Читающая транзакция должна быть readonly.
При открытии окна добавления/редактирования товара/объекта не открывать ничего на запись. А вот, когда пользователь нажимает сохранить и выполняется Commit, то для этого использовать пишущую транзакцию. т.е. пишущая транзакция - для записи данных и она - максимально короткая.

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


Даже не знаю, какие транзакции Delphi использует при работе с TIBTransaction, TIBQuery. Судя по всему - по умолчанию транзакции вида Snapshot. Вполне возможно, что пишущие используются для чтения. Вот только я после чтения их всё равно освобождаю (Free) - надеюсь, это решает проблему. Free делать приходится - так как иначе утечки памяти очень быстро копятся и потребляют все ресурсы компьютера.
...
Рейтинг: 0 / 0
19.11.2021, 13:48
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113111
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
Dimitry Sibiryakov

Наталья87А как базу можно этим угробить? Разве что тормозить база начнёт.

систему мигрируют на другую СУБД.


Это нереально. Тем более с вашим подходом "переводите по одной форме с IBX на FireDAC как раз до конца жизни за год и успеете. Перевести 400 тысяч строк кода - тем более что там куча быдлокода и говнокода на другую СУБД невозможно, либо оно того не стоит.

Скорее пользователи в этом случае сделают backup&restrore, поставят помощнее комп или в самом крайнем случае начнут с чистой базы данных.
...
Рейтинг: 0 / 0
19.11.2021, 13:51
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113113
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Наталья87Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 13:55
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113115
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
Dimitry Sibiryakov

Наталья87Это нереально.

Целый фейсбук переводили на другую СУБД несколько раз. Думаете, у них меньше
говнокода, чем у вас?..


Но там и бюджеты и масштабы другие. В наших небольших проектах не знаю стоит ли оно того ...
...
Рейтинг: 0 / 0
19.11.2021, 14:09
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113117
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
В ваших небольших бюджетах обычно просто берут 1С.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 14:11
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113124
goldmi45
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goldmi45
Участник
Наталья87
энди
Я правильно понимаю что Вы стартуете транзакцию, а потом вываливаете пользователю диалоговое окно и в это время у вас все еще болтается открытая транзакция?


Да. Но это не часами длится. Обычно не более 1 минуты, а при нормальной работе секунд 10-15. Очень удобно - если произошла ошибка или пользователь нажал "Отменить" - просто делаем Rollback и всё.

Не делайте так никогда. Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся, потом пошёл на обед. И в итоге транзакция может висеть очень долго.
Пишущая транзакция должна быть по времени максимально короткой. Стартовать в момент, когда пользователь нажал "Сохранить".
Дайте угадать, вы используете DBWare-компонеты, типа TDBEdit и поэтому не можете отказаться от старта транзакции перед изменением данных?
...
Рейтинг: 0 / 0
19.11.2021, 14:26
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113127
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
goldmi45Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 14:34
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113133
goldmi45
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goldmi45
Участник
Dimitry Sibiryakov

goldmi45Это вы думаете, что не более 1 минуты, а пользователь, открыв диалог, отвлёкся,
потом пошёл на обед. И в итоге транзакция может висеть очень долго.

Приведённые ею статистики такого не показывают.

Я лишь сказал, что не нужно начинать транзакцию при открытии диалога.
К тому же неизвестно, в какой момент эти статистики были собраны. Может быть, автоматический сборщик мусора запустился и всё колом встало.
...
Рейтинг: 0 / 0
19.11.2021, 14:49
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113140
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
goldmi45Может быть, автоматический сборщик мусора запустился и всё колом встало.

Если запустился автосвип (который часто путают со сборщиком мусора), то это
должно быть отражено в firebird.log. И "колом встало" при его работе это не про
приложение на полтора пользователя, там нужна гораздо более интенсивная нагрузка.

Запуск автосвипа неизбежен после отключения электричества, но я не слышал
упоминаний от аффтарши о "база тормозит после отключения электричества", только
"через некоторое время".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 14:59
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113141
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
goldmi45,

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.
...
Рейтинг: 0 / 0
19.11.2021, 15:01
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113161
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...
...
Рейтинг: 0 / 0
19.11.2021, 16:11
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113186
Наталья87
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наталья87
Гость
ъъъъъ
ТС уже раз пять прямо сказала, что НЕ БУДЕТ переделывать "как правильно", а они все равно скачут перед ней, как самцы павианов перед самкой, "короткие трпнзакции", "сборка мусора"...


Почему же нет? Буду переделывать. Только переделки времени требуют. Особенно если речь про 400 000 строк кода.
И требование писать новый код никто не отменял :(
И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.
Плохо тут то, что данные ошибки не проявляют себя сразу, а потом привыкаешь так писать.

Столько советов, что мозг уже не соображает, за что схватиться. Извините, если туплю :(

Хотя вопрос по сути уже решён, совет с "set statistics index" помог. Да 2 гигабайтной базе много и нее надо наверное ...



kdv
goldmi45,

да всё это теоретизирование. Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб :

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673
...
Рейтинг: 0 / 0
19.11.2021, 17:13
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113192
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
Наталья87

И понять, как не открывать пишущие транзакции для чтения в Delphi тоже.

Двойной клик мышью по объекту TIBTransaction открывает некий диалог, где все это, решив разобраться, можно настроить.
Т.е. в самом минимальном варианте нужны будут два объекта: TIBTransactionReadOnly и TIBTransactionReadWrite.
...
Рейтинг: 0 / 0
19.11.2021, 17:29
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113197
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Наталья87Хотя вопрос по сути уже решён, совет с "set statistics index" помог.

А не должен был по идее.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.11.2021, 17:34
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113199
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
Наталья87


kdv
...Я вот пока не вижу результата select count по самой большой таблице с execute time и page reads.


IBExpert (Execute and Fetch All) показывает так (cтоит сказать, что у меня Intel Core i7 и SSD, а у пользователей Pentium 4 и HDD потому сложно понять их проблемы с тормозами ...):

Исходная база 2 Гб:

------ Performance info ------
Prepare time = 0ms
Execute time = 1s 452ms
Avg fetch time = 0,01 ms
Current memory = 13 053 936
Max memory = 48 897 120
Memory buffers = 2 048
Reads from disk to cache = 3 949
Writes from cache to disk = 4
Fetches from cache = 316 413

После set statistics index Sweep (размер базы остался 2 Гб):

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 472ms
Avg fetch time = 0,01 ms
Current memory = 12 719 024
Max memory = 71 616 052
Memory buffers = 2 048
Reads from disk to cache = 3 950
Writes from cache to disk = 0
Fetches from cache = 316 393

После Backup&Restore (размер бэкапа 47 Мб) база стала вместо 2 Гб - 117 Мб :

И запрос:

------ Performance info ------
Prepare time = 10ms
Execute time = 1s 412ms
Avg fetch time = 0,01 ms
Current memory = 9 146 440
Max memory = 9 365 804
Memory buffers = 2 048
Reads from disk to cache = 4 162
Writes from cache to disk = 4
Fetches from cache = 284 673

Это п....ц.
Соответствие ответа вопросу - меньше, чем у виртуального собеседника уровня ELIZA, 1966г.
...
Рейтинг: 0 / 0
19.11.2021, 17:55
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113224
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Наталья87,

ок, спасибо. Хотя размер страницы из (gstat -h) тоже бы не помешал. Ну да ладно.
Допустим, размер страницы 8к. Хотя, если соотнести с уровнем знаний, то должен быть 4к.
Итого. 4162 страниц размером (допустим) 8к прочитано за 1.4 сек. Это получается 23мб/в секунду.
Для 4к страниц это 11.6мб в секунду.

То есть, база на каком-то ноутбучном диске HDD примерно 10летней давности, не меньше.
Наталья87После set statistics index Sweep (размер базы остался 2 Гб):
ну почему вы считаете что после каких-то операций размер базы должен уменьшиться?
Размер базы НИКОГДА не уменьшается, ни при каких операциях - удаление, свип, реиндексация, и т.д.
Уменьшение файла БД вообще никакой СУБД никогда не делается.
А рестор - это создание новой БД и заполнение ее данными из бэкапа. Весь файл БД строится заново.

Кроме того - ну уменьшилась у вас база в 20 раз. И что? Как было время выполнения запроса 1.4 секунды, так и осталось. Потому что читалось одно и то же (примерно) количество страницы. Результат page reads 4162 относительно 3950 предыдущих, видимо, из-за заполнения кэша (там плюс-минус 2048 страниц кэша).
Fetches меньше? Ну, м.б. чуть поплотнее данные на страницах стали. и всё.
Наталья87cтоит сказать, что у меня Intel Core i7 и SSD
не верю. по цифрам никакого ssd у вас нет.
...
Рейтинг: 0 / 0
19.11.2021, 19:36
| Ответить | Цитировать | Написать  
Ускорение работы растущей базы данных Firebird через приложение на Delphi
    #40113229
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Наталья87,

Для примера. База 26 гиг, tpcc. размер страницы 16к. amd 3700x.
select count(*) from order_line
(если что - результат = 90млн записей)
Execute time = 46s 687ms
Memory buffers = 2 048
Reads from disk to cache = 532 637
Firebird 3 (версия ФБ тут без разницы, т.к. фактически меряется скорость обращения к диску)

вычисляем, получаем ... 178 мегабайт в секунду. На HDD ST200DM01.

Вам надо CrystalDiskMark запустить, посмотреть диск. А то ваш диск на ssd не тянет совершенно, и даже на hdd.

Скопировал базу на ssd (samsung 860 evo, sata3), получил
Execute time = 22s 500ms

То есть, 369 мегабайт в секунду (столько же показывает и диспетчер задач).

p.s. и последнее - fetch All для select count зачем? там 1 запись выводится.
...
Рейтинг: 0 / 0
19.11.2021, 19:55
| Ответить | Цитировать | Написать  
25 сообщений из 243, страница 3 из 10
  3  все
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Ускорение работы растущей базы данных Firebird через приложение на Delphi
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=58&msg=40113117&tid=2036796]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 36ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 70ms
get tp. blocked users:
 1ms
others: 261ms
total:  410ms
созд. / загр.: 410ms
x
x
Закрыть


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