Создание высоко-нагруженного проекта.

cDLEON

Онанист РНРСlub
Создание высоко-нагруженного проекта.

Вот появилась вот такая вот задача 8) Хочется написать вот такое вот апи...Нагрузко-устойчивое :)
Возникла масса вопросов :)
1) MemCache
a) На сколько оправдана работа с этим чудом ?
б) Как оно себя поведёт, если перестанет хватать оперативы ?
в) Что вообще можно хранить в нём? Помимо "глобальных" значений. Которые смогут юзать все пользователи ?
г) Если хранить "Сессионо-зависимые" данные, память при ХТТП-флуде забьётся... Какой выход ?
д) Чем memCache отличается от мускуля с таблицами, которые храняться в оперативе ? Разве так много плюсов ?
2) SQL
а) Что делать с "тяжёлыми" сессионо-зависимыми запросами?
б) Кеширование SQL запросов. А стоит ли ? На мой взгляд, эти данные должен кешировать шаблонизатор....
3) Шаблонизатор.
а) Как удалять "устаревший" кеш ? Тупо запускаться(из скрипта, который выполняется юзверем) 1-ин раз в минуту(предположим) и чистить всё, что считается мусором? А если кеша в результате ХТТП флуда получилось пару миллионов файликов ? Чистить по крону?
б) Какая практика по кешированию наиболее "устоявшееся" в таких проектах ?
4) Поисковая часть.
а) Некоторые модули должны будут учавствовать в поиске. Как лучше всего с малой кровью стандартизировать все модули для поиска ? И вообще, как лучше всего это сделать ? На нужные поля форм, например, добавлять обработчик, который будет инсертить в базу ключевые слова ? Как быть с ссылками на эту ахинею ? :)
5) Какие ещё есть хорошие технологии, подводные камни и проч, чего я не перечислил ?

ЗЫ. Пожалуйсто, не нужно разговаривать про велосипеды :( В рабочих проектах я это не использую, а писать собираюсь для себя - что бы не потерять интерес к программированию....
 

dr-sm

Новичок
Re: Создание высоко-нагруженного проекта.

д) Чем memCache отличается от мускуля с таблицами, которые храняться в оперативе ? Разве так много плюсов ?
ну например nginx умеет контент брать напрямую из мемкеша.
что соотвецтвенно позволяет значительно сократить число тяжелых обращений к бекенду.
 

cDLEON

Онанист РНРСlub
ну например nginx умеет контент брать напрямую из мемкеша.
Помоему бред хранить целые страницы в памяти 8)
ЗЫ. Как то не пользуется популярностью топик :(
 

cDLEON

Онанист РНРСlub
После таких заявлений именно так и будет
намёк понял - пойду почитаю про использование мемкэйч с помощью НГИНКС. Но вообще, я думал, что если что поправите....
А что, у меня все вопросы такие дуратские ?
 

Wicked

Новичок
цДЛЕОН, по-правильному "НГИНКС" следует называть как nginx или энджиникс
 

cDLEON

Онанист РНРСlub
ДЛЕОН, по-правильному "НГИНКС" следует называть как nginx или энджиникс
А мыне больше нравится ЭН-ГЭ-ИНКС :D
Ps. Полазил, полазил.... Почитал. Не въехал, в суть вот этого:
а про целые страницы никто и не говорил
Гыде здесь не целая страница кешируется в этой связке ?

-~{}~ 23.05.08 18:48:

Спасибо фишер, очень интересные заметочки 8)

ЗЫ. Всегда стремился к тому, что бы потреблять всегда меньшее количество оперативной памяти....И, даже, считал не приличным использовать лишнее....
Я старомоден?
 

MiksIr

miksir@home:~$
Нелья к чему-то стремиться, не имея задачи. Именно за это архитекторам и платят деньги - они говорят, куда стоит стремиться.

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

Кеширование целых страниц - это правильное решение при определенных условиях, если понимать, что целая страница - это не обязательно от <HTML> до </HTML>, это может быть блок на страницу. При разработке своего проекта мы научили движок класть результат запроса в статику, и ему пофиг что было результатом запроса - полная страница или маленький блок. А дальше сборкой из статики уже занимается nginx с помощью банального SSI.

При сильной нагрузке на дисковую систему, когда файловый кеш не справляется с горячим контентом, можно делать частотный анализ и класть горячий контент в мемкеш, а можно сделать вирутальный диск в памяти и перемещать его туда - варианты есть, и какой применить зависит от архитектуры и архитектора ;)
 

dr-sm

Новичок
Автор оригинала: cDLEON
Гыде здесь не целая страница кешируется в этой связке ?
hint: SSI :)

ЗЫ. Всегда стремился к тому, что бы потреблять всегда меньшее количество оперативной памяти....И, даже, считал не приличным использовать лишнее....
Я старомоден?
дело в том, что из памяти отдавать параллельно можно значительно больше, чем с винтов.

-~{}~ 23.05.08 19:10:

MiksIr опередил меня )
 

cDLEON

Онанист РНРСlub
Так, день обучения прошёл успешно 8)
Завтра поправлю все свои вопросы 8) Надеюсь, топик получится более конструктивным )))
А то действительно как то не уважительно отнёсся )))
Спасибо всем ))
 

Alexandre

PHPПенсионер
Например, экономия в памяти выльется в повышенную нагрузку на сервер БД,
ну, как правило сервера БД имеют максимально заполненные слоты памяти. Выше ж.. не прыгнешь, если сервер расчитан на 8Гб то как ни ухитрись, то 10 уже не вставишь... меняйте мать, меняйте проц... и.т.д.
но и на спичках экономить не нужно.

-~{}~ 25.05.08 18:21:

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

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

Garret

Кто здесь?
1) MemCache
a) Зависит от задач
б) Можешь сам настроить, будет или удалять самые старые данные или отклонять сохранение новых
в) Все кроме идентификаторов ресурсов
г) Не хранить их или чистить кэш, зависит от задачи
д) В мэмкэшед немного другой смысл закладывался, плюсов хватает
2) SQL
а) Оптимизировать
б) Смотря какие запросы, чаще всего стоит

-~{}~ 26.05.08 15:05:

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Re: Создание высоко-нагруженного проекта.

> a) На сколько оправдана работа с этим чудом ?
думаю, ты знаешь варианты ответа на подобные вопросы :)

> б) Как оно себя поведёт, если перестанет хватать оперативы ?
RTFM

> в) Что вообще можно хранить в нём? Помимо "глобальных" значений.
RTFM

>Которые смогут юзать все пользователи ?
очередной "высоко-нагруженный" проект на публичном хостинге?!

> г) Если хранить "Сессионо-зависимые" данные, память при ХТТП-флуде забьётся... Какой выход ?
48

> д) Чем memCache отличается от мускуля с таблицами, которые храняться в оперативе ?
RTFM

> а) Что делать с "тяжёлыми" сессионо-зависимыми запросами?
RTFM
> б) Кеширование SQL запросов. А стоит ли ? На мой взгляд, эти данные должен кешировать шаблонизатор....
RTFM
> а) Как удалять "устаревший" кеш ...
RTFM

> б) Какая практика по кешированию наиболее "устоявшееся" в таких проектах ?
единственно реальная

> Как лучше всего с малой кровью стандартизировать все модули для поиска ?
учесть возможность кеширования при проектировании архитектуры

> И вообще, как лучше всего это сделать ?
прочесть и понять документацию

>5) Какие ещё есть хорошие технологии, подводные камни и проч, чего я не перечислил ?
называется "чтение" - лучшая технология со времен средневековья

>писать собираюсь для себя - что бы не потерять интерес к программированию....
глобальная цель, memcache тут не справится

высоконагруженный проект на хостинге для себя не делают :)
 

cDLEON

Онанист РНРСlub
очередной "высоко-нагруженный" проект на публичном хостинге?!
НЕД. Пишу сервер для АДСЛ модемоФ и что п БЕЗ РАЗРЫВОВ!!!
ЗЫ. Я всё ни как не могу найти время на обнавление этого топа как и обещал. :(
 
Сверху