Я в этом не очень разбираюсь, поэтому ищю решение на уровне модуля.
В установленном модуле metatag активировал модуль Metatag: Views, в итоге в представлении появилась ссылка metatag, где для заголовка можно выбрать маркер (токен), но из доступных маркеров только 2 имеют слово number: [current-page:page-number] и [smart-paging:page-number] (есть ещё токен, который показывает случайное число, но это не подходит) в итоге, работает только первый и в комбинации:

[view:title] - страница [current-page:page-number]

Я наверное не совсем верно вас понял...

Сначала я подумал что statistics это модуль входящий в ядро друпал, активировав его, смог на странице: /admin/reports/hits видеть посещения при нажатии на ссылку подробнее, но там нет никакой формы для автоматического запроса по IP.

Потом я подумал, что это какой-то конкретный модуль и попробовал найти по адресу: http://drupal.org/project/statistics оказалось там очень много самых разных модулей...

Включил статистику, но там же просто показываются посещения и вся информация о посетителе - это некий Гость пришёл на такую то страницу с такой то страницы, есть ещё IP. Как же определить среди всего этого (сотен посетителей за день, того кто послал письмо)?

Получается только по IP, и всё это вручную?

Или можно как то автоматизировать процесс?
Да и как вставить в сообщение контактной формы на сайте IP отправителя?

После переключения jquery с 1.8 на 1.7 действительно всё заработало как надо!

Огромное спасибо!

Также отмечу что на сайте используется кеширование memcache + authcache, модули: CSS Embedded Images, Speedy, также сайт находится под CDN Cloudflare (кеширующий прокси) и к тому же используется сборка Drupal Pressflow 7.22 (оптимизированный Drupal Core).

Может быть что-то из этого мешает?

Версия Views стоит последняя 7.x-3.7.
jQuery Update модуль версии 7.x-2.3, в установках модуля включена версия 1.8, jQuery compression level = Production (minified), jQuery and jQuery UI CDN = нет.

marazmus wrote:

1) random в mysql очень медленный, гугл выдает тонны плача по этому поводу, вывод - кешируйте рандом-блоки

2) вся эта тряхомундия нивелируется покупкой хостинга у ИТПатрола за 300 рублей в месяц, после чего такие проблемы забываются, и появляется время на сам сайт, а не на разборки с нищебродским хостингом

1. random блоки кешируются, об этом было написано в п.1

РЕШЕНО

Может быть как то, используя агрегацию по nid материала?

После установки модуля http://drupal.org/project/apc_status для просмотра состояния работы APC увидел, что APC не держится больше нескольких минут, получается весь эффект от него пропадает.

Сейчас настройки такие:

Подскажите на основании данной статьи:
http://drupalace.ru/lesson/sistema-keshirovaniya-drupal-7-chast-tretya-u...

Для множественного хранения внизу приведены настройки:
// Выносим кэш страниц в Varnish.
$conf['cache_backends'][] = 'sites/all/modules/varnish/varnish.cache.inc';
$conf['cache_class_cache_page'] = 'VarnishCache';

Заводской раб wrote:

"astrameridian" wrote:

Я сейчас плачу 120 р/мес

ёпть, еще и скулит

MainVisor wrote:

1. Берем VPS сервак 1 CPU +1Gb на KVM ядерной виртуализации
2. Ставим nginx как бэкэнд Apache или заменяем всё на Litespeed
3. PHP обязательно как mod_php
4. Переносим cache MySQL в ОЗУ
5. Ставим eAccelerator, а лучше xCache, так как eAccelerator толком уже не развивается.
6. Ставим Zend Optimizer
7. Вырубаем кэш друпала, кроме css сжатия
...
и тыды и тыпы

Также есть вопрос, как не сбрасывая кеш Boost, который сейчас копится 24 часа, сбрасывать отдельный блок, например каждый час?
Речь идёт о размещении ссылок в блоке, ссылки периодически покупают на разных страницах, в итоге закешированная страница не отображает ссылки 24 часа.

Вроде стоит модуль ajaxblocks , который вроде должен подгружать данный блок используя ajax, но не знаю как проверить закешировнность/незакешированность отдельной области страницы...

Пробовал ранее модуль Block Cache Alter, но он как то в связке с Boost не работал...

Ура! После подключения filecache и проверки сайта на http://loadimpact.com/
сайт держался до 43 одновременных подключений!

В итоге: 173 соединений, 24 в ошибке.
Мин. скорость загрузки страницы: 3.21s, максимальная: 56.86s.

При этом при 43 соединениях, скорость загрузки была около 18 секунд.

Ущё вопрос по APC, в настройках php.ini выставил для APC 32 mb, при этом за всё время, при просмотре /admin/reports/status занятой памяти для APC показывает обычно 2-3 мб, никогда больше 4 мб не было. APC настройки были сделаны для стандартного режима (а) в описании модуля.

Или лучше сделать режим (б), чтобы максимум из базы данных в оперативной памяти грузилось?

Кстати при включении модуля filecache и добавления в settings.php строчек:
$conf['cache_backends'] = array('sites/all/modules/filecache/filecache.inc');
$conf['cache_default_class'] = 'DrupalFileCache';

перестал грузится сайт:
Fatal error: Class 'DrupalAPCCache' not found in /home/biopcru/public_html/includes/cache.inc on line 31

Удалив после этого строчки для APC:

k_dmitry wrote:

"astrameridian" wrote:

Пробовал недавно использовать модуль filecache

"astrameridian" wrote:

что приводило к меньшей производительности

q2_faith wrote:

я думаю вы уперлись в настройку окружения

А что же можно ещё сделать не со следствием, а с причиной?

1. Возникла идея, можно ли сделать случайный вывод через представления но не среди всех материалов определённого типа, а например последние 100, тем самым сократив размер кэша базы и снизив нагрузку с базы данных по подготовке данного представления. Если это поможет, как это реализовать?

Провёл сейчас тест по http://loadimpact.com/ итоги неутешительные
уже где-то на 15-ти одновременных посетителях пошла 1 ошибка (сайт был недоступен для этого посетителя).
Также к этому моменту ресурсы загрузки процессора, памяти были близки к 100%.

maincg wrote:

Я APC не рассматривал бы в принципе. Сначала поставил eAccelerator, сайты летали, но через сутки начинали жутко тормозить (4-7 с). Как оказалось, в eAccelerator'а отсутствует Cacher. Снес его и установил XCache. Сейчас нет никаких проблем, скорость высочайшая. Не зря же его использует самый популярный хостер для Drupal'а

gorr wrote:

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

Спасибо, попробую. Было от 30 минут до 12 часов, сейчас поставил от 30 минут до 1 сутки и для html и для javascript. Посмотрим...

multpix wrote:

"k_dmitry" wrote:

Сделайте скрин страницы с модулями

ls sites/all/modules > modulelist.txt

Вот список модулей (SSH есть):

Да кстати, сайт использует CDN Cloudflare.com, основной плюс которой в том, что страница загружается быстрее и вес её меньше, например без cloudflare вес страницы 440 кб и загрузка в среднем 7-8 секунд, а при подключенном cloudflare вес страницы 170 кб и загрузка страницы за 2-3 секунды.

Кстати, когда меняю какие либо настройки в представлениях, то попадаю на белый экран с текстом (видимо это код настроек представления), и приходится возвращаться на страницу назад в браузере и только потом сохранять.

У кого то такое было?
Может из-за кеширования или использования модуля admin menu который на javascript...?