согласен - в некоторых случаях реаллокейты возникают из-за программных сбоев, но зачем гадать? - ждать и надеяться, что продакшн сервер отработает честно свои 1.5-2 года (и будет заменен на новый), я еще понимаю, когда 1-2 реаллокейта через полгода-год, но если уже в первый день видно реаллокейты? 🚬
pupseg: Если у вас 512Мбайт памяти, 1000Мгц процессор и вы хотите загнать на ваш ресурс 100 000 посетителей за сутки, то никакие пляски с бубном вам не помогут кроме наращивания аппаратной производительности.
помогут, почему не помогут, 100к посетителей это не какая-то бешенная циферка, если VPS конечно несильно порезана в плане tcp-стека, все зависит от CMS, от объема взаимодействия посетителей с ней и т.п., т.е. если это просто "новостной" сайт, то nginx + кеширование динамики (хотя бы на 5 минут) и эти 100к пройдут как отработка статики 🍿
а если ддосеры, например, начали с 15Гбит и дойдя до 50Гбит увидели, что задача выполнена, - зачем им засвечивать большее число ботов? - они остановятся на 50Гбитах, и подливать будут ровно столько, сколько необходимо для выполнения задачи, т.е. в данном случае уместно сказать "ахерабит" (как это сделал kostich), так как никто не знает сколько гигабит реально могли "подать" ддосеры 🍿
Raistlin: seocore, То, что они используют еще не значит что оно именно для ваших целей лучше.
почему нет? - цели одни - максимум производительности и надежности при минимуме затрат 🚬
Raistlin: Демоненок, Лишними - нет. А вот смысла не иметь - вполне могут. Опять же вы знаете, что у него за сервер? Может там VDS с 300 мегабайт оперативки. Какие к черту nginx и акселератор, там и так ресурсы все на счету?
ну вы просто неправильно подходите к вопросу - если eAccelerator позволит в 3 раза быстрее отрисовать страничку и при этом освободить ОЗУ для нового запроса, то очень даже будет кстати на слабых конфигурациях
про nginx я вообще молчу, насколько экономно для ОЗУ он отдает статику, по моему уже никому рассказывать не надо :D
WebAlt: ТС, почему XCache вместо eAccelerator не рассматриваете?
присоединяюсь к вопросу :)
Bazis007: eAccelerator кэширует интерпретированный бинарник, и при очередном запросе на запуск скрипта смотрит : менялся ли PHP-скрипт(по дате, если память не изменяет).
ну на деле это не конечный бинарник, а только некая форма R-кода, что-то в духе - компиленного Java-апплета :)
а смотрит за изменениями не по дате, а через полуоткрытые файлы, т.е. любая запись в файл и ОСь информирует приложение открывшее файл, о том, что файл открыт на запись другим приложением 🚬
Raistlin: Или lighttpd не знаете? Ничем не хуже джинкса, зато может больше апача и умеет почти все то же. Почитайте...
вот yandex и rambler используют nginx, ну эти люди тоже про lighttpd знают, и даже его "варить умеют", но все равно юзают nginx, видимо nginx лучше 🚬
skyscr: как какая разница, worker делает многопоточность из скриптов, а prefork ждет каждый скрипт и из-за этого надежнее workera, но тормознее... или я не прав, Вы же админ =)
skyscr добавил 14.10.2010 в 19:33 как понял мне поможет "sudo apt-get install apache2-mpm-worker"
причем тут mpm? - вы же пишете, что картинки многопоточно не грузит, они же у Вас nginx'ом раздаются :D
вообще prefork и надежнее, хотя и несколько тише, в случае, если статику раздает nginx вы от worker'а не только плюса не получите, а наоборот кучу проблем поимеете :)
по всей видимости keepalive надо крутить, nginx очень хочет отдать все картинки через одну сессию (как совет - уменьшите таймаут keepalive'а до 2-5 секунд)
LineHost: Посылай нафик этот дц, так как они тебе вешают макароны.
присоединяюсь, очень похоже на сказки со стороны ДЦ
LineHost: Prolexic вчера хвастался, что они сталкивались с 103 gbps атакой ;)
возможно, там у них в моде хвастаться рисованными циферками, как пример - берут объем средней белой TCP-сессии, потом просто умножают на количество потенциальных сессий (которые они зарубили на SYN-стадии), а учитывая еще Keep-Alive, там возникают просто геометрические такие величины в якобы 100-300Гбит отбитых атак :D
skyscr: что не хватает для ещё большей скорости fcgi или кажется? =)
в скорости много не выиграете, ОЗУ сэкономите более менее, но нестабильность и непрозрачность все плюсы сведут на нет
лучше покрутите в nginx кеширование и закешируйте малоактивную динамику, те же товары в магазине можно закешить аккуратно, так чтобы не задеть POST/COOKIE
skyscr: поэтому не скажу плохо о Жумле, тк аналогов в её универсальных способностях и количестве разных фишек не вижу
тоже самое скажут любители DLE, WP, Drupal :D
skyscr: Почитал кучу западных статей и сравнений, везде почему-то больше хвалят eAcc+Memcache....
если все будет вращаться локально, то зачем memcache? - работа через сетевой стек всегда будет проигрывать по скорости и ресурсоемкости c тем же eaccelerator_put/eaccelerator_get или xcache_put/xcache_get, я за eaccelerator но в последних версиях убрали eaccelerator_put/eaccelerator_get из него, поэтому альтернативное решение - xcache, на мой взгляд, более интересное решение, чем связка eaccelerator+memcache :)
skyscr: и если с mod_php+xcache всё ясно, то почему nginx не оставить без apache?
на вкус и цвет :D - просто на мой взгляд apache(mpm-itk) + mod_php более стабильны и просты
Важно не количество, а динамика прироста.
согласен - в некоторых случаях реаллокейты возникают из-за программных сбоев, но зачем гадать? - ждать и надеяться, что продакшн сервер отработает честно свои 1.5-2 года (и будет заменен на новый), я еще понимаю, когда 1-2 реаллокейта через полгода-год, но если уже в первый день видно реаллокейты? 🚬
Если у вас 512Мбайт памяти, 1000Мгц процессор и вы хотите загнать на ваш ресурс 100 000 посетителей за сутки, то никакие пляски с бубном вам не помогут кроме наращивания аппаратной производительности.
помогут, почему не помогут, 100к посетителей это не какая-то бешенная циферка, если VPS конечно несильно порезана в плане tcp-стека, все зависит от CMS, от объема взаимодействия посетителей с ней и т.п., т.е. если это просто "новостной" сайт, то nginx + кеширование динамики (хотя бы на 5 минут) и эти 100к пройдут как отработка статики 🍿
По официальным сведениям Arbor самая мощная атака, которая была зафиксирована 49Гбит/с:
http://www.arbornetworks.com/en/arbor-networks-releases-fifth-annual-infrastructure-security-report-2.html
по не официальным сведениям - 80Гбит/с.
а если ддосеры, например, начали с 15Гбит и дойдя до 50Гбит увидели, что задача выполнена, - зачем им засвечивать большее число ботов? - они остановятся на 50Гбитах, и подливать будут ровно столько, сколько необходимо для выполнения задачи, т.е. в данном случае уместно сказать "ахерабит" (как это сделал kostich), так как никто не знает сколько гигабит реально могли "подать" ддосеры 🍿
Мне расскажите... ))). Ну не знаете вы, чем отличаются prefork и worker, так почитайте хоть :).
не хочу продолжать спор, но nginx будет работать экономнее 🍿
seocore, То, что они используют еще не значит что оно именно для ваших целей лучше.
почему нет? - цели одни - максимум производительности и надежности при минимуме затрат 🚬
Демоненок, Лишними - нет. А вот смысла не иметь - вполне могут. Опять же вы знаете, что у него за сервер? Может там VDS с 300 мегабайт оперативки. Какие к черту nginx и акселератор, там и так ресурсы все на счету?
ну вы просто неправильно подходите к вопросу - если eAccelerator позволит в 3 раза быстрее отрисовать страничку и при этом освободить ОЗУ для нового запроса, то очень даже будет кстати на слабых конфигурациях
про nginx я вообще молчу, насколько экономно для ОЗУ он отдает статику, по моему уже никому рассказывать не надо :D
ТС, почему XCache вместо eAccelerator не рассматриваете?
присоединяюсь к вопросу :)
eAccelerator кэширует интерпретированный бинарник, и при очередном запросе на запуск скрипта смотрит : менялся ли PHP-скрипт(по дате, если память не изменяет).
ну на деле это не конечный бинарник, а только некая форма R-кода, что-то в духе - компиленного Java-апплета :)
а смотрит за изменениями не по дате, а через полуоткрытые файлы, т.е. любая запись в файл и ОСь информирует приложение открывшее файл, о том, что файл открыт на запись другим приложением 🚬
Или lighttpd не знаете? Ничем не хуже джинкса, зато может больше апача и умеет почти все то же. Почитайте...
вот yandex и rambler используют nginx, ну эти люди тоже про lighttpd знают, и даже его "варить умеют", но все равно юзают nginx, видимо nginx лучше 🚬
как какая разница, worker делает многопоточность из скриптов, а prefork ждет каждый скрипт и из-за этого надежнее workera, но тормознее... или я не прав, Вы же админ =)
skyscr добавил 14.10.2010 в 19:33
как понял мне поможет
"sudo apt-get install apache2-mpm-worker"
причем тут mpm? - вы же пишете, что картинки многопоточно не грузит, они же у Вас nginx'ом раздаются :D
вообще prefork и надежнее, хотя и несколько тише, в случае, если статику раздает nginx вы от worker'а не только плюса не получите, а наоборот кучу проблем поимеете :)
по всей видимости keepalive надо крутить, nginx очень хочет отдать все картинки через одну сессию (как совет - уменьшите таймаут keepalive'а до 2-5 секунд)
Посылай нафик этот дц, так как они тебе вешают макароны.
присоединяюсь, очень похоже на сказки со стороны ДЦ
Prolexic вчера хвастался, что они сталкивались с 103 gbps атакой ;)
возможно, там у них в моде хвастаться рисованными циферками, как пример - берут объем средней белой TCP-сессии, потом просто умножают на количество потенциальных сессий (которые они зарубили на SYN-стадии), а учитывая еще Keep-Alive, там возникают просто геометрические такие величины в якобы 100-300Гбит отбитых атак :D
что не хватает для ещё большей скорости fcgi или кажется? =)
в скорости много не выиграете, ОЗУ сэкономите более менее, но нестабильность и непрозрачность все плюсы сведут на нет
лучше покрутите в nginx кеширование и закешируйте малоактивную динамику, те же товары в магазине можно закешить аккуратно, так чтобы не задеть POST/COOKIE
поэтому не скажу плохо о Жумле, тк аналогов в её универсальных способностях и количестве разных фишек не вижу
тоже самое скажут любители DLE, WP, Drupal :D
Почитал кучу западных статей и сравнений, везде почему-то больше хвалят eAcc+Memcache....
если все будет вращаться локально, то зачем memcache? - работа через сетевой стек всегда будет проигрывать по скорости и ресурсоемкости c тем же eaccelerator_put/eaccelerator_get или xcache_put/xcache_get, я за eaccelerator но в последних версиях убрали eaccelerator_put/eaccelerator_get из него, поэтому альтернативное решение - xcache, на мой взгляд, более интересное решение, чем связка eaccelerator+memcache :)
и если с mod_php+xcache всё ясно, то почему nginx не оставить без apache?
на вкус и цвет :D - просто на мой взгляд apache(mpm-itk) + mod_php более стабильны и просты