в догонку. посмотрел в код модуля.

не знаю насколько это критично НО

у вас
SELECT COUNT(*) AS count FROM {users} WHERE name = '%s'

в модуле user
SELECT COUNT(*) FROM {users} WHERE uid != %d AND LOWER(name) = LOWER('%s')

как видите модуль user не пропустит к регистрации ник demimurych если уже есть зарегистрированный Demimurych.

спасибо за ваш труд

в linux у вас будут те же проблемы что и виндовс.

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

еще

ваша главная ошибка заключается в том что вы упускаете из виду такую вещь как особенности работы файловой системы и используемых в ОС систем кеширования.

самый примитивный пример повторное чтение файла в почти любой nix системе в общем случае не приведет к дисковым операциям.

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

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:

нтересный топик. Вот только если у меня сайт в Украине и рассчитан на 100% на украинскую публику, то до задницы эти тесты из Далласа

именно так.
это именно то о чем я говорил, о большой относительности этих пузомерок.

Все эти пузомерки весьма относительны.

1. гугл легко обманывается отдачей ему статики при приходе их бота, с максимальной скоростью. это если о рейтинге.

2. очевидно что меряться нужно повторными запросами. а не первым. гугл собственно считает так же, только почему то об этом умалчивает. Достаточно посмотреть на их сервисы. да хоть на тот же youtube. и его загрузку с чистым кешем.

"cloudgears" wrote:

еmimurych, так было в старой реализации NotCaptcha, которая под WordPress.

я смотрел пример расположенный на сайте где опубликован модуль.
точнее по ссылке что там была http://cloudgears.com/comment/reply/3#comment-form

Забавная капча.

НО если я все понял верно то:

в текущей ее реализации даже в лоб легко ломаемая.

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

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

"solomenikm" wrote:

Какой будет оптимальным?

два пути. первый посмотреть в ваш штмль чтобы сказать точнее

второй путь более универсальный обрабатывать
$(document).click(function(e)) {

if ($(e.target).hasClass(.views-field-title)) {выполнить что там надо}
}

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

с точки зрения МОИХ привычек. Крайне неудобно.
у меня курсор мыши всегда в центре страницы, и я привык колесом мыши скролить страницу.
а тут попадаю в какой то блок, который визуально МНЕ не дает ощущение того что он перематываемый.
ну это лично мои проблемы.

А вообще
присоединяюсь к Stan.Ezersky.

ознакомьтесь с такой штукой как
http://jqueryui.com/demos/slider/#default

да и вообще
http://jqueryui.com/home

"solomenikm" wrote:

ример на польском: http://bialystok2016.eu/calendar. Подробнее что конкретно?

не оптимальный селектор. впрочем если дом небольшой то и так сойдет.
$(".views-field-title a").click(

"graker" wrote:

upd: А, нет, посмотрел еще раз: вы правы, hook_view можно использовать. Отлично сделано.

ну на самом деле не очень и отлично.
потому что при такой реализации нужно модифицировать хук виев.

а если это сторонний модуль? тогда нужно делать патч к модулю, в случае если хотим как то управлять этим процессом.

сказать опредленно турдно.

на первый взгляд вы ставите друпал 5 ветки на пхп 5.3

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

"graker" wrote:

Вот это здорово.
Еще бы API какой-нибудь в виде хука, чтоб можно было для программно создаваемых типов нод написать обработку - что вставлять в случае эмбеда.

что мешает в хуке node_view
проверить значение поля $node->node_embedded
которая в случае работы это фильтра будет равно TRUE?

"Shift-Web" wrote:

а просто даже повода давать не хочется

выключите компьютер

"Shift-Web" wrote:

Знаете, мне как-то по барабану на кого этот лохотрон. Просто одна мысль о том, что кто-то будет на моем сайте лохотронить мне не по душе ... ну а в целом дело житейское

простите у вас на сайте разрешено аплоадить флеш и тем более его размещать в материалах?

эта глупость сродни разрешению фильтра full html всем пользователям.

"graker" wrote:

Нельзя ли фееричную цитату, где написано, что это правило?

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

чтобы таким образом что то ломать, атакующий должен иметь права на размещение флеша в материале куда атакуемый может зайти.

мало того. атакуемый должен еще произветис клик.

так что простите это не атака. а лохотрон на админа.

"olk" wrote:

Да причем тут быстродействие если ваш запрос дает не правильный результат :)

в моем распоряжении две базы
400 000 нод и 201 000 записей в term_data
128 000 нод и 78 000 term_data

все идет именно так как и нужно.
и четко совпадает с результатами вашего запроса.

Мой запрос может работать неправильно только в двух случаях. Оба случая говрят о том что у вас неверная таблица term_node

в ИЕ8
кнопка f11 (или f12)
можно переключаться между ИЕ7 <-> ИЕ8

режим работы браузера.

"<a href="mailto:screenager@drupal.org">screenager@drupal.org</a>" wrote:

большое спасибо, очень помогли =)

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

достаточно глянуть explain запроса чтобы понять какой ужас ждет сервер при попытке выолнить его.

правильно эта задача решается вот так.

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:

Воспользуйтесь советом natbampo, если человек использует выражение с having, то ему явно можно доверять

нельзя. запрос составлен крайне не оптимально, без понимания того как mysql оптимизирует запросы.