| 1.1, Аноним (-), 17:55, 18/05/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Не круто. Сегодня трабл в тяжлелых беках, а не в медленных клиентах.
Бекенд - что угодно: апач, лайт, нжынкс, которые ворочают приложения.
Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апача
А вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".
Первый клиент вносит станицу в кеш mod_accel'я, остальные 15000 получают ее со скоростью света не трогая SQL.
Вот это будет реальное ускорение и, что важнее, рост нагрузочной способности сервера. Так это от 10 раз. А в смысле нагрузочной способности и до 1000 раз по сравнению с описанной "двуслойкой".
Обновление контента скриптиком - апачктл стоп рм дерево кеша криейт дерево кеша апачктл старт. Причем если бекенд умер - самые популярные страницы (запрошенные больше одного нуля раз :) будут сдаваться аккселем, как новенькие :)
| | |
| |
| 2.2, alrond (??), 18:31, 18/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
годится только для тех, кто только select иногда в базу делает
а что делать движкам форумным? | | |
| |
| 3.6, citrin (ok), 20:04, 18/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
 >Так вы батенька забудьте про статические HTML-страницы...редкость уже давно,
>годится только для тех, кто только select иногда в базу делает
>а что делать движкам форумным?
90% процентов CMS, формов и прочего веб-софта написаны очень неоптимально с точки зрения производительности...
А на крцупных веб-порталах статики гораздо больше...
а делать select в базу на каждый запрос это дорого, и не всегда нужно. | | |
|
| 2.5, citrin (ok), 20:01, 18/05/2006 [^] [^^] [^^^] [ответить]
| +/– | |
что то вы как то путаетесь.
> Сегодня трабл в тяжлелых беках, а не в медленных клиентах.
nginx как раз таки и нужен, чтоб изолировать медленных клиентов (а они думаю всегду будут медленне бэкендов), от тяжелых бэкендов. Чтоб бэкенд мог отдавать данные за минимально возможное время, а потом nginx медленно отдавал эти данные клиенту.
> Нжынкс и лайт на ПХП могут оказаться СИЛЬНО быстрее апача
в nginx нет встренной поддержки php. и не будет. Можно запустить php в режиме fastcgi (а запросы на fastcgi направлять через реверсный прокси, например nginx) только это не будет сильно быстрее mod_php. Вполне возможно будет даже медленне, чем mod_php+apc.
> А вот фронт - сысоевский же mod_accel с выставленными "кешировать ВСЕ (за разумным исключением) и НАВСЕГДА".
1. кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
2. чаще кеширование удобно выполнять не на уровне http, а на уровне приложений - через memcached.
| | |
| |
| 3.10, Аноним (-), 09:56, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
Вот это единственное здравое суждение в вашей дикой чуши, но только оно даст прирост силы в 0.1% | | |
| |
| 4.11, Аноним (-), 09:59, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
>> кэширование это хорошо, только mod_accel это тяжелый апач и от клиентов его все равно лучше прятать за ngix.
>
>Вот это единственное здравое суждение в вашей дикой чуши, но только оно
>даст прирост силы в 0.1%
И вообще. Есть такая фтуська, ПРАКТИКА называется.
То есть, сначала сделай, а потом трынди.
Но за искючением 1. Автора новости 2. Меня 3. Хольсера
потоки сознаний самовыражающихся тута практикой не страдают. | | |
| 4.13, gvy (?), 12:25, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Зуб дадите? Двести апачей на десять болтающихся поменять -- это 0.1%?
Трепло безымянное. | | |
| |
| 5.14, Аноним (-), 12:52, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– | |
> Зуб дадите? Двести апачей на десять болтающихся поменять -- это 0.1%?
Да. У меня 8 ядер в 4 гигах озу. Мне до лампочки глубоко миллион там апачей или 10 тыщ.
А вот бек - ТЯЖЕЛЫЙ.
| | |
|
|
| 3.15, Аноним (-), 12:58, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
>2. чаще кеширование удобно выполнять не на уровне http, а на уровне
>приложений - через memcached.
А на уровне написания пропертиарной ОС ничего не надо? Совсем ничего? Нет?
А то еще можно новый проц изобрести... Или хрустальный мост с голыми девушками на бензиновом приводе...
| | |
| 3.17, Аноним (-), 13:04, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Какие-то костыльно-кувалдные у Вас подходы, батенька. Для моих нагрузок хватает как
>раз nginx+apache и мультикэширующей CMS (в принципе, оно и static export
>умеет, но не требуется), а вот с таким вебмастером на одной
>зоне ответственности работать бы поостерёгся.
А вот у меня CMS пропертиарная. С КРАЙНЕ интенсивным объемом вычислений на беке.
Посоветуйте дуракам, загружающим Ёс Симулятор, "мультикэширующий CMS",
"изначально задумывать оптимизацию" и "сразу задачу нормально"
| | |
| |
| 4.19, gvy (?), 19:41, 19/05/2006 [^] [^^] [^^^] [ответить]
| +/– |
>А вот у меня CMS пропертиарная.
ССЗБ. И писать учитесь :) | | |
|
|
|
| 1.3, Аноним (-), 18:48, 18/05/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Движкам форумным - лайт с удаленным фаст-сижиаем. Можно прокисровать нжынксом, можно не проксировать - плюс-минус полпроцента. | | |
| 1.8, Holser (?), 02:02, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Поверьте мне, как специалисту, это похоже на создание формулы 1 из Запорожца. Если изначально не задумывалась оптимизация (а о ней почему то думают в самый последний момент), но ни какой nginx не поможет. Я видел очень грамотные сайты написанные с использованием Java и в качестве сервера jBoss, которые выдавали 1000 запросов к базе в секунду, и запросы не просто Select, в целом не создавая нагрузку на frontend сервер. Я проверил и статика составлят 5%, в основном картинки, а основную нагрузку создает SQL сервер, вот здесь и поле для оптимизации. В данном контретном случае все закончилось созданием MySQL EMIC кластера, в конечном счете обошлось дешевле исли бы 2 программиста оптимизировали и затачивали код. Лицензия покупалась у continuent.com. Но самый главный вывод, все должно расматриваться с точке рентабельности. Если мне прийдется заплатить 10k за работу и ждать результата год, тогда лучше купить железо и создать кластер. | | |
| 1.16, Doktor (??), 13:03, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
2Vaso Petrovich, все меняется... и нужно соотвествовать текущим задачам. | | |
| 1.18, edgars (??), 19:38, 19/05/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
horosho tak, a vot tak tufta, a vot ja by zdelal tak i poluchili by vse 500% uskorenija. Tak davaite pokazhite pozhaluisto vash manual/howto da vsjoravno shto, no rabotosposobnoje, a to besit vot takuju chush chitacj! | | |
| 1.21, Виктор Куряшкин (?), 03:04, 01/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Хм..
апач на обработку одного запроса использует один процесс.
Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если одновременных клиентов 1000 - то процессов апача будет 1000 как минимум, а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю, выгода от выделения frontend-сервера очевидна.
Другой пример - всегда есть достаточно много статики. Картинки, цсс, яваскрипты. И этой статики будет всегда дофига. Для нее выгода от nginx так же очевидна.
Что касается динамики. Да, кешировать всю динамику глупо. Ну и что? Самостоятельно разрабатывать кеширующий слой обычно дороже. По крайней мере, он не замедлит работу, а в случае, когда вам не нужно порождать дополнительные апачевские процессы за счет выигрыша в остальном - только поможет.
Так что, в случае LAMP - имеет смысл использовать nginx если проект отличается от "Газеты вечерний Вуглускр".
Лично по моему опыту - могу сказать, что получил выигрыш около 70% (!) Статики при этом совсем немного.
Victor Kuriashkin
| | |
| |
| 2.22, Michael Shigorin (ok), 09:42, 01/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Вырожденный случай (но реальный) - клиенты скачивают большие файлы по http. Если
>одновременных клиентов 1000 - то процессов апача будет 1000 как минимум,
>а они тяжелые. Они будут висеть, пока клиенты качают. Тут, думаю,
>выгода от выделения frontend-сервера очевидна.
Тут как раз очевидна выгода от выделенного под статику шустрого простого сервера и неиспользования для неё apache вообще :) Будь это виртхост или /download.
>Лично по моему опыту - могу сказать, что получил выигрыш около 70%
>(!) Статики при этом совсем немного.
Очень сильно помогает на "висяках" память экономить -- браузер ещё сидит на keepalive, но уже ничего не спросит [какое-то время].
| | |
|
|
