Forums / National / Russian / Бета -впечатления.

Про необработанные запросы мне приходится каждые 5 минут напоминать: необработанными считаются те запросы, результаты которых не совпадают. Т.к. странички генерируются динамически и содержат счетчики и время генерации, то результаты практически все время разные, что рассматривается как проваленный запрос.

Парсер Cotonti, скорее всего, работает у меня шустрее из-за операционки. Это похоже на результаты старых тестов Cotonti 0.0.1 vs Seditio v125. Скорее всего, PCRE в Linux работает ощутимо шустрее, чем в Windows.

Я попробую провести аналогичный тест с форумом (форумы у Котонти сами по себе не самые быстрые, да еще из-за субфорумов снизилась производительность). И может быть еще тест на реальном сервере.

Но, честно говоря, результаты типа 3 запроса в секунду на таком железе - это просто ужасно. В реальных условиях такая CMS (вне зависимости от парсера) - выброшенные деньги на ресурсы. Либо виновата ОС.

Тест для форумов я сделал более стрессовый. Тоже создал две темы, но в каждой по 5 сообщений. Первое сообщение содержит 4 тестовых текста целиком, остальные 4 сообщения по одному тестовому тексту. 1000 запросов растянулось бы очень надолго, поэтому тестировал по 100 запросов. Причем уменьшил число потоков до 1, т.к. однопроцессорная система показывает наилучшие результаты именно в этом случае.

Результаты


Обратите внимание, что failed requests теперь обратная картина. Но если верить счетчикам движка и логам вебсервера, все запросы были обработаны без проблем в обоих тестах.

Ну и на десерт, для сравнения

Ждем тесты из-под FreeBSD, при условии что это реальная FreeBSD, а не запущенная в виртуальной машине.

Понял методику, по которой ApacheBench считает failed requests: он тупо сравнивает длину ответов в байтах. Наиболее многочисленная группа с одинаковой длиной считается "правильной", все остальные - "проваленными". Т.к. в страницу включаются счетчики (для страниц) и время генерации страницы и SQL (для всех), а числа получаются иногда одинаковой, а иногда разной длины, то имеем полную неразбириху по данному параметру. Именно поэтому на него никогда не смотрят, тестируя динамические сайты - для них он не только бесполезен, но и вреден, т.к. сбивает с толку.

Вот теперь официально заявляю: не вижу оснований для того, чтобы заменять встроенный парсер на xBB, вместо того, чтобы поставлять xBB в качестве отдельного настроенного пакета для всех желающих.

RTFM. Если админ не понимает значения данных четырех букв, значит он не наш клиент. И уж тем более он не будет ничего писать на ПХП, чтобы что-то добавить, а если и захочет, то не будет разбираться в том, как это сделать.

И мне надоели эти бесконечные препирания. Чтобы угодить всем на свете у нас есть хуки, плагины, с недавних пор перегрузка функций, а скоро будут еще и модули. И не надо мне говорить, что в стандартной поставке все должно быть идеально, если бы на свете было что-то идеальное, то все люди давно говорили на одном языке, ходили в одинаковых комбинезонах, ели каждый день белково-углеводную пасту из тюбиков, были одного универсального пола и получали бесконечное наслаждение от такого положения вещей на протяжении своей яркой тысячелетней жизни.

Ну, тут просто хэлп надо написать.

Там в некоторых строках вписано markitup ?
А если у меня не стоит markitup ?

Это обозначает то, что этот тэг инсталлировал в систему плагин markitup. При деинсталляции плагина этот тэг пропадет.

Приоритет - это приоритет обработки тэга. В тексте тэги с меньшим приоритетом парсятся первыми.

Тэги с флагом Пострендер парсятся уже в тексте HTML-кеша. Т.е. они применяются самыми последними и парсятся всегда (если в админке вообще включен парсинг ббкодов на страницах), при каждом запросе страницы.

UPD [*] вместо [ li ] можно сделать, при помощи callback. Можно и не вместо а в дополнение.