emzi: Комментарии

Главные вкладки

23 апреля 2007 в 1:01

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

17 апреля 2007 в 10:53

> А нет ли такого модуля уже в готовом виде у Друпала?
> Или может быть есть какие-то другие решения (редактирование ядра например)?
в "готовом" виде не встречал, но разве это что-то меняет? Модули все равно пишутся людьми
не совсем понятно, что Вы имели в виду под словами "редактирование ядра". В большинстве случаев ковыряться в "ядре" - плохой подход.

17 апреля 2007 в 10:50

>при чём здесь крон? moonman не хочет использовать внутренний поиск Drupal'а
возникло (возможно, неверное) впечатление, что у него данные на сайте обновляются очень часто, и поскольку индексы обычного поиска зависят от крона, естественным следствием стало предложение запускать его почаще.

17 апреля 2007 в 1:11

Конечно можно. Модуль только свой для поиска придется написать, и возможно подправить кое-что в базе. Как промежуточное решение, попробуйте настроить крон на более частый запуск (подозреваю, что дело в отставании поискового индекса от актуального контента)

2 апреля 2007 в 15:11

Автор не считает, что "производительность MySQL зависит только от одной переменной", он полагает, что мог бы посоветовать голословным критикам далеко не единственное место, куда можно было бы "сходить", однако не станет этого делать в силу очевидных причин.

2 апреля 2007 в 10:20

1. если нет возможности что-то сделать (на хостинге), то по крайней мере можно провести диагностику и сделать предположения о возможных причинах медленной работы. К счастью, хостингов у нас много, есть из чего выбрать.
2. "уменьшить количество запросов" - можно, я на эту тему тоже хочу сделать статеечку. К сожалению, проблема, на мой взгляд, не в универсальности, проблема носит системный характер.

28 марта 2007 в 18:27

вообще-то для этого кажется даже модуль есть, чтобы по крону оптимизировать таблицы. а если руками - то так, как я написал: optimize table XXXX; вместо XXXX имя каждой таблицы по очереди из базы подставляте и запускаете эту команду

28 марта 2007 в 18:09

query_cache_size 0
писать, чтоб включили кэш у mysql-я, то бишь query_cache_size=[сколько не жалко памяти]
еще полезно сделать всем таблицам в базе optimize, синтаксис: optimize table xyz;
кроме того, попробуйте сделать, что вам выше посоветовали, насчет конннекта не к сокету, а к пайпу. Не могу сказать, что я лично замечал разницу, но хуже не будет.

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

28 марта 2007 в 17:50

кэш Mysql, я имел в виду. проверяется так: в консоли mysql (или phpmyadmin-е) запускаете команду show variables like 'query%';
query_cache_type должно быть 'ON', а query_cache_size больше 0
150 хостов в сутки, это все равно, что 0 хостов в сутки, если они, конечно, не приходят все вместе в одну и ту же минуту Smile

11 марта 2007 в 23:08

добавление модулей дает нагрузку прежде всего на память. Первый признак начинающихся проблем - пустая страница со списком модулей и Segmentation fault в логах. Нагрузка на процессор уже будет зависеть от других факторов - строк локализации, эффективности кода модулей итд. Не доходят руки до пятерки, но за схему загрузки нод в 4й версии хочется одновременно и похвалить (за красоту), и руки поотрывать - за полную неэффективность при работе со списками нод

16 февраля 2007 в 20:03

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

14 февраля 2007 в 22:02

плохо настроенный mysql, неоптимизированные таблицы (их нужно периодически оптимизировать), плохая работа кэша. А что значит - больше 50 юзеров? 50 залогиненых или 50 одновременных запросов страниц? Вообще, fvds - это же виртуальный сервер, и тормоза могут быть от "соседей".