vertical-align:middle; или прямо в пикселях для более ровного результата style="vertical-align:-12px;"vertical-align:middle; или прямо в пикселях для более ровного результата style="vertical-align:-12px;"Код: Выделить всё
<dt><!-- IF forumrow.S_IS_CAT --><a href="{forumrow.U_VIEWFORUM}">{forumrow.FORUM_IMAGE} • {forumrow.FORUM_NAME} • {forumrow.FORUM_DESC}</a><!-- ELSE -->{L_FORUM}<!-- ENDIF --></dt>Код: Выделить всё
# Time: 121112 22:35:46
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 2.032246 Lock_time: 0.000027 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745346;
UPDATE _phpbb_sessions SET session_time = 1352745344, session_last_visit = 1352745344, session_admin = 0, session_page = 'viewtopic.php?t=177&p=280178', session_forum_id = 0, session_album_id = 0
WHERE session_id = '7d5377e482855d914f8d243eea3931ab';
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 2.997184 Lock_time: 0.000036 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745346;
UPDATE _phpbb_sessions SET session_time = 1352745343, session_page = 'ucp.php?mode=login', session_forum_id = 0, session_album_id = 0
WHERE session_id = '1b00abf367c495ad353b19e603e8485f';
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 2.628216 Lock_time: 0.000032 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745346;
UPDATE _phpbb_sessions SET session_time = 1352745343, session_page = 'viewtopic.php?forum_uri=posle-prostudi&t=7971&start=', session_forum_id = 0, session_album_id = 0
WHERE session_id = '0b884492492434be31aa3f0033237d75';
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 2.525855 Lock_time: 0.000024 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745346;
UPDATE _phpbb_sessions SET session_time = 1352745343, session_page = 'viewtopic.php?forum_uri=ami&t=8009&start=', session_forum_id = 0, session_album_id = 0
WHERE session_id = '805febf3892094e8264b6d59bbd20b04';
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 2.919537 Lock_time: 0.000027 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745346;
UPDATE _phpbb_sessions SET session_time = 1352745343, session_last_visit = 1352745343, session_admin = 0, session_page = 'viewtopic.php?f=52&p=279034', session_forum_id = 52, session_album_id = 0
WHERE session_id = 'f6d007af2c847f77ba2b03a081af5e40';
# Time: 121112 22:36:01
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 1.099386 Lock_time: 0.000032 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745361;
UPDATE _phpbb_sessions SET session_time = 1352745359, session_last_visit = 1352745359, session_admin = 0, session_page = 'viewtopic.php?forum_uri=srochno&t=6776&start=', session_forum_id = 0, session_album_id = 0
WHERE session_id = '7948075f14df74b480ed7b719bb32949';
# User@Host: gv_user[gv_user] @ localhost []
# Query_time: 1.124465 Lock_time: 0.000025 Rows_sent: 0 Rows_examined: 1
SET timestamp=1352745361;
UPDATE _phpbb_sessions SET session_time = 1352745360, session_page = 'posting.php?mode=reply&f=50&t=7971', session_forum_id = 50, session_album_id = 0
WHERE session_id = '0b884492492434be31aa3f0033237d75';Хостер отвечает:User 'forum' has exceeded the 'max_user_connections' resource (current value: 10) [1226]
Вопрос - такая рекомендация приемлема? Действительно стоит сменить способ подключения и не будет ли после этого других проблем с phpbb? И если да, то как его сменить?Данное сообщение сигнализирует о том, что Ваш проект держал слишком много открытых одновременных подключений к серверу баз данных. Обычно это вызвано использование mysql persistent connection, как например в файле /includes/db/mysql.php:
$this->db_connect_id = ($this->persistency) ? @mysql_pconnect($this->server, $this->user, $sqlpassword) : @mysql_connect($this->server, $this->user, $sqlpassword, $new_link);
Рекомендуем изменить способ подключения к базе с mysql_pconnect() на mysql_connect().
а конвертеры на что? При правильности рук и правки кода конвертера под конкретный форум - все прекрасно переноситьсяKot писал(а):причём посчитали нормальным потерять всех пользователей и всю базу сообщений??
для небольшого не требовательного форума кунена подходит полностью, но в моем случает от форума требовалось не только непосредственно форум но и ряд систем учета рейтингов и систем на подобие денежных, а также вносить ряд доработок, позволяющих на основании информации о пользователе, его рейтинге и счетов предоставлять ему определенные права доступа к информации как на форуме так и на самом сайтеKot писал(а):А всё-таки серьёзно, чем конкретно phpBB лучше кунены? Я интересуюсь не просто так, у меня сейчас в очередной раз встал вопрос, что ставить на один из Joomla-сайтов: phpBB с бриджем, или ту же Кунену?ELITE_ писал(а):из бесплатных - он один из самых многофункциональных движков форума..
Просто ситуация действительно выглядит несколько странно: как я и говорил, вы отказались от Кунены в пользу phpBB, причём отказались с потерями, и в то же время жалуетесь, что phpBB жутко тормозит. Тут либо ситуация "мыши плакали, кололись", либо phpBB предоставляет что-то кардинально отличное по сравнению с Куненой, за счёт чего и возникает повышенная нагрузка.
P.S. А на Жука внимания не обращайте. Он считает, что выполняет священную миссию по очистке форума от школоты, на самом же деле он просто ... жук. Я старше его всего лишь на пару лет, но уже научился не судить о людях только на основании знания ими правил русского языка.
P.P.S. А ещё он хоть и тролль, но сам ведётся как миленький. И обязательно ответит на мои пассажи в его адрес.
Ты как вообще можешь выдавать здесь такие цифры, если у тебя нет настроенного и посещаемого форума на phpBB3? Ты по чистому движку что ли оценку делаешь?примерно в 2 раза ниже sql нагружен
Описанное выше может хорошо объяснять, почему Кунена генерит меньшую нагрузку. Более навороченная авторизация доступа, поддержка всяких свистелок вида "кто онлайн", активности на форуме и так далее. Почему-то мне кажется, что если на Кунену установить все те возможности, которые предоставляет базовый пакет phpBB, то она будет грузить проц не меньше.ELITE_ писал(а):ну и +к кунене - это легкость, она раза в 3-4 меньше нагружает проц на хостинге и примерно в 2 раза ниже sql нагружен
JFusion на стороне жумлыКстати, с помощью чего реализована связка авторизации phpBB и остальных сервисов? Если мост сделан не оптимально, у вас может создаться ложное впечатление о проблеме в самом phpBB, хотя на самом деле это не так.
Форум на одном домене с сайтом, хостов в день около 800, откуда может быть эта нагрузка/превышение? Раньше было и 2500 посетителей в день и все нормально работало без ошибок... Вымогание со стороны хостера или действительно высокая нагрузка? Дело то было в майские праздники и посетителей намного меньше чем обычно...У Вас происходит превышение лимита на количество запущенных обработчиков PHP FastCGI.
[Fri May 03 01:36:48 2013] [info] mod_fcgid: too many /var/www/ххххххххх/data/php-bin/php processes (current:4, max:4), skip the spawn request.
Рекомендуем провести оптимизацию работы PHP скриптов или рассмотреть вариант переноса сайта на VPS.
а это значит, что проблема не в нагрузке скриптов на сервер, а в количестве одновременных обращений к различным скриптам.превышение лимита на количество запущенных обработчиков PHP