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

Тема в разделе "PHP", создана пользователем SergXP, 2 апр 2011.

Модераторы: latteo
  1. SergXP

    SergXP Постоялец

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

    Liver

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

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

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

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

    SergXP Постоялец

    Регистр.:
    8 мар 2008
    Сообщения:
    66
    Симпатии:
    11
    т.е. практически нереально ничего сделать?
    кроме как увеличения мощностей сервера?

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

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

    chang

    Регистр.:
    20 ноя 2009
    Сообщения:
    363
    Симпатии:
    117
    дык а че за массив такой на 10 метров ?
    что с ним делают и зачем? и как часто ...
    может есть смысл изменить принцип работы с теми данными
     
  5. LEE_ROY

    LEE_ROY

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

    SergXP Постоялец

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

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

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

    chang

    Регистр.:
    20 ноя 2009
    Сообщения:
    363
    Симпатии:
    117
    нельзя -)

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

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


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

    CrashX В прошлом XSiteCMS

    Регистр.:
    6 июн 2008
    Сообщения:
    682
    Симпатии:
    112
    я перешел в многоуровнему кешированию
    теперь при соответствующих нагрузка система сама решает когда какой кеш юзать, она бедет свою статискику по юзверям онлай на проекте, чем больше тем больше кеша зайдствавно

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

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

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

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

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

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

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

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

    SergXP Постоялец

    Регистр.:
    8 мар 2008
    Сообщения:
    66
    Симпатии:
    11
    к примеру в одном объекте данные о пользователе, в другом данные для генерации формы,
    в третьем данные о сессии и тд и тп.

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

    CrashX В прошлом XSiteCMS

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

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