535i, LIKE видите? Это обычный поиск. Он перебирает и сравнивает все записи.
Жмите кнопочки в админке, переключайте тип поиска. Должна быть поменьше нагрузка.
Не могу точно сказать за DLE, возможно, он продолжит формировать подобные запросы с LIKE, но уже не в поиске, а в других местах.
Если там встречаются часто используемые слова, то их можно внести в специальный список стоп-слов и переиндексировать с помощью REPAIR TABLE. Индекс станет меньше, а скорость поиска больше. Поиск по таким словам не выдаст ничего. Подробности в документации к утилите myisam_ftdump.
Совет с innodb пока отпадает. Sphinx действительно хорош, но с ним больше возни.
535i, так стандартный DLE с использованием LIKE или полнотекстовый с использованием MATCH .. AGAINST ? там можно задать два типа в админке. Запросы покажите, я скажу какой именно используется у вас.
А то sphinx - дело хлопотное. И полнотекстовый поиск в mysql не настолько плох, как о нем думают.
Вообще-то, в dle и так уже есть полнотекстовый поиск. И он не сильно медленнее чем sphinx в масштабах обычного сайта. По крайней мере ускоряет поиск по сайту.
535i, переведи данные в innodb, подними лимиты innodb и само все загонится. Для более быстрого прогрева можно запустить какой-нибудь читающий все строки запрос.
Это принципиально лучше, чем tmpfs, так как исключает межпроцессный обмен данными. Все уже находится внутри innodb pool. К сожалению, может потребоваться больше памяти чем при использовании myisam.
Остальные варианты сложны и непрактичны.
Но раз уж tmpfs не помог, то и этот способ точно не улучшит скорость на порядки.
myhand: Еще раз - то, что Вы предлагаете далеко не так просто. Вспомните хоть, что изменение формата логов потребует reload'а веб-сервера + плюс всего, что парсит эти ваши логи.
А не требует. Я дописываю нужные параметры в конец записи, а awstat прекрасно все жует как ни в чем не бывало.
А тут все просто: на входе запрос - на выходе разрешение/запрет на его дальнейшую обработку. А в промежутке "черный ящик", ваш обработчик, которому всегда доступны параметры запроса - меняйте его логику как и когда удобно.
Ну так и где это решение? Кто его написал? исходя из того, что нормальный программист об интерфейсные заморочки да еще и на С мараться не будет. Хочу просто логику программировать.
Boris A Dolgov: 1) Вероятность того, что один из ста пользователь ната - бот в сто раз больше, чем вероятность того, что пользователь, который хотел пойти к нам на сайт и был заблокирован из-за соседа - бот. В конце концов, никто не отменяет блокировку на FW. Но если, например, за 4 часа пришло 10% ддос-запросов и 90% нормальных, то такой ip нельзя блокировать.
Ах вы про обычный нат. Я то думал вы про NAT на сервере.
Тогда не понимаю причем тут исключения. Конечно, программа читающая логи сможет обработать NAT более удобно.
Andreyka: С DDOS по IP не встречался?
Да, кстати, у меня код, который раньше читал access.log, легко переделался под чтение вывода tcpdump и получилось отражение и syn-флуда и простого бессмысленного udp.
myhand: А что мешает это делать на уровне веб-сервера?
обычно веб-сервер ничего не знает о php-приложении.
myhand: Ну, например, какие еще сейчас запросы вебсервер обрабатывает.
Почти бесполезно. Если обычные запросы не завершаются хотя бы за 5-10 секунд - сайт уже в жопе. Все остальное в логах.
myhand: Собственно, тут уже писали, что не нужно все пихать непосредственно в веб сервер. Можно поставить отдельный обработчик (например, cgi-скрипт), который будет принимать решение о пропуске/отклонении конкретного запроса.
Ну и где взять такое решение? опять писать на C ?
Тут вам предлагают одновременно и просто и безопасно.
535i,или не умеете искать : engine/ajax/find_relates.php , engine/modules/fullsearch.php, engine/modules/show.full.php
535i, у вас какой-то неправильный DLE либо вы не умеете искать. Это поведение переключается нажатием кнопочек в админке.
535i, LIKE видите? Это обычный поиск. Он перебирает и сравнивает все записи.
Жмите кнопочки в админке, переключайте тип поиска. Должна быть поменьше нагрузка.
Не могу точно сказать за DLE, возможно, он продолжит формировать подобные запросы с LIKE, но уже не в поиске, а в других местах.
Если там встречаются часто используемые слова, то их можно внести в специальный список стоп-слов и переиндексировать с помощью REPAIR TABLE. Индекс станет меньше, а скорость поиска больше. Поиск по таким словам не выдаст ничего. Подробности в документации к утилите myisam_ftdump.
Совет с innodb пока отпадает. Sphinx действительно хорош, но с ним больше возни.
535i, так стандартный DLE с использованием LIKE или полнотекстовый с использованием MATCH .. AGAINST ? там можно задать два типа в админке. Запросы покажите, я скажу какой именно используется у вас.
А то sphinx - дело хлопотное. И полнотекстовый поиск в mysql не настолько плох, как о нем думают.
Вообще-то, в dle и так уже есть полнотекстовый поиск. И он не сильно медленнее чем sphinx в масштабах обычного сайта. По крайней мере ускоряет поиск по сайту.
Вы кнопочки-то в админке тыкали?
535i, переведи данные в innodb, подними лимиты innodb и само все загонится. Для более быстрого прогрева можно запустить какой-нибудь читающий все строки запрос.
Это принципиально лучше, чем tmpfs, так как исключает межпроцессный обмен данными. Все уже находится внутри innodb pool. К сожалению, может потребоваться больше памяти чем при использовании myisam.
Остальные варианты сложны и непрактичны.
Но раз уж tmpfs не помог, то и этот способ точно не улучшит скорость на порядки.
alexkv, это не холивар, а критика предрассудков. mysql прекрасно работает и на windows.
тем более в данном случае речь не идет о каких-то сложных запросах. всего лишь хранение данных о пользователях.
настроить shared для внешних подключений может оказаться невозможно.
T.R.O.N, gene6 не портированный.
Что конкретно на винде у вас не срослось с mysql ? помочь?
Еще раз - то, что Вы предлагаете далеко не так просто. Вспомните хоть, что изменение формата логов потребует reload'а веб-сервера + плюс всего, что парсит эти ваши логи.
А не требует. Я дописываю нужные параметры в конец записи, а awstat прекрасно все жует как ни в чем не бывало.
Ну так и где это решение? Кто его написал? исходя из того, что нормальный программист об интерфейсные заморочки да еще и на С мараться не будет. Хочу просто логику программировать.
1) Вероятность того, что один из ста пользователь ната - бот в сто раз больше, чем вероятность того, что пользователь, который хотел пойти к нам на сайт и был заблокирован из-за соседа - бот.
В конце концов, никто не отменяет блокировку на FW. Но если, например, за 4 часа пришло 10% ддос-запросов и 90% нормальных, то такой ip нельзя блокировать.
Ах вы про обычный нат. Я то думал вы про NAT на сервере.
Тогда не понимаю причем тут исключения. Конечно, программа читающая логи сможет обработать NAT более удобно.
С DDOS по IP не встречался?
Да, кстати, у меня код, который раньше читал access.log, легко переделался под чтение вывода tcpdump и получилось отражение и syn-флуда и простого бессмысленного udp.
А что мешает это делать на уровне веб-сервера?
обычно веб-сервер ничего не знает о php-приложении.
Ну, например, какие еще сейчас запросы вебсервер обрабатывает.
Почти бесполезно. Если обычные запросы не завершаются хотя бы за 5-10 секунд - сайт уже в жопе. Все остальное в логах.
Собственно, тут уже писали, что не нужно все пихать непосредственно в веб сервер. Можно поставить отдельный обработчик (например, cgi-скрипт), который будет принимать решение о пропуске/отклонении конкретного запроса.
Ну и где взять такое решение? опять писать на C ?
Тут вам предлагают одновременно и просто и безопасно.