|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов Денисох уж эти сравнения. Ну раз такой оффтоп: Вообще хорошего теста не хватает. Я лично для себя гоняю периодически тесты MSSQL vs FB vs Pg. По факту массовые заливки в Pg быстрее. На дефолтных настройках. В FB подкручена память сортировки и кеш. Время создания толстых индексов сравнимое (3 поля и более, записей 100К .. 1M). А вот интересное начинается если Update начать гонять при наличии уже построенных индексов. Вот тут FB часто начинает обгонять. Причём раза в два, если правильно помню. Начинаем мучать Pg: нелогируемая таблица, заполнение страниц уменьшаем. Начинает ускоряться, но всё равно FB по дефолту резвее бегает. К сожалению я не спец в Pg и не могу адекватно его тюнить. Так что нужен спец, крайне желательно из обоих миров. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2016, 17:38 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов Денисох уж эти сравнения.чем богаты... Если все параметры конфига в дефолте, то тест сразу на свалку.на свалку... Попробуй на 3.0лениво... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2016, 17:45 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
PolesovЕсли все параметры конфига в дефолте, то тест сразу на свалку.на свалку... параметра по умолчанию в FB откровенно говоря отстой рассчитаны на совсем маленькие БД. Правда говорят что в PG тоже. Но какие выставлены лучше хз Ты кстати не сказал в какой архитектуре пробовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2016, 17:51 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов ДенисТы кстати не сказал в какой архитектуре пробовал. Ooops... classic server ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2016, 18:28 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Не, Классик и 2.5 оригинально конечно использовать, но все таки лучше взять 3.0 SuperServer с конфигом с http://ib-aid.com/en/optimized-firebird-configuration/ ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2016, 00:27 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Polesov, По условию задачи разве не update построчно с коммитом транзакции потом? На том железе где тестил update одним запросом был бы в несколько секунд. Я тестировал именно на то как поведёт себя оракл, при издевательствах над индексами. 6 миллионов потому что где-то в другом месте запомнилась эта цифра ( в Пятнице вроде) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2016, 10:55 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Если все параметры конфига в дефолте, то тест сразу на свалку. сразу видно болтуна ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2016, 12:15 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Не пинать. Всесторонние тесты нужны только для ориентира. И выявления узких мест. Желательно делать это на одинаковом железе. У нас сейчас будет не очень объективная картина, но есть моменты которые меня интересуют. Объясняю почему. Когда то моя база создавалась за 30 секунд и потом произошло резкое увеличение времени создания. Сейчас создание на SSD 50 секунд. Мне было лень тогда искать причину этого, ведь у клиентов тормозов не наблюдалось. Теперь поздно. Как только перехожу на новую версию старую не использую вообще. Firebird-3.0.1.32510-0_Win32 Но пришлось сделать и для Fb 2.5.6.26979 т.к. результат сильно отличался Polesov SSD чтение и запись 41Мбайт/сек было в "Монитор ресурсом" База распухла в обоих вариантах с 1700Мб до 16Гб с индексом до 20Гб Тройка отстает от 2.5, но надо понимать в 3-ке упор на множественные подключения и это плата за быстродействие в 1-ом коннекте. Об этом наверно и разработчики скажут. Интересно при создании базы у меня 1.5 раза создалось быстрей чем у Polesov. НО по выборкам расхождения жуткие с Polesov. У меня зекало у Polesov наверно последовательный РАЙД. update быстрый. Polesov Заполнение таблицы FB - 19 мин 19 сек Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Fb 3.0.1.32510 Время подготовки "00:00:00.003", выполнения "00:12:37.943" Plan: MaxMemory: 383611736, CurrentMemory: 329672320, NumBuffers: 38192 Cache fetches 311564521, reads from disk 16, writes to disk 1854011 "RDB$PAGES" backout 0, delete 0, expunge 0, insert 1156, purge 0, read_idx 0, read_seq 0, update 0 "TEST" backout 0, delete 0, expunge 0, insert 100000000, purge 0, read_idx 0, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.003", выполнения "00:12:14.375" Plan: MaxMemory: 372039676, CurrentMemory: 323576656, NumBuffers: 38192 Cache fetches 315100295, reads from disk 0, writes to disk 1851609 "RDB$PAGES" backout 0, delete 0, expunge 0, insert 982, purge 0, read_idx 0, read_seq 0, update 0 "TEST" backout 0, delete 0, expunge 0, insert 100000000, purge 0, read_idx 0, read_seq 0, update 0 Так сравнил разницу между системами. 19*60+19=1159 12*60+37=757 1159/757=~1.5 раза мой комп выполнил это быстрей. НО это может зависит от настроек конфига которые просили в студию У меня они такие Код: sql 1. 2. 3. 4. 5. 6.
PG - 8 мин 12 сек Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Создание индекса Код: plsql 1. 2. 3. 4. 5.
Fb 3.0.1.32510 4:25 соотношение времени 1.5 раза тут все в порядке Fb 2.5.6.26979 4:55 Несколько селектов Код: plsql 1. 2. 3. 4. 5.
Fb 3.0.1.32510 Время подготовки "00:00:00.237", выполнения "00:00:13.400" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 538290632, CurrentMemory: 334019936, NumBuffers: 38192 Cache fetches 20048822, reads from disk 237598, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000007, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.154", выполнения "00:00:10.548" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 328532544, NumBuffers: 38192 Cache fetches 20048822, reads from disk 237581, writes to disk 5 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000007, read_seq 0, update 0 Код: plsql 1. 2. 3. 4. 5.
Fb 3.0.1.32510 Время подготовки "00:00:00.003", выполнения "00:00:10.939" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 538290632, CurrentMemory: 334019376, NumBuffers: 38192 Cache fetches 20051087, reads from disk 239821, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.007", выполнения "00:00:09.480" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 328532560, NumBuffers: 38192 Cache fetches 20051087, reads from disk 239804, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 0 Код: plsql 1. 2. 3. 4. 5.
Fb 3.0.1.32510 Время подготовки "00:00:00.004", выполнения "00:00:01.085" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 538290632, CurrentMemory: 329164048, NumBuffers: 38192 Cache fetches 2005107, reads from disk 23988, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1000000, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.009", выполнения "00:00:00.988" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 324170568, NumBuffers: 38192 Cache fetches 2005107, reads from disk 23975, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1000000, read_seq 0, update 0 order by + полный фетч Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Fb 3.0.1.32510 Время подготовки "00:00:00.009", выполнения "00:00:43.030" Plan:PLAN (TEST ORDER PK_TEST) MaxMemory: 538290632, CurrentMemory: 339424296, NumBuffers: 38192 Cache fetches 60102650, reads from disk 477266, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000996, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.005", выполнения "00:00:44.069" Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 381843796, NumBuffers: 38192 Cache fetches 60607742, reads from disk 985030, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000088, read_seq 0, update 0 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Fb 3.0.1.32510 Время подготовки "00:00:00.005", выполнения "00:00:54.328" Plan:PLAN (TEST ORDER PK_TEST) MaxMemory: 538290632, CurrentMemory: 339424312, NumBuffers: 38192 Cache fetches 60105041, reads from disk 479659, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000997, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.008", выполнения "00:00:45.121" Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 367308440, NumBuffers: 38192 Cache fetches 60459460, reads from disk 836750, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000089, read_seq 0, update 0 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Fb 3.0.1.32510 Время подготовки "00:00:00.004", выполнения "00:00:54.452" Plan:PLAN (TEST ORDER PK_TEST) MaxMemory: 538290632, CurrentMemory: 339424312, NumBuffers: 38192 Cache fetches 60105041, reads from disk 479659, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000997, read_seq 0, update 0 Fb 2.5.6.26979 Время подготовки "00:00:00.009", выполнения "00:00:43.058" Plan:PLAN (TEST ORDER PK_TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 343564628, NumBuffers: 38192 Cache fetches 60209460, reads from disk 586750, writes to disk 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 20000089, read_seq 0, update 0 Непонятно, почему для PG такой разброс: 3.53 - 32.14 - 13.76 Вообще ничего не понимаю. Чувствую надо будет для FB2 тест проверить. update Код: plsql 1. 2. 3. 4. 5.
Fb 3.0.1.32510 Время подготовки "00:00:00.007", выполнения "00:02:10.892" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 538290632, CurrentMemory: 336000864, NumBuffers: 38192 Cache fetches 136096383, reads from disk 241012, writes to disk 241523 "RDB$PAGES" backout 0, delete 0, expunge 0, insert 55, purge 0, read_idx 0, read_seq 0, update 0 "RDB$RELATION_CONSTRAINTS" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 0, read_seq 1410, update 0 "RDB$INDICES" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 1640, read_seq 1696, update 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 10000000 Fb 2.5.6.26979 Время подготовки "00:00:00.008", выполнения "00:01:53.063" Plan:PLAN (TEST INDEX (PK_TEST)) MaxMemory: 533370408, CurrentMemory: 329754040, NumBuffers: 38192 Cache fetches 150208860, reads from disk 239826, writes to disk 241484 "RDB$PAGES" backout 0, delete 0, expunge 0, insert 47, purge 0, read_idx 0, read_seq 0, update 0 "RDB$INDICES" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 2, read_seq 0, update 0 "TEST" backout 0, delete 0, expunge 0, insert 0, purge 0, read_idx 10000031, read_seq 0, update 10000000 P.S. Компьютер один и тот же, диск один и тот же, оба сервера 32-х битные. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2016, 15:55 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
MaratIskЕсли все параметры конфига в дефолте, то тест сразу на свалку. сразу видно болтуна ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально. А ещё и размер страницы небось 4K был. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2016, 19:31 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Евгений БолтикDefaultDbCachePages = 38192 FileSystemCacheThreshold = 264K GCPolicy = background RemoteAuxPort = 3051 ServerMode = Classic TempDirectories = f:\ на классике такой огромный кеш вреден. Хотя тест тут в один поток идёт, так что никак не сказывается. Какой ещё background на классике? Почему не супер? TempCacheLimit не увеличивал хотя бы до гигабайта? Это должно улучшить время создания индекса и скорость сортировок ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2016, 19:40 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов ДенисMaratIskпропущено... сразу видно болтуна ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально. А ещё и размер страницы небось 4K был. тест должен строиться на дефолтовых параметрах, исходя из того, что разработчик предусмотрел их как оптимальные для типичного применения есть, разумеется, кудесники знающие все закоулки субд, но таковых немного и погоды в массе они не делают ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2016, 05:47 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
MaratIskСимонов Дениспропущено... ага, то есть ты считаешь что 75 страниц кеша и 8M под сортировку это нормально. А ещё и размер страницы небось 4K был. тест должен строиться на дефолтовых параметрах, исходя из того, что разработчик предусмотрел их как оптимальные для типичного применения есть, разумеется, кудесники знающие все закоулки субд, но таковых немного и погоды в массе они не делают Обе предпосылки неверные. А вообще, предлагаю уже заодно делать тест на 256МБ ОЗУ и позвать мускуль с оракулом. «Для себя, чисто поржать»© ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2016, 08:07 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Я очень дико извиняюсь В этом месте всралась ачипятка: Код: plsql 1. 2. 3.
Не 99000001 , а 90000001 - count считался по 10 млн записей Код: plsql 1. 2. 3.
Цифры приведены для 90000001 Код: plsql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2016, 11:24 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
NikolayV81По условию задачи разве не update построчно с коммитом транзакции потом? Ну, смотря что понимать под массовым апдейтом, изначально уточнено не было. Alexey Kovyazinна таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2016, 11:34 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
PolesovNikolayV81По условию задачи разве не update построчно с коммитом транзакции потом? Ну, смотря что понимать под массовым апдейтом, изначально уточнено не было. Alexey Kovyazinна таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов. Если не ошибаюсь где-то проскакивала тема про данное приложение и про макс. размер тела запроса в 3ке да и ещё если посмотреть на мой пример там идёт обновление именно полей входящих в индекс (что собственно для оракла и критично из-за чего в etl и стараются избегать constraint-ов , либо отключают / включают их при заливках ). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2016, 15:14 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
MaratIskтест должен строиться на дефолтовых параметрах давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль. Так что ваш выстрел про "болтуна" на самом деле вам в ногу. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:07 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
NikolayV81если посмотреть на мой пример там идёт обновление именно полей входящих в индексНу, я исходил из того, что менять значения полей, входящих в первичный индекс, как-то не комильфо. А вообще, при такой постановке задачи всяк интерпретирует ее по своему. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:40 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Polesov, не комильфо вообще такой PK делать. Разве что для теста в равных условиях. ИХМО весь хвост топика про тестирование надо бы в отдельную тему оформить ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:43 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
kdvMaratIskтест должен строиться на дефолтовых параметрах давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль. Так что ваш выстрел про "болтуна" на самом деле вам в ногу. ну можно же дефолты в документации к релизу указывать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:54 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
MaratIskkdvпропущено... давно известно, что много дефолтных параметров ФБ идут со времен царя гороха, и уже давно неактуальны. Даже для суперсервера размер кэша в 2000 страниц - это мизерабль. Так что ваш выстрел про "болтуна" на самом деле вам в ногу. ну можно же дефолты в документации к релизу указывать хрен с ним с историческими слоями кода - понимаю, перелопачивать их тоска смертная ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:57 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов ДенисИХМО весь хвост топика про тестирование надо бы в отдельную тему оформить Согласен. И не в "Сравнение СУБД", а оставить тут, потому как там он сгинет. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 11:57 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов Денисне комильфо вообще такой PK делатьНу, таково было условие от Alexey Kovyazin . Симонов ДенисИХМО весь хвост топика про тестирование надо бы в отдельную тему оформитьДа уже нет смысла, кмк (в силу некорректной постановки задачи). Странный разброс по времени выполнения запросов с полным фетчем на PG. Видимо, надо будет в профильной спросить. Удивило, что по результатам тестирования Евгений Болтик FB3.0 был медленнее в селектах, чем 2.5. Он сказал, что тестировал на SSD, у меня же обычный SATA. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 12:02 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
PolesovСимонов Денисне комильфо вообще такой PK делатьНу, таково было условие от Alexey Kovyazin . не уверен в этом. Alexey KovyazinУ кого Оракл под рукой, проверьте пожалуйста на таблице ID, varchar(80), date, varchar(2000), с индексами по ID, varchar(80), date, таблица 100 млн записей (сгенерить надо), пропадейтить 10 миллионов. подозреваю что тут не один общий индекс (PK), а по индексу на каждое поле. И это может в некоторых случаях весьма сильно изменить результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 12:09 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
Симонов ДенисPolesovпропущено... Ну, таково было условие от Alexey Kovyazin . не уверен в этом. Ну, значит я не правильно понял ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 12:11 |
|
Импортозамещение - кто хочет опубликоваться в PCMagazine?
|
|||
---|---|---|---|
#18+
PolesovСтранный разброс по времени выполнения запросов с полным фетчем на PG. само по себе тестирование полного фетча имеет множество нюансов. 1. Полный фетч он ещё учитывает затраты сетевого протокола 2. Вопрос как и где он проводился. Если в IBexpert и pgadmin, то надо учитывать, что там ещё неизвестно сколько вносят компоненты доступа. Плюс в IBE сам грид навороченный, отображение всех записей в нём имеет весьма существенные затраты. PolesovУдивило, что по результатам тестирования Евгений Болтик FB3.0 был медленнее в селектах, чем 2.5. конфиг у Болтика весьма странный. Кэш в FB 3.0 на одном потоке чуть медленней чем в 2.5. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2016, 12:30 |
|
|
start [/forum/topic.php?fid=40&msg=39232217&tid=1562155]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 166ms |
0 / 0 |