сайт clubwave.ru сегодня закрыли за перегрузку сервера.. сказали, что иногда винчествер не успевал копировать информацию.. перегрузка наступила при достижении 700-800 посетителей в сутки...
из предоставленных логов видно, что абсолютно все перегрузки вызывает модуль locale
пока не ясно что делать с порталом, сам хостинг шифруется, не отвечает на телефон и закрыл папку с сайтов от чтения... очень интересно, я даже не могу скопировать свой портал... эй Россия...
Всвязи с чем ко всем большая просьба.. посоветуйте дорогой, мощный хостинг, который потянет сраных 1000 человек.. можно западный, и как быть без модуля locale ?
слышал решение есть но времени на поиски нет совершенно..
хэлп!!
Комментарии
Мда, locale разработчики явно уделяют мало внимания. СУБД на отдельно хосте или на том же? Если на отдельном, мне в свое время на shared хостинге помогло использование чистого gettext - вместо хранения переводов в базе хранение их в файлах и выборка посредством расширения gettext в PHP. Правда последний такой патч я делал под 4.5, но можно посмотреть как 4.7 адаптировать... Результат не гарантируется, но иногда бывает очень действенным.
Кстати, кэш включён? Время кеширования выставлено?
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
База на том же хостинге.. тоесть если на томже то gettext не поможет?
И есть ли резон поставить базу на другой хостинг?
А патч много кода затрагивает?
Ты кстати смотрю тоже locale не торопишься включать..
Можно конечно в коде самому всё менять.. это лучше, чем ставить заглушку, как мне посоветовали..
Кеш не был включён, поскольку меня уверяли, что с нагрузкой всё в порядке... сейчас включил, минимальное время не выставил... лучше поставить?
Кстати, расскажи о модуле throttle .. что он делает, и как оптимально его настроить?
Винчестер у них вместо оперативки наверно. Гы, модулей к апачу админы не пожалели повключать:
Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e-p1 FrontPage/5.0.2.2635 mod_jk/1.2.15 mod_python/3.1.4 Python/2.2.2 mod_perl/2.0.2 Perl/v5.8.8
даже расширения frontpage включили. mod_php только не видно. Однако 1000 юзеров drupal.ru тянул на shared хостинге Infobox. Правда не всегда быстро
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
"Винчестер у них вместо оперативки наверно. Гы, модулей к апачу админы не пожалели повключать:
Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e-p1 FrontPage/5.0.2.2635 mod_jk/1.2.15 mod_python/3.1.4 Python/2.2.2 mod_perl/2.0.2 Perl/v5.8.8
даже расширения frontpage включили. mod_php только не видно. Однако 1000 юзеров drupal.ru тянул на shared хостинге Infobox. Правда не всегда быстро :)"
Я могу отрубить всё кроме php это както поможет?
Не поможет. Реплика была вызвана количеством модулей к Апачу в попытке заточить сервер под всё сразу - перл, ява, питон, пхп.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Тут где-то была длинная тема про переделку этого модуля, даже какой-то код выкладывался сокращающий кол-во обращений к базе... и мной тут вроде выкладывался locale использующий gettext и po файлы лежащие на диске, правда не доделал обработку множественных форм...
ЗЫ. А вообще у меня тоже была проблема с друпалом из за большого количества обращений к базе, быстро выбирался лимит запросов (заявленный хостером лимит 50000 запросов/час), причем это было при двухстах посетителях в сутки. Такая вот фигня. Это было на servage.net, на infobox.ru тот же сайт работает без проблем...
Вообще это админские глупости ограничивать количество запросов. Друпал много запросов делает, но они мелкие и простые. Можно конечно всё хоть в один запрос запихнуть с такой кучей соединений и группировок, что СУБД им подавится.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
То же пытался сделать возможность наглядного перевода множественных форм, но упёрся в отсутствие однообразия их переводов и неочивидные связи между различными вариантами. Решил, что проще просмотреть исходный код на наличие count и %count заместителей, и загрузить для них .po файл.
Вот теперь думаю, а что если бы мы знали что кто-то ещё борется с этим модулем? Возможно сообща и удалось бы побороть.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Самый тупой способ это отключить locale и переводить путем правки текста непосредственно в модулях
Ага, и делать это каждый раз при обновлении друпала... не, это плохой способ.
Плохой не спорю, но знаю что так делают.
У меня кстати была бредовая идея написать офлайн утилитку которая бы брала модуль и po файл и делала поиск и замену строк.
А тут есть здравый смысл. Хотя способ экстремальный - после каждого апдейта затачивать сайт под определённый язык
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Можно сделать хитрее: собрать статистику о часто выполняемых запросах, и перевести в коде только эти фрагменты. Пользователям в любом случае не нужен перевод админки, а админов так много не ходит
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
ну а есть разница переведена админка или нет, если туда всеравно посетители не ходят? Или в том логе перегрузки из-за большого колличество записей в таблице переводов и идут тормоза?
кстати еще роботы могут опрокинуть, смотрю логи у меня сейчас мэйлрушный бот перелапачивает event календарь за 1970 год по 6-7 страниц в минуту
то что роботы это можете не сомневатся - сменились ссылки - вот они все и бросились качать
что-бы этого не происходило - надо ограничение поставить в robots.txt - потом логи посмотреть
а еще надо поставить модуль devel и смотреть сколько запросов что делает - может модули какие не дружат или блок куда-то неудачно вывели.
а например что в robots.txt написать?
модуль devel ставил пару месцев назад, правда не на этот сайт, ну и вылезла куча ошибок, пришлось сайт восстанавливать.. На этом сайте экспериментировать сейчас не хочется, итак бедный посетителей теряет..
Народ, я вот читаю и прямо каким-то ущербным себя начинаю чувствовать: не первый раз пишут про проблемы с этим самым locale.module, а я не могу понять - отчего так? У меня ни как не получается сделать, что бы этот модуль так сильно грузил систему и делал множественные запросы к БД каждый раз.
Однажды это сделать получилось, но я сам был причиной того: перекодировал данные в БД и покривил кэш локализации, от того действительно при каждом обращении к сайту Дрюпал заново доставал все переводы (т.к. кэш не мог получить). Но с этим делом быстро разобрался (просто почистил кэш) и всё заработало как обычно: почти на каждый запрос - одно обращение за переводами - к кэшу.
Были тут темы, затрагивающие возможности как-то избавиться от locale.module. Был код, который просто подключал файл с переводами напрямую... Случилось так, что я получил возможность глянуть на сайт одного человека, который тоже всё жаловался на locale и его тормоза.
Могу сказать, что сразу заметил:
Время генерации страницы на моей машине составило около 4 секунд (это если на администраторские странички не заходить! Там ещё больше).
И человке жалуется, что сайт медленно работает и это из -за локализации...
Вот и смотрите сами, где там собака зарыта...
если снтересно лог тяжёлых запросов в аттаче
на что жаловаться не знаю... ну views кажется при использовании вывода как teaser list или full nodes нагрузки давать не должен.. насчёт CCK фиг знает...
А если говорить о хостингах, то случилось ставить друпал на арбатеке... так он одного посетителя не вытягивал... - через раз - невозможно подключиться к базе данных
Кстати а что насчёт PostgreSQL ?
При СУБД на той же машине, что и вебсервер работа locale.module и использование gettext не отличаются по скорости - у меня были такие же результаты. Эффект можно получить, если СУБД на отдельной машине. И то подозреваю это зависит от загруженности СУБД.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
тоесть в любом случаем MySql должна быть быстрей чем gettext и базу лучше размещать на томже сервере, где и сам сайт?
"винчествер не успевал копировать информацию" - очень интересно вообще, это о чем?! Если не успевал считывать данные для БД, то, может быть кэш там побольше поставить, или вроде того?
Хотя, модуль "локале" действительно тормоз. Кто хочет над этим поработать? Основным разработчикам это не очень нужно, им английского хватает. (мне пока тоже... пока...)
А еще - ничего личного, но, судя по твоим постингам здесь, я не исключаю вариант что ты сам что-то испортил, может какой кусок кода не так написал, или еще что. Так же, не вижу аттача, в котором лог запросов.
P.S. Поздравления принимаешь только ты
""винчествер не успевал копировать информацию" - очень интересно вообще, это о чем?! Если не успевал считывать данные для БД, то, может быть кэш там побольше поставить, или вроде того?" - ага именно это они и сказали... кэш попросить увелисчить? я какимто чудом их заставил сайт включить, но даже если без locale всё будет ок, мне такой подход как закрытие сайта без предупреждений не нравится, поэтому ищу новый хостинг..
"А еще - ничего личного, но, судя по твоим постингам здесь, я не исключаю вариант что ты сам что-то испортил, может какой кусок кода не так написал, или еще что. Так же, не вижу аттача, в котором лог запросов."
Да я сам скорее через MyAdmin всё загрузил... часто кстати вывожу по 3000 строк, чтобы удалить, но это не принципиально... сам ничего не программировал в модулях принципиально, поскольку всё можно делать и так, а потом опыт очень малый.. Все куски моего кода относятся к созданию темплейтов, и как правило к <?php if $field else $field и print $field ?>
не думаю, что это как то повлияло на My Sql
а лог как водится приложить забыл..
держите..
блин прикрепить файлы нельзя? сча сюда кусок кину...
SELECT vhost, AVG(pidcount) as avg_pid, MAX(pidcount) as max_pid, AVG(cpuusage) as avg_cpu, MAX(cpuusage) as max_cpu, AVG(memusage) as avg_mem, MAX(memusage) as max_mem FROM eplanet.apachetop_summary GROUP BY vhost;
# Time: 061130 17:54:05
# User@Host: admin[admin] @ localhost []
# Query_time: 21 Lock_time: 0 Rows_sent: 563 Rows_examined: 1849178
SELECT vhost, AVG(pidcount) as avg_pid, MAX(pidcount) as max_pid, AVG(cpuusage) as avg_cpu, MAX(cpuusage) as max_cpu, AVG(memusage) as avg_mem, MAX(memusage) as max_mem FROM eplanet.apachetop_summary GROUP BY vhost;
# Time: 061130 18:24:43
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
use clubwave;
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'webform' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Приколы (6)' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'page footer' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Дальневосточная (3)' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Global Party (16)' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Каталог развлечений' AND t.locale = 'ru';
# Time: 061130 18:24:44
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# Time: 061130 18:24:46
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# Time: 061130 18:24:49
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'header' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'РћР±Р·РѕСЂ CD' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'book page' AND t.locale = 'ru';
# Time: 061130 18:25:02
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '%page not found.' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# Time: 061130 18:25:10
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 7 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Binary Poll' AND t.locale = 'ru';
# Time: 061130 18:25:16
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Ranking' AND t.locale = 'ru';
# Time: 061130 18:25:17
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Shoutbox' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Vote for or against a number of choices.' AND t.locale = 'ru';
# Time: 061130 18:25:18
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Ртальянская' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'weblink' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'STOP наркотикам (25)' AND t.locale = 'ru';
# Time: 061130 18:25:19
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'Санкт-Петербург' AND t.locale = 'ru';
# User@Host: clubwaveu[clubwaveu] @ localhost []
# Query_time: 6 Lock_time: 0 Rows_sent: 1 Rows_examined: 7932
SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru';
# Time: 061130 18:25:20
и так далее
Странно, чего так долго исполняется каждый запрос (если конечно этот query_time в секундах выводится). И строки всегда перебраны все подряд - т.е. полный скан таблицы что-ли? Индексы не слетели? Тогда выполнение EXPLAIN SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = '' AND t.locale = 'ru'; интересно посмотреть.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
посмотреть уже ничего уних не получится, т.к. переехали на другой сервак, а там свои проблемы..
новости с нового сервера...
переехали значит в спешном порядке на infobox.ru
нагрузку дающуюся на тарифе эконом при 500 человеках не превышаем... чаще всего меньше 50%
однако главная страница открывается несколько секунд, смотрите сами - http://clubwave.ru
галерея вообще висела недавно секунд 30.. http://clubwave.ru/gallery
пробовал отключить модуль locale... ничегон е изменилось, на вид стало ещё медленней
из переписки с саппортом:
> да, но на другом сервере генерация была в разы быстрей..
Возможно, это связано с особенностями настройки софта на сервере. Так, например, у нас PHP установлен как CGI, а не как модуль к Apache. Это несколько снижает скорость выполнения скриптов, но значительно повышает стабильность и безопасность работы.
> А на более дорогом тарифе будет быстрей скорость MySQl или если нагрузка не превышает 100% разницы не будет?
Скорость работы сайта не зависит от тарифа. Более высокую скорость можно достичь на выделенном сервере.
Если "PHP установлен как CGI" то это тормоз, не нужен такой хостинг.
Не, их тоже понять можно. Через mod_php сложно обеспечить разграничение прав (точнее можно, но в ограниченных пределах :). А на инфобоксе наверно suphp стоит, который хотя и запускает PHP через CGI (кстати это скорее всего FastCGI, т.что потеря в производительности не особо большая и вообще не всегда есть), но зато скрипты работают под аккаунтом пользователя, а не под аккаунтом вебсервера.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
ну когда главная страница открывается 10-20 секунд это торможения серьёзные...
Кстати, когда из кэша берутся данные то открывается мгновенно..
вобщем я не знаю что делать, планирую ещё попробовать spaceweb... а потом VPS, если не получится..
Кстати, axel, может поведаешь у кого хсотишься и на каких условиях?
10-20 секунд это уже не CGI, это хостер нахватал клиентов больше чем сервер выдерживает В грамотности настроек на серверах Инфобокса не сомневаюсь - года два у них хостился, админы и саппорты там толковые.
Но однажды тормоза надоели и собрали с другом на двоих сервер, поставили на coalocation в Корбине и забыли про нехватку ресурсов На Drupal на сервере несколько сайтов (хотя drupal.ru из них самый посещаемый), сколько ещё железо потянет даже не знаю.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Ух ты как интересно. Т.е. вы свой комп поставили в эту корбину? или как? И очень интересно сколько это стоит! Этож как хостинг на выделенном сервере получается, только лучше и дешевле!
В мастере один юнит стойки раньше стоил 55$/месяц, сейчас вроде сотню. В корбине должно быть дешевле. "Поставить комп" туда возможным не представляется, в колокейшн можно втыкать только 19" железо.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Сервер собрали в 1U-корпусе. Приличных хостеров, которые ставят компы в обычных корпусах не считая их за несколько юнитов в Москве не нашлось. Я только в Питере знаю у Инфобокса были одинаковые расценки - что за 1U, что за тауер. Со сборкой сервера эт вообще песня была - для интересующихся железом репортаж с фотками о том, как с творческим подходом можно запихнуть десктопную плату в серверный 1U-корпус: http://ru.chuvash.org/blogs/comments/54.html
Корбина не самый дешёвый хостинг, причём с оплатой трафика при перерасходе, не буду уже объяснять почему именно туда сунулись, так исторически сложилось
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
саппорт мне понравился, и по их словам сервер, на котором лежит clubwave.ru загружен лишь на 30% и поступило предложение оптимизировать скрипты... по этому поводу у меня большой вопрос на обсуждение, но я думаю создать для этого отдельную тему и постараться развёрнуто объяснить суть проблемы, дабы всем вместе решить её..
А сколько на drupal.ru хостов/хитов?
И ещё интересно, если теоретически к вам положить сайт, можно как-то поотслеживать хотябы какие страницы нагрузку большую дают?
Статистика общедоступна, cсылка внизу каждой страницы - stats.html.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
да ладно? больше 1000 уников в день? не ожидал... а на drupal.org тогда сколько? нет информации?
Кстати, под тысячу хостов посещаемость доходила когда на инфобоксе ещё жили, работало очень медленно, но работало.
На drupal.org подозреваю на порядок больше, но эт так, от фонаря. Где-то на drupal.org публиковали данные, если не ошибаюсь.
Вот ещё: http://www.alexaholic.com/drupal.org
и для сравнения любопытно: http://www.alexaholic.com/drupal.org+joomla.org
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
И если сравнить с drupal.ru, то вообще жуть: http://www.alexaholic.com/drupal.ru+drupal.org
1000 хостов нервно курят в сторонке Данные конечно не факт, что точные, я не смотрел как они это высчитывают, но о соотношении по ним полагаю судить можно.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Нагрузку по посещаемости или по потреблению CPU и памяти? Статистика потребления ресурсов для юзеров у нас не ведётся, пока ещё в этом нет надобности, можем себе позволить не считать
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
как мне сказали CPU и память потребляем не сильно, а вот MySQl сервер тормозил безбожно из-за нас..
Кстати еду опять на e-planet.ru на новый сервер, обещал включить кэш и оптимизировать скрипты... кстати кэш для авторизованных теоретически включить нельзя?
И именно что получается - я выставил минимальное время жизни кэша - 15 минут, значит если страницу не запрашивали 15 минут в кэше её не будет?
и если поисковик пойдёт индексировать всё подряд, каждая страница будет генерироваться заново?
В 5-й версии есть какието улучшения в области кэширования и нагрузки? И как скоро ожидается релиз?
понятно, что ненастроенный mysql может работать неоптимально, но чтобы настолько медленно...
Путем настроек параметров mysql-сервера мне на моей основной площадке удалось добиться прироста производитльности, похоже, что для друпала нужны такие настройки, которые для других систем некритичны
блин... хорошо хоть на месяц заказал...
что делать блин?
У когони-будь есть paypal ?
Пэйпэл с Россией не работает... Кредитку себе не хочешь сделать?
хочу наверное, но мне срочно нужен хостинг..
Здравствуйте! А можно ли залить вместо дефолтного инглиш, русский и вообще отключить локале. Зачем ему вообще работать и даром запросами базу мучить?
Сообщения на английском забиты в исходных текстах. При выводе модуль locale просматривает базу и подменяет сообщения на английском на сообщения на другом языке (хоть на русский, хоть на другой английский). Без locale будут выводиться сообщения из исходников - т.е. оригинальный английский текст.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Жаль, конечно, что английский так намертво залит в Друпал. Я надеялся, что есть отдельная таблица в бд с англ. языком и ее легко можно было бы заменить русской.
Использован механизм аналогичный применяемому в gettext. В исходниках все строки подлежащие переводу обрамлены в вызовыы специальной функции. Эта функция вызывается с аргументом в виде строки английского текста и по нему ищется перевод. Метод удобен тем, что даже если перевод отсутствует, то можно получить человеко-понятное отображение строк - хотя бы английский текст будет всегда видно. И механизм перевода легко менять переписывая единственную функцию t() - она определена в модуле locale. Например чтобы брать переводы не из базы, а из файлов - см. комменты выше по топику.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Я смотрю, сайт открывается нормально, хотя Вы на том же инфобоксе. Что поменялось?
сайт открывается только из кэша нормально, местами отлично, но вот попробуй зарегится и походить по сайту, особенно в галерею зайди... сразу всё поймёшь
функция t() всегда использует кэш для хранения строк. Есть две потенциальные проблемы:
1. если что-то случится с таблицей cache и слетит запись, в которой находятся переводы, locale будет лазить в базу за каждым переводом. Обычно это довольно медленно.
2. В кэш отправляются только короткие строки (до 75 символов, кажется). Поэтому если на странице много длинных локализуемых текстов (админка этим страдает), то опять начнутся обращения к базе.
Решений, в моем понимании, два: либо увеличивать максимальную длину строки для помещения в кэш, либо разбивать локализуемый текст на части меньше 75(?) символов
Вот тут фишка, что длинные справочные тексты есть в большинстве своём только в админке. Хотя есть ещё справка по форматам фильтров для пользователей - да и всё пожалуй. А в админку по определению лазает очень ограниченное число людей и то не часто, поэтому тут с производительностью вопрос не стоит.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
а играет какуюто роль колличество переведённых строк? тоесть я залил полный перевод, а если я переведу только необходимое запросов меньше будет или запросы будут в любом случае, даже если переводы пустые а модуль locale задействован?
советую проанализировать таблицу с локализацией на предмет распределения строк по длинам - может быть, выставленный в ядре размер максимальной строки, попадающей в кэш, неоптимален
например?
ну на прежнем хосте куда я опять еду всё открывается моментально, но при определённых условиях сервер запросто начинает глючить..
Чтобы посмотреть, при каких условиях возникают тормоза
дали только лог тяжёлых запросов, я выше приводил... но спрошу на всяк случай
ничерта не понимаю, что за reach(per million)