а чего мне общаться то с ними, когда сами защитой занимаемся...
как в том анекдоте - плеск как плеск, впс как впс...
мне кажется нельзя о творческой работе говорить техническим языком... тупой рерайт - замена прямой речи на косвенную и на выходе в любом случае знаков меньше! - работа сугубо техническая, если новостей касаться... если добавлять аналитику какую-то, разбавлять отслеживанием события - работа уже творческая.
если делать рерайт статьи без цитирования, то это плагиат уже называется... речь идет скорее о реферате или еще о чем аналогичном, но тут уже не за знаки платить надо, а за потраченное время или за статью целиком.
Ну я пытаюсь тут до некоторых личностей донести, что лучше бы они эти бабки на Директ тратили бы, но как-то наезды пока только подозрительные... если исполнители засветились по полной и заказчика примерно знаем уже, кто его знает, что запостится в тред через пару дней.
С одной стороны топик этот что бы жертва, которая поднялась, на ответку не пошла... а с другой стороны как сигнал - прекратите дурью маятся... бьют не по паспорту. В любом случае хотелось бы вразумить некоторых личностей, которые реально к этому прибегают.
если кто за ситуацией следит, то не может не заметить, что реклама ddos услуг постепенно исчезает с просторов рунета...
http://int23h.livejournal.com/190657.html - почитайте на досуге, а сколько это урод народу переддосил можно только догадываться. Неплохую работу ребята проделали, так же как и с тем форумом где он рекламился, вполне очевидно.
Так же как и их адреса, телефоны, ФИО, места работы и прочее - все на столько банально, что лишний раз описывать не хочется... из области нефик звонить по мобиле с места преступления.
Да нет, с чего Вы так решили? Ветка деловая на самом деле и речь идет о грязном методе, моем негативном отношении к нему и так же к тем участникам данного форума, которые до этого опустились.
Думаю через пару дней не только намекнут, а еще и скажут кто потенциально тут пропатился... да и по моей статистике концы сюда же приводят.
Смысл в атаке, если она не даёт эффекта... и защита всегда значительно дешевле нападения.
Простите, но речь идет о форумах где рекламируются эти услуги - т.е. вот так открыто висят объявы, с ценами и чуть ли уже не с портофолио. IMHO админы крупных ISP еще пару форумом прибьют и на DDOS будет такое же табу как и на кардинг.
да так, конкуренты по выдаче просто... Дим, а Вы случаем не по "низковольтное ..." там?
А кто дал Вам право так передергивать?
только не ко мне, не к нам и не к нашим ресселерам...
ps. Дима, подозрительно Вы возбудились... а тут на форуме много же написано, ясно же примерно кто за этим стоит... а не по "низковольтное ..." ли там случаем? а вдруг?
Кластер, в том виде который у mysql это зло. Если жахнется хорошо, то потом собирать цельные сутки. Проще изначально предусмотреть распределенную архитектуру, возможно даже с софтовой репликацией. ... или Oracle RAC.
А тут много народу скажет, кто хостил comromat.ru на обычном шареде - статика как статика... не лям хитов конечно, но близко. Остальные ресурсы, со схожей архитектурой, вообще на халяву берут, т.к. трафикогенерилка хорошая - сервер не грузят, а мегабит 10-15 круглые сутки выдают. И самое главное в нужную сторону выдают. А там штук 30 ресурсов и вот уже почти 300 мегабит... самое время кому нибудь их через зарубежку вставить.
Верну к теме.
Прежде всего программист должен внимательнейшим образом изучить RFC, а администратор особенности серверной ОС и программное обеспечение. Не просто так, мануалы почитать, а еще и внимательно просмотреть исходный код. За живое тема просто задевает, т.к. всегда на шаг впереди, а то и на десять. Это не просто так, sql запросы оптимизировать, оно порой бывает и так оптимально все, но из-за самой задачи оптимизация заходит в тупик.
Вот стата в нашем seo модуле под vbulletin, она собирается insert-ами в несколько табличек... по четным периодам в одну, по нечетным в другую. Следовательно когда одна таблица отдыхает, то её обрабатывает, агрегирует и чистит - лучше не придумаешь. А что будет, если mysql не будет справляться с потоком записи? Ну и... ну и... ну и будем писать в fifo, на fifo сборщик/агрегатор и репорты в таблички, неспешно причем - лучше не придумаешь.
Пример - боремся с медленными клиентами. Алгоритм тупой - если у нас все на GET запросах, то на freebsd врубаем accf_http и рестартуем апач, смотрим зацепил ли он его и идем спать. Если кому-то интересно, почему под все остальные методы кроме GET я рекомендую ставить nginx, то идем в сорцы accf_http модуля и смотрим принцип его работы. Как только он видит что-то отличное от GET или HEAD, то он пропускает это сразу, т.е. идет выделение ресурсов для обработки запроса, а запроса, по сути, еще нет.
В данном случае мне приятно на низком уровне это все пояснять, т.к. по этой теме мы давим на всю ивановскую... следовательно accf_http для ресурсов с POST запросами, т.е. к примеру фотогалереи посещаемые и т.д., не является 100% решением. Что у нас происходит на самых низах - приходит куча клиентов с мобильников, с диалапов, да и просто с меговыми фотками и дальше все они занимает один "слот" на нашем веб сервере. Лимит на нашем сервере, к примеру, 200 одновременных подключений. 200 медленных закачек и все, приехали, остальные запросы в очередь, если пик продолжается, то все успешно накапливается пока не сдохнет.
Ставим акселератор, ну пускай это будет squid или еще какая ферма. На что мы натыкаемся... решение универсальное, но опять же пробивается до задника. Народ тыкает рефреши, куки и все остальное - все в rfc описано. Акселераторы, кэширующие особенно, они по большей массе rfc соответствующие или совместимые. Конечно же возможность гибких настроек есть, но надо смотреть по проекту конкретному. Если грамотно присобачить фронт, то можно раскачать производительность в сотни раз.
Программист все хорошо продумал, все замечательно, в локальных кэш-ах браузера все хорошо кэшируется, нагрузка спадает на 70%, реальная цифра. Причем нагрузка по количеству приходящих запросов.
Заказчику стукает в голову добавить динамики какой-то. Как делать правильно, что бы потом не думать - динамику выносим во внешний жабаскрипт, который персонифицирует страницу под посетителя. Кто-то скажет, что это два запроса. Ответ: два запроса в одном tcp соединении - раз, количество залогиненных юзеров можно легко подрезать - два, основная масса по прежнему кэшируется - три, появление страницы в разы быстрее - четыре, юзера довольны - пять, оптимизация поисковая никак от этого не страдает - шесть.
И вот, что бы этим всем профессионально заниматься, надо читать доки, изучать исходники серверного ПО и выбирать оптимальное решение. То, что порой бывает описываю, грозит только проектам с 2-3 тыс конектов одновременно и наплывом в 300-400 новых запросов в секунду. WAP один чего стоит...
Ответ на Ваш вопрос один: обратитесь к профессионалам.
потом кончается место в стойке или начинается нехватка питалова в ДЦ и опять думаем как быть дальше...
Купите землю или недвижимость... а если время есть, то вложитесь в сельское хозяйство - золотое дно сейчас.
ps. А лучше вложите эти деньги в свое образование, тогда и вопросов возникать не будет.
