кэширование данных

[SergXP]

Всем привет!
Задача не совсем для начинающих, больше к профи)
Все мы рано или поздно сталкиваемся с быстродействием кода.
При обработки тяжелых массивов и SQL запросов, сильно грузится процессор.
К тому же при больших массивах, жрется и память.
Отсюда более длительное время генерации страницы и страшное пожирание памяти сервера.
Можно использовать модули, eAccelerator, memcache и тд
Но не у каждого человека есть возможно приобрести VPS,VDS.
Прибегаем к кэшированию, а значит потеря динамики сайта. Тоже выход не супер, но работает)
Есть идея, как разработать умный кэшер, который будет поддерживать динамику сайта
и в тоже время, уменьшать нагрузку.
Но вот незадача, как быть с огромными массивами?
Массив в памяти весит больше 10мб, это очень много.
А без него сайт кушает всего-лишь 2-3мб.
Ну хорошо, кэшируем его(массив) в файл, предварительно упаковав в serialize.
А дальше? А дальше считываем с кэша. Да, нагрузка на процессор уходит, в 10раз уменьшилась.
Только вот память все также на износ.
как быть в данном случае? создавать какой-то индексный файл?
или весь массив передавать в базу? но это ужасно просто %)

 

[Liver]

Решения обычно зависят от задачи. Может и нет причины держать такой объем данных в памяти. Разве что это массив с очень частым доступом. При переносе его на хард будет очень много чтений дика, что не есть гуд. На жадной задаче нельзя жадничать ресурсами. Лопатой котлован не выкопать.

К тому же даже виртуалы сейчас дают по 32 метра рамы. А стоимость VDS тоже уже невелика.

Любая задача при увеличении объемов упирается в лимит ресурсов. И оптимизировать бесконечно невозможно. Проще добавить мощностей.

К чему я это - каким то ресурсом придется пожертвовать. Рама, хард, деньги - на выбор. Лучше рамы добавить.

 

[SergXP]

т.е. практически нереально ничего сделать?
кроме как увеличения мощностей сервера?

32 метра малова-то все-таки. многие движки жрут только по 10-20 мб. возьмите к примеру WordPress.
Работал с Zend Framework, тоже 6-8мб страница съедала.

все из-за объемных массивов.

 

[chang]

дык а че за массив такой на 10 метров ?
что с ним делают и зачем? и как часто ...
может есть смысл изменить принцип работы с теми данными

 

[LEE_ROY]

zf жрет из-за огромного количества обьектов, у тебя не тот случай чтобы что-то придумывать, возьми сначала сервер с 512 оперативки минимум и кешируй в memcached динамику а статику в файлы, на фронтенд поставь реверс прокси например nginx и будет тебе счастье. Еще можно можно облако заюзать, поймешь какие ресрусры сервера тебе нужны дабы не платить с избытком.

 

[SergXP]

LEE_ROY, вот вот! Объекты! К тому же массивы объектов.
не прибегая к модулям и настройкам сервера,
пытаюсь определить возможно ли оптимизировать работу, средствами php.
объявленные классы, их методы и объекты нереально запихнуть в кеш-файлы?

все невозможно кешировать, верно? либо массивы(уменьшая нагрузку на проц) либо целиком страницы, но потеря динамики..

chang, массивы постоянно используются, и верно подметил LEE_ROY объектов тоже много.

 

[chang]

объявленные классы, их методы и объекты нереально запихнуть в кеш-файлы?

нельзя -)

все невозможно кешировать, верно? либо массивы(уменьшая нагрузку на проц) либо целиком страницы, но потеря динамики..
chang, массивы постоянно используются, и верно подметил LEE_ROY объектов тоже много.

ну здесь еще интересно как они используются и для чего..

я просто частенько видел индуский код в котором последовательность действий
а) сделать запрос вида SELECT * FROM table
b) циклами N-ой вложенности посчитать сумму ... минимальное или среднее ... и подобную фигню ...
очень даже часто используется ... причем с виду в достаточно солидных приложениях


думаю здесь не так но мало ли ...
да и если используется СУБД то возможно есть смысл этот массив запихнуть туда?

 

[CrashX]

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

уровень первый
кэширование элементов в памяти, если у есть построитель форм использующий простые куски, или используется одни и тот же блок для вывода скажем новости... пример вы выводите 10 новостей значит 10 раз ситать фаил нужно а зачем?

берем массив там храним индекс и шаблон при требовании смотрим если он есть в раме то отдаем если нет грузим...

ускорение в среднем 3-10%, цель разгрузка IO

уровень второй
кэширование первого, у каждого модуля есть набор свойств, шаблонов и тк который он грузит весь массив ложив в кеш, ускорение 3-6% разгрузка IO

уровень 3 кэширование SQL ускорение до 30% при больших тяжелых запросах

уровень 4 кэширование сгенерированного контента, те запрос выполнен, шаблон загружен и данные шаблонизатором расставлены... мы его дампим в кеш и потом используем...ускорение до 60%
цель переход к статике на 30-50% тк часть модулей все еще динамические, и на странице от 1 до N модулей

уровень 5
кэширование страниц, переход к статике... ускорение до 80%

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

 

[SergXP]

к примеру в одном объекте данные о пользователе, в другом данные для генерации формы,
в третьем данные о сессии и тд и тп.

в общем получаются массивы объектов(если не ошибся в названии).
даже если запихнуть в БД этот тяжелый объект, его все равно придется считать..
снова в массив в коде php
вернемся снова к "пожирание памяти". ))))

 

[CrashX]

если это не могает
оптимизация, профилирование проекта, оптимизация запросов, php кода
я вот знаю что половина строковых оперций лучше переписать на свой лад тк в пыхе оно криво реализовано те очень долго выполняется. например substr на 6к итерацих очен долгий размер слова у него 9 сиволов выполние 600мс 0,6сек - долго...

Добавлено через 1 минуту
пожрание памяти )))) ололо
ну я храню запроны в раме потеря 4кб рамы... много а прирост настолько большой что я жертвую этим