запросы могут быть которкими могут быть не очень — всего от пользователей в сутки до каше доходит порядка 700 000 запросов — остальное обслуживается мемкешем
200 — 300 тысяч обращений к глобалам — это конечно много, я стараюсь что бы такого количества не было — но в целом, если страница не в индексе то её придётся создавать — и тогда (если вы под обращением к глобалу вы подразумеваете одну операцию сет гет или ордер) — то количество этих обращений будет даже более, дело в том что фактически на Каше у нас реализован также бекенд — то есть возвращается xml готовой страницы, для которой внутри каше дополнительно вызывается xslt преобразование — по сути каше отдаёт уже готовый html
хорошие у вас сервера))) нам пока приходится обеспечивать 50 000 пользователей в сутки на 40 ядрах и 40 ГБ оперативы (это для всей системы мастер слейвовы фронтенд и фотобанк)
но спасибо за совет буду знать с чем столкнусь в дальнейшем!
ещё вопрос насчёт своих индексов, это понятно — в прямом доступе других индексов и быть не может, возможно есть рекомендации о глубине индексного глобала — то есть что дешевле ^a(index1,index2) или ^a1(index) ^a2(index) и тому подобные вопросы — то есть когда операция merge — становится настолько долгой что быстрее выполнить ордер и сет (с этим я сталкивался в реальной жизни на относительно небольших глобалах) что быстрее ордер или квери например для одноуровнего глобала (понимая что они выполняют разные действия)?
кажется длинные строки встречаются только в глобалах содержащие кашевские программы — это может влиять на производительность имеет смысл переписывать программы что бы там не было строки длинной более 8 КБ?
100GB оперативы мы пока что себе позволить не можем
спасибо — этот способ мне был известен, думал может вы знаете како-то секрет:) — в том-то и проблема что фактически кашетепм никак не удалить без остановки — другие БД можно прямо в процессе — переконфигурировать и удалить (если использовать их как временные) — например у нас есть tempNamspase — tmpBD — мы создаём newtmpBD — указываем её как основную БД для tempNamspase — а tmpBD удаляем — прелесть в том что это может делать скрипт автоматом без остановки системы а с кашетепм такой фокус не покатит.
а как размер буфера (я так понимаю это объём памяти выделенный под 8КБ кеш) может значительно превышать размер CacheTemp если эта БД у меня весит порядка 10ГБ — и вот ещё вопрос каким образом её можно чистить что бы она место на диске не кушала — стандартными средствами ничего не выходит — очищается пару десятков метров и всё?
ого! я уж думал сам писать про каше но раз вы первый тогда спрошу: как отследить единичную операцию записи данных в WIJ файл? есть ли какие-то рекомендации или рецепты по использованию ещё «более прямого» доступа к данным — то есть запись/чтение делать не применительно к глобалам а сразу к блокам? есть у вас такой опыт? что рекомендуете почитать? есть ли статьи о проектировании и конфигурировании структур данных не на объектах и не на SQL — а с использованием прямого досутпа? реальные проекты с прямым доступом большие БД хотя бы десяток тысяч уникальных ежедневных пользователей?
Как правильно настраивать память в каше, что такое кеш 2КБ и чем он отличается от кеша 8КБ (у меня например основной объём памяти выделен под 8КБ кеш — а под 2КБ чуть более чем ноль — может я не прав?)
Как отслеживать эффективность кеша (то есть цифру в портале управления я вижу) — каким образом можно на неё влиять? имеет ли смысл подогревать глобалы самостоятельно — или лучше оставить это на совести у системы?
Всё по прямому быстрому и ещё более быстрому доступу безо всяких скл объектов цсп и прочей лабуды быстрее быстрее быстрее — все что знаете. Спасибо.
Читал и думал что Пелевин выкатывает главы своей новой книги — очень хорошо написано «вау» и прочие факторы соединены с описанием надчеловеческого (надсистемного для человека) организма. Рад за Хабр — ради такого его стоит продолжать читать.
вопрос насчёт «расширения своих собственных возможностей практически неограниченно»?
а мы знаем куда расширять наши возможности, в каком направлении?
а мы знаем зачем их расширять, с какой целью?
нам не хватает текущих наших возможностей?
эти вопросы вызваны не страхом и не желанием затормозить прогресс — не поймите привратно — эти вопросы вызваны скорее попыткой переориентации из модели «не хватает рекрутов Сэр!» (энергии, ресурсов, возможностей) — в модель «каким наилучшим образом использовать то что есть сейчас» — и отвечая на этот вопрос — находить ответы на вопрос что нам ещё необходимо чего у нас сейчас нет и что нам нужно получить исследовать узнать познать из области неизвестного…
200 — 300 тысяч обращений к глобалам — это конечно много, я стараюсь что бы такого количества не было — но в целом, если страница не в индексе то её придётся создавать — и тогда (если вы под обращением к глобалу вы подразумеваете одну операцию сет гет или ордер) — то количество этих обращений будет даже более, дело в том что фактически на Каше у нас реализован также бекенд — то есть возвращается xml готовой страницы, для которой внутри каше дополнительно вызывается xslt преобразование — по сути каше отдаёт уже готовый html
но спасибо за совет буду знать с чем столкнусь в дальнейшем!
спасибо — этот способ мне был известен, думал может вы знаете како-то секрет:) — в том-то и проблема что фактически кашетепм никак не удалить без остановки — другие БД можно прямо в процессе — переконфигурировать и удалить (если использовать их как временные) — например у нас есть tempNamspase — tmpBD — мы создаём newtmpBD — указываем её как основную БД для tempNamspase — а tmpBD удаляем — прелесть в том что это может делать скрипт автоматом без остановки системы а с кашетепм такой фокус не покатит.
Как правильно настраивать память в каше, что такое кеш 2КБ и чем он отличается от кеша 8КБ (у меня например основной объём памяти выделен под 8КБ кеш — а под 2КБ чуть более чем ноль — может я не прав?)
Как отслеживать эффективность кеша (то есть цифру в портале управления я вижу) — каким образом можно на неё влиять? имеет ли смысл подогревать глобалы самостоятельно — или лучше оставить это на совести у системы?
Всё по прямому быстрому и ещё более быстрому доступу безо всяких скл объектов цсп и прочей лабуды быстрее быстрее быстрее — все что знаете. Спасибо.
а мы знаем куда расширять наши возможности, в каком направлении?
а мы знаем зачем их расширять, с какой целью?
нам не хватает текущих наших возможностей?
эти вопросы вызваны не страхом и не желанием затормозить прогресс — не поймите привратно — эти вопросы вызваны скорее попыткой переориентации из модели «не хватает рекрутов Сэр!» (энергии, ресурсов, возможностей) — в модель «каким наилучшим образом использовать то что есть сейчас» — и отвечая на этот вопрос — находить ответы на вопрос что нам ещё необходимо чего у нас сейчас нет и что нам нужно получить исследовать узнать познать из области неизвестного…