| Flat |
Отправлено: 11 марта 2019 — 17:13 
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
По делам текущим..
Сейчас полностью работаю над оригинальным Exbb.
Сделано:
1) Движок переведён на другой, более читаемый формат файлов. Загрузка файлов стала в 2 раза быстрее;
Пример файла boardstats.php:
CODE:<?php die('Access denied!');?>
return array (
'max_online' => 1,
'max_time' => 1552311233,
'lastreg' => 'admin',
'last_id' => 1,
'totalmembers' => 1,
'totalposts' => 0,
'totalthreads' => 3,
);
2) Все данные: папки members, messages, uploads, forums собраны в в data;
3) Функции exbb_read и exbb_write сделаны атомарными, т. е. убраны из кода функции fclose хэндлов файлов. Раньше это могло привести к неприятным последствиям, так как блокировка файлов и разблокировка были разнесены во времени, а некоторые файлы блокируются, но не разблокируются в коде движка, что может привести к конфликтам процессов.
4) Несколько изменён файл allforums.php. Создан отдельный файл со списком всех категорий. Это привело:
1. Возможность задавать модераторов отдельной категории, возможность задавать права на отдельную категорию, а также делать отдельную категорию приватной.
2. Избавится от бага тасовки категорий и форумов. Теперь там всё прозрачно.
3. Создавать категорию без форумов. Сейчас если удаляем единственный форум в категории удаляется и категория, что неприятно.
4. Сделать номера категорий уникальными, а не зависящими от порядка сортировки.
Сейчас надо полностью переработать работу в файле setforums.php и некоторых других. Короче, буду перелопачивать весь код.(Отредактировано автором: 11 марта 2019 — 17:20) |
| |
|
| 1Bot |
Отправлено: 12 марта 2019 — 20:15
|
Super Member
Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009
Откуда: Днепропетровск
Репутация: 69
|
Flat пишет:По делам текущим..
Сейчас полностью работаю над оригинальным Exbb.
Сделано:
1) Движок переведён на другой, более читаемый формат файлов. Загрузка файлов стала в 2 раза быстрее;
Пример файла boardstats.php:
CODE:<?php die('Access denied!');?>
return array (
'max_online' => 1,
'max_time' => 1552311233,
'lastreg' => 'admin',
'last_id' => 1,
'totalmembers' => 1,
'totalposts' => 0,
'totalthreads' => 3,
);
Вы объединяете код и данные.
Достоинства:
- такой файл будет подключаться быстрее, чем десериализация;
- файл будет кеширован самим php.
Недостатки:
- есть опасность вставки в такие "данные" любого кода, который также может перекрывать любые переменные;
- при неполной записи в такой файл во время его подключения будет фатальная ошибка. |
| |
|
| Flat |
Отправлено: 13 марта 2019 — 02:50
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет: есть опасность вставки в такие "данные" любого кода, который также может перекрывать любые переменные;
Дело в том, что я и подключаю не через include, а через функцию exbb_read(), в которой делаю:
Цитата:return eval($buf);
Всё делается примерно точно также, как и сейчас.
1Bot пишет:- при неполной записи в такой файл во время его подключения будет фатальная ошибка.
Ну, это и сейчас так. В этом случае, предусмотрено, что в основном, запись делается поверх существующего файла с тем же порядком следования элементов. Поэтому, даже при неполной перезаписи ничего не глюканётся, кроме может быть неполной и неверной записи какого-то отдельного поля. Надо стараться, чтобы физически не тасовать элементы массивов без острой на то нужды.
К достоинствам можно добавить и то, что его легко модифицировать " неумелыми админскими ручками" если что случится. А на сериализированные массивы без страха смотреть невозможно. Новый формат ничем не хуже сериализации в плане сохранения структуры, к ому же на порядок читабельнее.
Что касается отдельного файла с категориями, то возможно откажусь от этой идеи и оставлю один файл allforums, но несколько изменённый. Даже так и сделаю. Иначе придётся слишком много всего менять.. Да и так придётся многое изменить: практически новое ядро.
В setforums.php сейчас сделано добавление категорий, форумов и подфорумов(раздельно).
Думаю если постараться вскоре будет бета и возможно к разработке подключатся и другие пользователи.
Часть кода возьму от своих старых наработок, в частности отслеживание посещений пользователями отдельных тем и онлайн подсчёта. Сейчас тут применяется модуль sqlite, а будет силами самого скрипта. Отслеживаться будут последние 100-200 тем(число задаётся в админке), которые пользователь посетил/не посетил. Это всё практичски уже написано для другого движка.
Онлайн подсчёт должен быть более корректным. Вы думаете что тут каждый день по 400-1000 гостей? Это саомобман, достаточно взглянуть на логи посещений. Тут идёт подсчёт каждого действия гостя, хотя он и не уникален, а также не корректно подсчитываются боты.(Отредактировано автором: 13 марта 2019 — 03:04) |
| |
|
| Flat |
Отправлено: 16 марта 2019 — 06:06
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Реализован собственный шаблонизатор. Весь php код из шаблонов убран. Примерно как в PhpBB, но несколько по другому..
Файлов шаблонов станет меньше и они будут более понятными. В редакторе код шаблона прекрасно подсвечивается. Честно говоря я "тащусь" от своего шаблонизатора, - мне он положительно нравится!!! Удивительно, но загрузка главной страницы стала быстрее, видимо потому, что файл шаблона единственный и грузится только 1 раз!
Решил каким образом реализовать проблему деления одной темы на несколько меньших, которая является ахилессовой пятой форумов типа exbb. Проблема эта давняя, но никто так и не приступил к её решению.
После напряжённых раздумий, решил сделать таким образом:
Каждая тема делится на отдельные файлы по 60 сообщений в файле. Число 60 оптимально по нескольким причинам.
Каждый юзер имеет право выбрать не произвольно число сообщений на станицу, а заранее определённое число, которое на цело делится на 60. В профиле он может выбрать такие числа количества сообщений: 1, 2, 3, 4, 5, 6, 10, 15, 20, 30, 60.
В этом случае не придётся качать помимо 60 сообщений ещё 60 сообщений второго файла, если часть сообщений будут лежать в другом файле.
При такой схеме мы получаем:
1. время загрузки темы является постоянной величиной. Поэтому тема может быть сколь угодно большой, и её не нужно делить на отдельные темы, и не будет потерь в скорости загрузки даже при огромных темах.
2. юзеры по прежнему имеют право выбрать определённое число сообщений на одну страницу, хотя и из ограниченного списка.
3. количество файлов тем будет относительно не большим при 60 сообщений на файл даже для огромных форумов.
Почему раньше это не было реализовано?..(Отредактировано автором: 16 марта 2019 — 06:08) |
| |
|
| 1Bot |
Отправлено: 17 марта 2019 — 07:03
|
Super Member
Покинул форум
Сообщений всего: 773
Дата рег-ции: Апр. 2009
Откуда: Днепропетровск
Репутация: 69
|
Flat пишет:Решил каким образом реализовать проблему деления одной темы на несколько меньших, которая является ахилессовой пятой форумов типа exbb. Проблема эта давняя, но никто так и не приступил к её решению.
После напряжённых раздумий, решил сделать таким образом:
Каждая тема делится на отдельные файлы по 60 сообщений в файле. Число 60 оптимально по нескольким причинам.
Каждый юзер имеет право выбрать не произвольно число сообщений на станицу, а заранее определённое число, которое на цело делится на 60. В профиле он может выбрать такие числа количества сообщений: 1, 2, 3, 4, 5, 6, 10, 15, 20, 30, 60.
В этом случае не придётся качать помимо 60 сообщений ещё 60 сообщений второго файла, если часть сообщений будут лежать в другом файле.
При такой схеме мы получаем:
1. время загрузки темы является постоянной величиной. Поэтому тема может быть сколь угодно большой, и её не нужно делить на отдельные темы, и не будет потерь в скорости загрузки даже при огромных темах.
2. юзеры по прежнему имеют право выбрать определённое число сообщений на одну страницу, хотя и из ограниченного списка.
3. количество файлов тем будет относительно не большим при 60 сообщений на файл даже для огромных форумов.
Почему раньше это не было реализовано?..
Хорошая идея!
Дополнительно следует добавить функционал при удалении/переносе в другую тему сообщений по перераспределению сообщений между файлами.
Можно просто делать пометку для сообщения "удален" и из админки или отдельной плановой задачей делать полную перестройку файлов темы, убирая удаленные сообщения. |
| |
|
| Flat |
Отправлено: 17 марта 2019 — 09:24
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет:Дополнительно следует добавить функционал при удалении/переносе в другую тему сообщений по перераспределению сообщений между файлами.
Да, естественно.
1Bot пишет:Можно просто делать пометку для сообщения "удален" и из админки или отдельной плановой задачей делать полную перестройку файлов темы, убирая удаленные сообщения.
Так и сделаем.
Сейчас пока переписываю setforums.php. На RC у меня при определённой логике удаления/добавления/перестройки категорий и форумов посыпался весь allforums.php, после чего мне очень захотелось переделать данный файл.. К тому же иногда при удалении форумов остаются их папки. Кстати первоначальный setforums до переделки Маркусом был относительно правильней организован: там был свитч переключатель на функции, при этом в редакторе можно было легко найти функцию через их список, а сейчас приходится искать вручную, либо через поиск, что очень напрягает. С точки зрения программиста первоначальный вариант был правильнее, чем через ifelse.. Да и переменные не перекрывались..(Отредактировано автором: 17 марта 2019 — 09:31) |
| |
|
| Flat |
Отправлено: 21 марта 2019 — 09:13
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет:Вы объединяете код и данные.
С функцией var_export возникли определённые проблемы. Массив в файле получается довольно большим(больше сериализированного на 50-30%) даже если убрать переводы строк и пробелы, которые эта функция вставляет для отступов, то получим меньший по весу файл, чем сериализированный, однако придётся в текстовых строках пробелы менять на html сущности, что геморрно.
Тут поэкспериментировал пол-дня, над функциями json_encode и json_decode, и получается, что файл занимает в 2-3 раза меньше места на диске, при этом скорость его загрузки возрастает в 2-2,5 раза, причём формат json как буд-то специально предназначен для хранения данных типа массивов и легко читаем. Надо, друзья шагать в ногу со временем, а сейчас, даже Опера использует такой формат, для хранения закладок в текстовом файле!
Пусть эти функции работают только PHP 5 >= 5.2.0, однако кто сейчас сидит на 4 пыхе?
Теперь всё устаканилось. Пока кардинально ничего менять не будем, на это нет времени, а сделаем:
1) новый формат json.
2) неделимые темы.(Отредактировано автором: 21 марта 2019 — 09:14) |
| |
|
| Flat |
Отправлено: 23 марта 2019 — 17:08
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Прикрутил новый формат. Теперь всё работает, загружается быстрее в 2 раза. поверил на файле размером 60 мегабайт. Мой формат загружает его 15 секунд, а сериализированный вообще не загружается, по всей видимости функция сериализации просто не расчитана на такие обьёмы..
По ходу пьесы выявились некоторые концептуальные промахи предыдущих разработчиков. Во-первых номер сообщения в теме это время создания сообщения. Что тут неправильно? Может возникнуть ситуация, когда в течении одной секунды два юзера запостят сообщения в одной и той же теме и получат одинаковый timestamp.. А это значит, что два сообщения получат одинковые номера со всеми вытекающими. Проблема более чем реальна.
Будем решать.
Зачем сохраняем на веки вечные ip юзера в записи сообщения? Ведь ip меняется каждый день. Зачем эту ненужную информацию хранить вечно? Это обычный мусор, одноразовый..
Далее, Номер темы уникален только внутри форума, а не внутри конференции. Это мягко говоря неправильно. Номер темы, как и номер форума, как и номер сообщения должны иметь уникальные для всего форума(конференции) id.. В этом случае мы легко можем переносить без излишних телодвижений всё куда угодно откуда угодно, при этом сохраняя все ссылки. Но это будет работать только в том случае, если у нас будет своеобразный реестр того, что чему принадлежит. Реестр где собрана информация об этом в одном единственном месте.
Хотелось бы реализовать возможность иметь ссылку на сообщение пользователя в цитате на него, ну и другие возможности.(Отредактировано автором: 23 марта 2019 — 17:15) |
| |
|
| Flat |
Отправлено: 24 марта 2019 — 14:49
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
Тут намедни, протестил одну задумку, которая, впрочем, у меня уже давненько так крутилась в голове, да и когда-то слегка тестилась. Так вот, протестил сейчас и сравнил скорость поиска и загрузки..
Предположим у нас имеется текстовая база подобного формата, для файла users.php:
CODE:
<?php die()?>
^#id:1#n:'admin'#m:'ffffff@mail.ru'#p:2$
^#id:2#n:'vasya'#m:'gggg@mail.ru'#p:2$
^#id:3#n:'kolya'#m:'bbbbb@mail.ru'#p:2$
^#id:4#n:'lena'#m:'xxxx@mail.ru'#p:2$
^ это начало записи;
$ это её конец;
# это начало идентификатора поля, после чего через : идёт значение.
Так вот, к чему это я.. А к тому, что если такую базу НЕ сериализовать и НЕ десиреализовать, или как-то по другому конвертировать в массив и обратно, то скорость загрузки вкупе со скоростью поиска поля/значения/записи, через строковые функции типа strpos, возрастает, не упадите со стула, ... в 100 - 500 раз...
И это без мечтаний о файлах прямого доступа.., без мечтаний о мускуле и пр..
И база такая сохраняет способность легко её править вручную. И весит она в 2-4 раз меньше..
Может быть вот оно, то самое, что разгонит этот движок до космических скоростей, и даст ему новое дыхание? Как вы думаете?
Пока буду тестировать, авось что-нибудь из этого и выйдет, а может быть и нет, но результаты меня впечатлили.
Хотя не для всякой базы это подойдёт. Подойдёт там, где не нужно разбивать в массив, а нужно только убедится в наличии значения какой-то записи, или получить отдельную запись или значение поля, а не все записи/поля. Например для поиска хорошо подойдёт.(Отредактировано автором: 24 марта 2019 — 15:08) |
| |
|
| Flat |
Отправлено: 25 марта 2019 — 16:11
|
Full Member
Покинул форум
Сообщений всего: 186
Дата рег-ции: Май 2018
Откуда: Красноярский край
Репутация: 14
|
1Bot пишет:Дополнительно следует добавить функционал при удалении/переносе в другую тему сообщений по перераспределению сообщений между файлами.
Можно просто делать пометку для сообщения "удален"
Физически перераспределять сообщения между файлами с сообщениями плохая и тупиковая идея. Предположим у нас огромная тема, я видел темы с пол миллионом сообщений на одном форуме(они мечтают довести до миллиона сообщений поэтому там приветствуется любой флуд ). В этом случае нужно открыть под сотню файлов с риском потерять или запороть тему, если к примеру сервер отключится от электроэнергии.
Выход я вижу в наличии отдельного файла для каждой темы со списком, в котором записана информация типа: [номер страницы] => array(file => количество сообщений в файле, ). При этом легко вычислить необходимую информацию, которая нужна для определения номера файла и для удаления записи или целог файла если сообщение/я удаляются. В этом случае юзер получает возможность выбрать произвольное число сообщений на страницу, как и сейчас, при этом тема может быть сколь угодно большой!
Этим займусь в первую очередь, так как это самая серьёзная задача по изменению кода ядра на которое завязано многое в движке. много зависимостей фиксить нужно
Но представьте, какое удобство будет иметь целые темы! Наконец-то!
Кстати нужно ввести возможность перехода на произвольную страницу задавая число в поле ввода, как на других форумах.(Отредактировано автором: 25 марта 2019 — 16:19) |
| |
|
|
Сайт проекта ExBB
Чат на форуме
Помощь
Поиск
BanList
Описание: О развитии нового форка движка.
