Оптимизация, кэширование и "многокомпьютерность" программы

[Tronyх]

Оптимизация, кэширование и "многокомпьютерность" программы

Вообщем есть задача по написанию достаточно крупного проекта (в планах - 40000+ хостов и 2+ млн. хитов в день). Встаёт вопрос о том как заставить это всё работать максимально быстро и без лишнего геммороя. + Должна быть возможность разнести разные части программы на несколько компьютеров. Какие средства по оптимизации Вы можете посоветовать?

Те способы которые я думаю использовать:
- Компилирование шаблонов
- Везде где это возможное генерация статики
- Кэширование запросов к СУБД
- Постоянное подключение к СУБД
- Какие-то данные получать от демона

На счёт последних 2 пунктов есть вопросы! С помощью каких средств это сделать? Много раз от Тони слышал - SRM... Ещё СРМ в данном случае полезен тем что, код основных библиотек можно хранить на одном сервере и не копировать его на другие. А есть ли другие решения? Есть тесты скорости? Ещё что-нибудь

Использовать СРМ останавливает один ньюанс, для разработки есть всего один комп (дома, я уволился и можно сказать занялся "крупным фрилансом"). Проблема в том, что большая часть сайта работает ТОЛЬКО под ие5.5+. Поэтому поднять *никс для СРМ просто нет возможности. Что посоветуете?

+ если кто использовал SqlRelay тоже поделитесь опытом.

-~{}~ 14.01.05 17:36:

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

 

[MiRacLe]

Поэтому поднять *никс для СРМ просто нет возможности.

*nix можно поставить в pc-эмуляторе (vmware,virtual pc )
как впрочем и наоборот ( винду в эмуляторе)
а можно вообще IE запускать в X-ах (WINE)

хранить данные между запросами удобно (и быстро) можно в [m]memcache[/m]

 

[trent]

зайди на http://tony2001.phpclub.net/ там есть ссылки и на демон, который тебе может пригодиться и шаблонизатор..

 

[Кром]

Можно немного критики?

1. Начинать такой амбициозный проект не зная ответ на заданные вопросы несколько неосмотрительно.
2. Начинать такой проект на домашнем компьютере не имея возможности взять себе другой компьютер под серверную часть или договориться о хорошем хостинге - несколько смешно.
3. Непонятно, как "Постоянное подключение к СУБД" уменьшит нагрузку на сервер. Где то услышали?
4. "Какие-то данные получать от демона" - фраза за которой ничего не стоит. Надо получать - получайте. Еще не факт, что это положительно скажется на производительности.
5. "в планах - 40000+ хостов и 2+ млн. хитов в день". Планы очень часто имеют тенденцию оставаться планами.

Я бы посоветовал просто начать делать проект. А уже потом изучать слабые места и для них - конкретно для них - искать подходящие решения. Те же "кеширования, демоны" и т.д.

 

[Tronyх]

зайди на http://tony2001.phpclub.net/ там есть ссылки и на демон, который тебе может пригодиться и шаблонизатор..

Был и читал. Интересно мнение тех кто его использовал.

Можно немного критики?

Можно

1. Начинать такой амбициозный проект не зная ответ на заданные вопросы несколько неосмотрительно.

Ответы знаю не на все вопросы, и возможно можно сделать что ещё. Мало ли кто каким опытом поделится.

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

Нет желания, сейчас покупать этот самый хостинг. К концу сдачи проекта будет куплен нормальный сервер и он будет размещён у провайдера. А сейчас абсолютно нет желания тратить эти деньги.

3. Непонятно, как "Постоянное подключение к СУБД" уменьшит нагрузку на сервер. Где то услышали?

Ага, услышал... мусор когда выкидывал два бомжа общались )) Не тратится время на создание нового подключения.

4. "Какие-то данные получать от демона" - фраза за которой ничего не стоит. Надо получать - получайте. Еще не факт, что это положительно скажется на производительности.

Те данные которые трудно и долго вычислять... Разумеется не всё подряд.

5. "в планах - 40000+ хостов и 2+ млн. хитов в день". Планы очень часто имеют тенденцию оставаться планами.

Замечательно, и что? Это разговор об успешности проекта и это не мои проблемы. А проблемы маркетолога. А как такая тенденция - "в планах" было оговорено что система это потянет, а потом когда туда пошли эти люди - выяснилось что она не тянет и 4 000 хостов?

Я бы посоветовал просто начать делать проект. А уже потом изучать слабые места и для них - конкретно для них - искать подходящие решения.

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

конкретно для них - искать подходящие решения

Вот именно это я сейчас и делаю.

 

[.R1]

пример

Просто хочу привести пример работы одного сервера с одним проектом.

Есть:
3+ млн. хитов в день
20+ тыс. посетителей

При этом нагрузка CPU в пределах 0.1 - 0.3 (не помню, камень - какой-то средний пентиум 4)

Апач совершенно спокойно выдает по 50 запросов, мускула почти не видно (в процессах)

Для оптимизации использовано кэширование редко меняющихся страниц (раз в сутки), за авторизацию и бан IP отвечает apache (так оно быстрее и надежнее).

Проблема остается лишь с обсчетом статистики. Ясно, что лог немаленький, метров 500. Используется wusage. Не думаю, что статистика из PHP будет быстрее, но зато не скачками.

В идеале можно разнести базу и http-сервер на разные машины. Это к вопросу как "разбить программу".

 

[AnToXa]

----
4. "Какие-то данные получать от демона" - фраза за которой ничего не стоит. Надо получать - получайте. Еще не факт, что это положительно скажется на производительности.

Те данные которые трудно и долго вычислять... Разумеется не всё подряд.
-----

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

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

постоянное подключение к БД часто получается сделать довольно проблематично.
допустим апач, 2M хитов в сутки - это по что-то порядка 300-500(сильно зависит от сложности запросов, может быть и 1500) висящих чайлдов, потихонечку умирают старые и рожаются новые переустанавливая коннекты. получается, что mysql(как самый распространенный вариант) должен удерживать открытыми 500+ коннектов, 500 потоков mysql + 500 апачей + всякие служебные - довольно тяжко.
т.е. как минимум надо выносить базу отдельно.

 

[Tronyх]

за авторизацию и бан IP отвечает apache (так оно быстрее и надежнее).

Спасибо за это! Авторизация только через апач не может у меня идти, а вот бан точно будет.

В идеале можно разнести базу и http-сервер на разные машины. Это к вопросу как "разбить программу".

Это впринципе "стандартный подход". А если больше? например 2 компа со скриптами, при чём не полностью одинаковыми? Я себе это представляю следующим образом - ядро системы одно, а "обёртки" разные. Просто при обновлении ядра на одном из компьютеров делать копию и на второй. Может быть есть что-то более удобное?

постоянное подключение к БД часто получается сделать довольно проблематично.

А если использовать SqlRelay (http://sqlrelay.sourceforge.net/)? Кто-нибудь его использовал?

 

[clevel]

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

 

[ys]

> Может быть есть что-то более удобное?
Почему не использовать, например, NFS?

Кстати, немного не в тему, а стандартный механизм сессий будет работать в случае распределения нагрузки по разным серверам (много A record для одного hostname) и хранения сессионных данных в общем разделе расшареном по NFS?

 

[Tronyх]

Почему не использовать, например, NFS?

А что это?

 

[ys]

Tronyх

Network File System

 

[Yurik]

Крупные американские сайты новостей насколько я читал отдают только статику. Всякие back-endы пишутся на PHP, Java или что-кому угодно (скорость не так важна, даже если на генерацию страницы нужно 30 сек это не столь критично), оно с заданной периодичностью обновляет разные *.shtml части сайта которые Апач отдаёт с небывалой для любого CGI приложения скоростью.
Вся real-time функциональность (форум, подписка etc) выносится на отдельный сервер (часто поддомен)
Для статики (графика, мультимедиа) ещё отдельный сервер.

P.S. странный крупный проект если нету возможности выложить $50 за машинку для тестирования Unix

 

[Tronyх]

Крупные американские сайты новостей насколько я читал отдают только статику. Всякие back-endы пишутся на PHP, Java или что-кому угодно (скорость не так важна, даже если на генерацию страницы нужно 30 сек это не столь критично), оно с заданной периодичностью обновляет разные *.shtml части сайта которые Апач отдаёт с небывалой для любого CGI приложения скоростью.
Вся real-time функциональность (форум, подписка etc) выносится на отдельный сервер (часто поддомен)
Для статики (графика, мультимедиа) ещё отдельный сервер.

Проблема в том, что практически все страницы динамические вопрос именно в их оптимизации. А это на мой взгляд SqlRelay, SRM или memcache. КТО ИСПОЛЬЗОВАЛ ХОТЬ ОДНУ ИЗ ТРЁХ БИБЛИОТЕК??? Поделитесь опытом, плюсами и минусами.

странный крупный проект если нету возможности выложить $50 за машинку для тестирования Unix

Подумал, а ведь и прада! Вложил уже

 

[Screjet]

Как вариант, можно, например, обработчики делать как модули к апаче.
Скорость = потрясающая (правда и стоимость разработки = тоже потрясающая)

Как нечто среднее, для производительности, можно использовать mod_perl или акселераторы для ПХП.

 

[AnToXa]

кстати, NFS довольно тормозная хреновина.

 

[ys]

AnToXa

Это по сравнению с какой сетевой FS?
Вроде их не так много.

 

[AnToXa]

по сравнению со всем локальным.

 

[anight]

apache тормоз, т.к. при большом количестве параллельных запросов получается существенный overhead на context switches
nfs тормоз сам по себе но еще и много глюков

 

[AnToXa]

ну а теперь с появлением fastcgi в nginx, так ваще выбор очевиден