Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Как правильно правильно реализовать логику. Есть документы. Номер документа увеличивается в зависимости от номера склада. У каждого склада своя нумерация документов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2018, 13:37 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Как правильнее использовать триггер, скалярную функцию или что то другое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2018, 14:30 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
или хранимую процедуру ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2018, 14:35 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
ВаселинаНомер документа увеличивается в зависимости от номера склада. У номера документа есть префикс, зависящий от номера склада? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2018, 11:31 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iap https://social.technet.microsoft.com/wiki/ru-ru/contents/articles/10056.microsoft-sql-server.aspx пи#дец, простите... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 00:44 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_iap https://social.technet.microsoft.com/wiki/ru-ru/contents/articles/10056.microsoft-sql-server.aspx пи#дец, простите... Это восхищение или критика? :-) Это экстремально лучший вариант, подходит, если при высоких требованиях к производительности и функциональности. Он при этом в общем простой и лаконичный, просто в статье разнесено на несколько частей, из за этого кажется большим. Единственный минус - используется CLR. Конечно, если у ТС 10 пользователей, можно просто сделать таблицу счётчиков, и в процедуре или триггере присваивать новый номер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 08:56 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_iap https://social.technet.microsoft.com/wiki/ru-ru/contents/articles/10056.microsoft-sql-server.aspx пи#дец, простите... В многопользовательской среде вообще всё непросто... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 10:24 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
можно просто сделать таблицу счётчиков, и в процедуре или триггере присваивать новый номер. Именно сделать таблицу счетчиков и в ТРИГГЕРЕ присваивать новый номер ПРИ СОЗДАНИИ НОВОГО ДОКУМЕНТА. Я этот метод использую почти 20 лет и никаких проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 11:17 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7i можно просто сделать таблицу счётчиков, и в процедуре или триггере присваивать новый номер. Именно сделать таблицу счетчиков и в ТРИГГЕРЕ присваивать новый номер ПРИ СОЗДАНИИ НОВОГО ДОКУМЕНТА. Я этот метод использую почти 20 лет и никаких проблем. ох эти романтики... 20 лет ничему их жизнь не учит ps капс это важность ваше подчёркивает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 11:25 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7i можно просто сделать таблицу счётчиков, и в процедуре или триггере присваивать новый номер. Именно сделать таблицу счетчиков и в ТРИГГЕРЕ присваивать новый номер ПРИ СОЗДАНИИ НОВОГО ДОКУМЕНТА. Я этот метод использую почти 20 лет и никаких проблем.Я тоже. Но при этом я прекрасно понимаю, что это говнокод. Потому что полюбому надо SELECTом получить текущий номер из таблицы, потом UPDATEом его изменить, да ещё в другую таблицу вставить. Если не блокировать таблицы в монопольном режиме доступа, то рано или поздно возникнут накладки в нумерации. Особенно если пользователей несколько сотен или тысяч. В то же время такой уровень изоляции транзакции приведёт к катастрафическому падению производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 11:25 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapЕсли не блокировать таблицы в монопольном режиме доступа, то рано или поздно возникнут накладки в нумерации.Таблицы-то зачем? Достаточно строку в таблице, хранящей счетчики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 11:56 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
 PS Мне всегда хватало identity PPS Для всего остального я мутил свои счётчики ... наверное я хреновый проектировщик ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:03 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_, identity не прикрутишь для разнородных номеров ака "Номер документа увеличивается в зависимости от номера склада" а так да, таблица со складами, масками и последним значением, при добавление блокировать вычитку строки счётчика и увеличивать при успешном окончании или просто увеличивать и забить на стабильный +1(чаще всего требование ничем не аргументируется кроме как "хочу и всё тут") Из радостей - блокировка строки счётчика до окончания вставки вашего документа, или если отказаться от +1 то только на момент генерации номера, а всавилось или нет дело не обяхательное ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:12 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
TaPaKSIMPLicity_, identity не прикрутишь для разнородных номеров ака "Номер документа увеличивается в зависимости от номера склада" а так да, таблица со складами, масками и последним значением, при добавление блокировать вычитку строки счётчика и увеличивать при успешном окончании или просто увеличивать и забить на стабильный +1(чаще всего требование ничем не аргументируется кроме как "хочу и всё тут") Из радостей - блокировка строки счётчика до окончания вставки вашего документа, или если отказаться от +1 то только на момент генерации номера, а всавилось или нет дело не обязательное Да, наверное. ... и вариант invm (с отдельной таблицей) мне нравится больше... в силу снижения нагрузок. Особенно при распределённых системах. Может быть, для этих случаев сиквенсы - "луч добра", но... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:20 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_TaPaKSIMPLicity_, identity не прикрутишь для разнородных номеров ака "Номер документа увеличивается в зависимости от номера склада" а так да, таблица со складами, масками и последним значением, при добавление блокировать вычитку строки счётчика и увеличивать при успешном окончании или просто увеличивать и забить на стабильный +1(чаще всего требование ничем не аргументируется кроме как "хочу и всё тут") Из радостей - блокировка строки счётчика до окончания вставки вашего документа, или если отказаться от +1 то только на момент генерации номера, а всавилось или нет дело не обязательное Да, наверное. ... и вариант invm (с отдельной таблицей) мне нравится больше... в силу снижения нагрузок. Особенно при распределённых системах. Может быть, для этих случаев сиквенсы - "луч добра", но... ну в общем это и есть вариант с отдельной таблицей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:22 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Васелинаили хранимую процедуру Возвращаясь к теме. Если добавление идёт через единственную хранимую процедуру,- то лучше (на мой взгляд) логику в ней реализовать. И избегать вставок "кроме как через неё". Если добавляется абы как (где-то документы добавляются хранимкой, а где-то запросом от клиентского приложения) , - то будет лучше триггером. Это плохая практика, но сработает. Жизнь можно облегчить грамотно сформировав индекс. Я бы, наверное, построил НЕкластерный индекс по склад - номер. Кластерный (такой же) был бы идеален, но на больших данных частых вставках, подозреваю, он будет слишком часто обновляться; а в том как работает механизм перестроения кластерного индекса я не сильно разбираюсь ... Если я где-то не прав (по теме топика) - поправьте.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:30 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_, авторЖизнь можно облегчить грамотно сформировав индекс. Я бы, наверное, построил НЕкластерный индекс по склад - номер. Кластерный (такой же) был бы идеален, но на больших данных частых вставках, подозреваю, он будет слишком часто обновляться; а в том как работает механизм перестроения кластерного индекса я не сильно разбираюсь ... наша песня хороша, начинай сначала ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:33 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7iЯ этот метод использую почти 20 лет и никаких проблем.Первое же нагруженное приложение - и проблемы будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 13:43 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Я бы, наверное, построил НЕкластерный индекс по склад - номер. Кластерный (такой же) был бы идеален, но на больших данных частых вставках, подозреваю, он будет слишком часто обновляться; а в том как работает механизм перестроения кластерного индекса я не сильно разбираюсь ... А как работает "механизм перестроения НЕкластерного индекса" вы разбираетесь? НЕкластерный не нужно обновлять? А после обновления НЕкластерного не нужно обновлять кластерный/кучу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 13:54 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Попроектирую и я тоже... 1. Идентити - как главный номер и суррогатный ключ. 2. Строковое поле, куда можно вводить любой номер. Можно генерировать автоматом в процедуре (типа, нет номера - генерируем, причем совсем не обязательно в момент ввода документа - можно постобработкой) или вводить/менять ручками - как ужо сделаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:18 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
ВаселинаКак правильнее использовать триггер, скалярную функцию или что то другое? Правильнее всего использовать бумажный "журнал регистрации документов", который и будет выполнять задачу сериализации при генерации номеров. На каждом складе - свой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:27 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Если добавление идёт через единственную хранимую процедуру,- то лучше (на мой взгляд) логику в ней реализовать. И избегать вставок "кроме как через неё".Кто мешает запустить процедуру одновременно в десяти коннектах?invmiapЕсли не блокировать таблицы в монопольном режиме доступа, то рано или поздно возникнут накладки в нумерации.Таблицы-то зачем? Достаточно строку в таблице, хранящей счетчики.Какая разница, если в любом случае речь об общем ресурсе, к которому необходимо организовать последовательный доступ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:52 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapКакая разница, если в любом случае речь об общем ресурсе, к которому необходимо организовать последовательный доступ?Разница большая, - потому что общий ресурс не таблица, а строка этой таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:01 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
invmiapКакая разница, если в любом случае речь об общем ресурсе, к которому необходимо организовать последовательный доступ?Разница большая, - потому что общий ресурс не таблица, а строка этой таблицы.Всё равно же надо ждать, пока он освободится! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:05 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
Ну, не знаю, как в высоконагруженных системах, но при числе соединений до 100 и при выдаче 100-300 документов за день, никаких видимых задержек при формировании номера документа из таблицы счетчиков+триггер не наблюдалось на протяжении много лет эксплуатации. И вроде бы ТС ничего не указывал на высоконагруженную систему, а тут сразу начали выдумывать термоядерные движки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:26 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7i, автор100-300 документов за день это без проблем ведётся в толстой тетрадке с учётом переноса её между складами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:30 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapВсё равно же надо ждать, пока он освободится!Надо. Только зачем выстраивать одну большую очередь, когда ее можно разбить на несколько меньших? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:46 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
d7iНу, не знаю, как в высоконагруженных системах, но при числе соединений до 100 и при выдаче 100-300 документов за день, никаких видимых задержек при формировании номера документа из таблицы счетчиков+триггер не наблюдалось на протяжении много лет эксплуатации. И вроде бы ТС ничего не указывал на высоконагруженную систему, а тут сразу начали выдумывать термоядерные движки...ТС дали разные варианты, что тут плохого, пусть почитает. Конечно, для создания 100-300 документов за день не нужно делать так сложно, задержек и не может быть. Проблемы будут, когда в среднее время транзакции нужно успеть завести более одного документа. Скажем, если транзакция 100мс, то заводим 10 документов в сек, или 36 000 в час. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 17:45 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
iapinvmпропущено... Разница большая, - потому что общий ресурс не таблица, а строка этой таблицы.Всё равно же надо ждать, пока он освободится! Если для каждого склада будет своя строка номера, то существует некая "параллельность". Дмитрий Короткевич на тему блокировок строк таблицы и их (блокировок) влияния на select по таблице делал сообщение,- лет пять-семь тому назад,- но с тех пор много воды утекло и что-то в механизмах MS SQL Server могло уйти вперёд... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 00:14 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexSIMPLicity_Я бы, наверное, построил НЕкластерный индекс по склад - номер. Кластерный (такой же) был бы идеален, но на больших данных частых вставках, подозреваю, он будет слишком часто обновляться; а в том как работает механизм перестроения кластерного индекса я не сильно разбираюсь ... А как работает "механизм перестроения НЕкластерного индекса" вы разбираетесь? НЕкластерный не нужно обновлять? А после обновления НЕкластерного не нужно обновлять кластерный/кучу? При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. Если есть какая-то другая информация - буду признателен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 00:31 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
[quot SIMPLicity_]msLexпропущено... При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. Если есть какая-то другая информация - буду признателен... Эвона как, а мужики то не знают! Ваш пример будет верен только если табл ввиде кучи и у нее есть хотя бы один не кластерный инд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 01:09 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. А что, в вашем понимании, "перестроения самой таблицы" и что вообще такое "сама таблица"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 11:11 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
[quot Mr. X]SIMPLicity_пропущено... Эвона как, а мужики то не знают! Ваш пример будет верен только если табл ввиде кучи и у нее есть хотя бы один не кластерный инд. Почему именно так? ... Может быть кластерный индекс по времени появления строк в таблице, например (если такое поле предусмотрено). Тогда таблица будет монотонно расти согласно кластерного индекса. Изменения других полей (номер, ....) не будет влиять на него. А некластерные индексы будут перестраиваться согласно изменениям в соответствующих полях.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 01:36 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexSIMPLicity_При обновлении полей НЕкластерного индекса НЕ происходит перестроения самой таблицы. При добавлении/удалении строки - тоже. А что, в вашем понимании , "перестроения самой таблицы" и что вообще такое " сама таблица "? Если отвлечься от того, как данные распределены "физически" по системе хранения (хард, полка, ssd-шник, RAMdrive, виртуальное хранилище, оперативка...) то для таблицы с кластерным индексом - это записи, уложенные друг за дружкой по кластерному индексу. Про columnstore-таблицы не интересовался. Если запись вставляется в середину страницы, то она либо попадает в неё (если есть место), либо страница расщепляется на две и новая запись попадает в одну из них. В случае "кучи": новые записи кидаются в конец "таблицы" и НЕкластерные индексы их ни как не организовывают. Кажется так. По крайней мере, я себе так представляю процесс... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 01:47 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Если отвлечься от того, как данные распределены "физически" по системе хранения (хард, полка, ssd-шник, RAMdrive, виртуальное хранилище, оперативка...) то для таблицы с кластерным индексом - это записи, уложенные друг за дружкой по кластерному индексу. Про columnstore-таблицы не интересовался. Если запись вставляется в середину страницы, то она либо попадает в неё (если есть место), либо страница расщепляется на две и новая запись попадает в одну из них. В случае "кучи": новые записи кидаются в конец "таблицы" и НЕкластерные индексы их ни как не организовывают. Кажется так. По крайней мере, я себе так представляю процесс... Коль 1. В качестве физического уровня вы выбрали "железо" 2. Вы говорите о проблеме расщеплении данных на логическом уровне стоит предположить, что логический уровень хранения, это файлы данных и страниц в них (так же, кстати, логический уровень хранения определяют и разработчики SQL Server-а, когда называют внешнюю фрагментацию данных логической) В этом случае , логически эти данные не обязаны быть "уложены" друг за дружкой и часто могут быть разбросаны как внутри одного файла данных так и по разным файлам Если возвращаться к начальному вопросу кластерный - плохо, потому что будет "перестроение" (как мы выяснили, вы говорили про расщепление станиц данных) , некластерный - хорошо. то главная ваша ошибка в том, что при добавлении новых данных страницы некслатерного индекса так же могут расщепляться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 13:05 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
msLexто главная ваша ошибка в том, что при добавлении новых данных страницы некслатерного индекса так же могут расщепляться Да. Но как правило (даже если мы используем в НЕкластерном индексе включённые поля) , то на страницу умещается значимо больше "записей" некластерного индекса; соответственно и процесс "расщепления" идёт реже. Опять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. А наоборот - нет. Возможно, что это принципиально (т.е. явно заметно с точки зрения потери производительности) только на сильно больших данных. Общий вопрос: "подряд" или "НЕподряд" лежат записи в классической (НЕ column-store) таблице сильно обесценивается внедрением SSD, но остаётся актуальном в силу блочности операций чтения с СХД (СХД в широком смысле слова) . Насколько я понимаю, любая СХД (вне зависимости от реализации на физическом уровне) отдаёт данные сиквелу блоками. И чем компактнее данные лежат в блоках, тем лучше; а порядок расположения блоков в самой СХД в случае RAID уже не сильно принципиален (исключая чередование, зеркалирование и чередование+зеркалирование) . Думаю, что любой SQL|noSQL сервер НЕ умеет получать исключительно определённую запись таблицы с СХД; кроме как в случае, когда запись ложиться ровно в блок ;-) . ! Интересно, как всё происходит в случае сжатых данных .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:45 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_Опять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. А наоборот - нет все с точностью до наоборот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:52 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
SIMPLicity_, авторНо как правило (даже если мы используем в НЕкластерном индексе включённые поля), то на страницу умещается значимо больше "записей" некластерного индекса; с страница 8кб, что такое значимо больше/значимо меньше не ясно как это влияет на расщипление, занято - split авторОбщий вопрос: "подряд" или "НЕподряд" лежат записи в классической (НЕ column-store) таблице сильно обесценивается внедрением SSD, но остаётся актуальном в силу блочности операций чтения с СХД (СХД в широком смысле слова). Насколько я понимаю, любая СХД (вне зависимости от реализации на физическом уровне) отдаёт данные сиквелу блоками. И чем компактнее данные лежат в блоках, тем лучше; а порядок расположения блоков в самой СХД в случае RAID уже не сильно принципиален (исключая чередование, зеркалирование и чередование+зеркалирование). Думаю, что любой SQL|noSQL сервер НЕ умеет получать исключительно определённую запись таблицы с СХД; кроме как в случае, когда запись ложиться ровно в блок ;-) . тут как то вообще не ясно о чём. Читает минимум экстентом и опять логическая и физическая фрагментация это вообще разные вещи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:54 |
|
||
|
Нумерация документов
|
|||
|---|---|---|---|
|
#18+
авторОпять-таки, перестроение КЛАСТЕРНОГО индекса влечёт за собой корректировку всех НЕкластерных индексов. Нет. зачем? авторА наоборот - нет ну тут фиг поспоришь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 15:57 |
|
||
|
|
start [/forum/search_topic.php?author=Nick3698&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 684ms |
| total: | 856ms |
| 0 / 0 |
