Перед нами стоит серьёзная проблема: как увеличить скорость работы wacko?
Wacko Ускорено
Предложения
- По структуре БД
- Заменить все VARCHAR -> CHAR
- Плюсы: увеличивает скорость работы с этими полями на 50–100%.
- Минусы: занимает заметно больше места.
-
Вывод: наверное, делать.
- Вывод: наверное, не делать. глупости.
- Отказаться от медленного и глючного FTS в mysql и написать свой индексатор. Индексирование делать отдельно от сохранения. Открывать картинку 1х1 пиксель раз в день, которая будет индексировать, либо при помощи WeaselWiki:НебольшоеПериодическоеЗадание.
- Плюсы: будет заметно быстрее сохранение, немного быстрее селекты.
- Минусы: очень много работы.
- Вывод: делать, но потом.
- Движок.
-
Хранить отформатированный текст, кроме акшнов и ссылок (которые анврапнуть и завернуть в двойной-скобка-синтаксис).
- переписывается форматтер основной, чтобы вызывал не Линк, а PreLink.
- пишется PreLink, который анврапывает все линки, приводя их в простой, удобный для регэкспа формат
- пишется PostFormatter, который ничего не умеет, кроме простого Link.
- при сохранении пользуемся основным форматтером
- при выводе — PostFormatter
- вспомогательно — пользуемся основным, куда флажком $this->Format(.... immediate=1) добавляем вызов PostFormatter
- под это уже даже есть специальное поле в БД – body_r.
- Плюсы: Все должно стать заметно быстрее.
- Минусы: не вижу.
- Вывод: сначала думать, потом делать.
- Итог: сделано, привело к большому ускорению, очевидно. 0.2 секунды на страницу примерно сейчас.
Экшны.
- Search (?)
- lastusers (?)
- pageindex
- оптимизировать, ужасно тормозит
- linkstree (??)
Вопросы.
- Что-нибудь ещё? DBAL с кэшированием sql-запросов в текстовых файлах?
- Ку Ме: буэ...
- Ку Куц вот думает, что не буэ. Сделать экспирейшн в 10 минут...
- Стоит сделать хотя-бы примитивное профилирование. Ускорять надо узкое место, а мы его не знаем.
- Ку Куц: Сейчас узкого места не видать.
- Meta Wizard: если в таблице есть хоть одно поле динамической длины, то строка таблицы также приобретатет динамическую длину. Если же в таблице нет ни одного поля динамической длины, то n-ую запись можно найти по смещению n*размер_записи. Потому имеет смысл любую таблицу, содержащую поля динамической длины (в особенности TEXT) разбивать на 2 таблицы, отправляя во вторую таблицу все поля динамической длины. Конечно же, это имеет смысл лишь случае, когда в сис-ме присутствует значительное кол-во запросов, для выполнения которых достаточно полей статической длины. Такими запросами является поиск по разынм критериям.
- Это не совсем так в случае mysql. Эта bd не умеет рассчитывать «статическую длинну записи», только «статическую длинну поля». Поэтому количество полей с переменной длинной играет роль. Наличие одного – двух полей переменной длинны не так уж и роляет. -Grigory Bakunov
Many thanks to: