Комментарии 65
тема актуальна и продолжение было бы интересно почитать, возможно что то сам добавлю, сейчас работаю над системой кэширования для своего сайта, велосипед конечно изобретать не охото, но только так можно разобраться во всех тонкостях и закрепить полученные знания. Так что с удовольствием почитаю теорию.
Поэтому, если возникли проблемы с быстродействием сайта, то может стоит купить просто помощнее сервер – в ряде случаев это окажется дешевле.
Путь увеличения мощности сервера неправильный. Все же оптимизация будет лучше.
Тема кеширования сейчас наиболее актульано ждем продолжения :)
Путь увеличения мощности сервера неправильный. Все же оптимизация будет лучше.
Тема кеширования сейчас наиболее актульано ждем продолжения :)
Ключевое слово — дешевле. Железо дешевле труда программистов.
Кроме того, более медленный код может получаться в результате частичной автогенерации, что сильно экономит время и соотв. деньги.
Тема кэширования тем не менее актуальна :)
Кроме того, более медленный код может получаться в результате частичной автогенерации, что сильно экономит время и соотв. деньги.
Тема кэширования тем не менее актуальна :)
«Путь увеличения мощности сервера неправильный. Все же оптимизация будет лучше.»
Весьма распространенное заблуждение. Зачастую как раз таки правильное решение — увеличение мощности сервера.
Важно определить критерии «правильности», для меня, например, этот критерий стоимость решения в течении его жизни.
Если оптимизация даст выигрыш в 2 раза, при затратах в 100 000-рублей разово, и код будет использоваться год. А докупка мощностей будет стоить 60 000-рублей за этот же год, то стоит выбирать 2-ое.
Весьма распространенное заблуждение. Зачастую как раз таки правильное решение — увеличение мощности сервера.
Важно определить критерии «правильности», для меня, например, этот критерий стоимость решения в течении его жизни.
Если оптимизация даст выигрыш в 2 раза, при затратах в 100 000-рублей разово, и код будет использоваться год. А докупка мощностей будет стоить 60 000-рублей за этот же год, то стоит выбирать 2-ое.
НЛО прилетело и опубликовало эту надпись здесь
Джавистам рекомендую обратить внимание на фреймворк EHCache
Он лучше OSCache'а?
Как он по сравнение с JBoss Cache?
начал недевно использовать, а какие очень кратко у него плюсы и полезности?
я с ним лично мало работал, у нас в отделе ребята его активно используют. Из вкусностей — возможность использования в распределенных системах, хорошее взаимодействие с другими популярными фреймворками, например Hibernate, «персистентный кеш», который позволяет хранить состояние объектов даже после перезагрузки виртуальной java-машины.
Вношу предложение: мне было бы интересно узнать про существующие системы кэширования и не только при разработке сайтов, но и, например, кэширование файловой системы разных ОС или даже кэширование внутри различных устройств ввода-вывода или процессоров. Так же мне кажется интересным материал с аналитикой зависимости размера кэша на производительность на отдельно взятой системе кэширования. Если бы автор в будущем собрал бы и обобщил такие материалы, то было бы очень здорово.
За эту статью — спасибо.
За эту статью — спасибо.
Ну, я специализируюсь на веб-програмировании, и что знаю — о том и пишу. Что бы ответить на все ваши вопросы нуждно быть хорошо знать многие области, а всё знать хотелось бы, но увы — невозможно.
На всякий случай, хотя я уверен что вы это уже читали:
ru.wikipedia.org/wiki/Кэш
На всякий случай, хотя я уверен что вы это уже читали:
ru.wikipedia.org/wiki/Кэш
Автор, вы молодец, интересная статья, даже для непросвященного хабрачеловека :) спасибо.
Интересно, грамотно, легко читать. Я прям требую продолжения)
Очень ждем продолжения. Будет великолепно, если продолжение тоже будет с примерами как в этом топике.
Стоит добавить что системы кеширования могут изменить систему выдачи информации не только технически, но и логически.
Например, вытаскивают из базы только id и с помошью id проверяется наличие в кеше объекта. Если его нет, то объект вытаскивается достаточно быстрым селектом и кешируется.
Например, вытаскивают из базы только id и с помошью id проверяется наличие в кеше объекта. Если его нет, то объект вытаскивается достаточно быстрым селектом и кешируется.
У меня вот есть интересный вопрос по теории кеша.
Как именовать ключи?
Поясню — есть один сервер и на нем куча сайтов.
В кеше хранятся сотни тысяч ключей.
Именую ключи как HOST_NAME.$userkey
Тоесть один сервер все свои сотни тысяч ключей хранит с одинаковым префиксом. Это заметка номер 1
Далее юзер кей может иметь вид rubric:$ID: page:$PAGE
Чиста мне — понятно.
А чиста серверу искать как? Если длина фиксированного префикса еще более увеличивается?
Многие фреймворки хранят ключи как md5($realkey) — так у них получаются реально уникальные имена без длинных «начал»
Многие хранят в том виде в котором и отдаешь
Некоторые добавляют начало md5 суммы(2-3 знака) к ключу.
На первый взгляд это позволяет найти ключик быстрее, но (лично мне) не известно как именно хранит ключики сервер сам по себе. Я бы на его месте хранил в хеш-таблице, тоесть мне было бы на префикс положить…
… но… тестировал ли кто-либо как это дело реально влияет на скорость?
Речь идет наверное о главном стандарте кэширование — memcached
С файлами и так понятно
Как именовать ключи?
Поясню — есть один сервер и на нем куча сайтов.
В кеше хранятся сотни тысяч ключей.
Именую ключи как HOST_NAME.$userkey
Тоесть один сервер все свои сотни тысяч ключей хранит с одинаковым префиксом. Это заметка номер 1
Далее юзер кей может иметь вид rubric:$ID: page:$PAGE
Чиста мне — понятно.
А чиста серверу искать как? Если длина фиксированного префикса еще более увеличивается?
Многие фреймворки хранят ключи как md5($realkey) — так у них получаются реально уникальные имена без длинных «начал»
Многие хранят в том виде в котором и отдаешь
Некоторые добавляют начало md5 суммы(2-3 знака) к ключу.
На первый взгляд это позволяет найти ключик быстрее, но (лично мне) не известно как именно хранит ключики сервер сам по себе. Я бы на его месте хранил в хеш-таблице, тоесть мне было бы на префикс положить…
… но… тестировал ли кто-либо как это дело реально влияет на скорость?
Речь идет наверное о главном стандарте кэширование — memcached
С файлами и так понятно
Memcached в вашем случае лучше не использовать. почему — вот об этом и будет в следующей статье.
Для кеша конечно нужен хеш. Кеширование — это одно из самых главных использование хешей. Я лично использую sha1, но можно и md5 — кому как нарвится. Думаю, вам тоже стоит использовать хеш типа md5($realkey). Почему вас это не устраивает?
При хранении в файловой системе надо быть ой как аккуратным. Дело в том, что у многих файловых систем (в частности, ext2) есть ограничение на количество файлов в директории, которое обычно равно 32768 (2^15). И превышение этого лимита будет черевато write_error. Так что придется извращаться — разбивать хеш-код на отрезки по 2-4 символа и для первых 2-3 частей создавать одноименные директории. Тогда будет более-менее устойчиво и быстро. Иначе — дикие тормоза и сбои.
Для кеша конечно нужен хеш. Кеширование — это одно из самых главных использование хешей. Я лично использую sha1, но можно и md5 — кому как нарвится. Думаю, вам тоже стоит использовать хеш типа md5($realkey). Почему вас это не устраивает?
При хранении в файловой системе надо быть ой как аккуратным. Дело в том, что у многих файловых систем (в частности, ext2) есть ограничение на количество файлов в директории, которое обычно равно 32768 (2^15). И превышение этого лимита будет черевато write_error. Так что придется извращаться — разбивать хеш-код на отрезки по 2-4 символа и для первых 2-3 частей создавать одноименные директории. Тогда будет более-менее устойчиво и быстро. Иначе — дикие тормоза и сбои.
Как это не использовать???
или именно кешед не использовать?
или именно кешед не использовать?
Именно memcached не стит использовать.
Обосновать сможете?
Кратно какнить, но так чтобы зацепило :)
А то не хочется ждать ждать новой статьи
Кратно какнить, но так чтобы зацепило :)
А то не хочется ждать ждать новой статьи
Во-первых Memcached — это daemon. Т.е. к нему надо выполнять http-connect. Что очень ресурсоемкая операция. Во-вторых вопреки общепринятому мнению memcached не такая уж и быстрая штука. Кеширование в файл будет быстрее.
Memcached хорош когда много сайтов используют одни и те же данные, которые можно положить в разделяемую память. Тогда да, что изменилось — изменяешь и в памяти, другой сай уже будет использовать обновленные данные. Это быстрее, нежели конект к сайту для обновления данных на нем, который в свою очередь может обратиться к другому для обновлений там и т.д.
Но memcached не нужно использовать, если у вас только один сайт. Используйте APC — это во-первых не демон а сугубо PHP-шная штука, а во-вторых он и предназначен именно для кеширования в память.
Memcached хорош когда много сайтов используют одни и те же данные, которые можно положить в разделяемую память. Тогда да, что изменилось — изменяешь и в памяти, другой сай уже будет использовать обновленные данные. Это быстрее, нежели конект к сайту для обновления данных на нем, который в свою очередь может обратиться к другому для обновлений там и т.д.
Но memcached не нужно использовать, если у вас только один сайт. Используйте APC — это во-первых не демон а сугубо PHP-шная штука, а во-вторых он и предназначен именно для кеширования в память.
Мне APC не нравиться, он глючит, вешает систему и иногда портит данные.
eAccelerator или XCache
Серверов физических у меня два+сервер БД
По демону кешеда запущено на каждом.
При SET значения я кладу еше еще и в локальный кеш на ttl в 3 раза меньший
При GET — пробую в начале добраться до переменой в локальной памяти
Память я выделяю 32метра — и она обычно заполнена процентов на 70, из них половина — кеш скриптов.
В принципе кешед — это единственный кэшер который может «держать» хоть какой живой обьем данных, а не те 100-500 метров что технически можно поднять через sharedmem cacher
eAccelerator или XCache
Серверов физических у меня два+сервер БД
По демону кешеда запущено на каждом.
При SET значения я кладу еше еще и в локальный кеш на ttl в 3 раза меньший
При GET — пробую в начале добраться до переменой в локальной памяти
Память я выделяю 32метра — и она обычно заполнена процентов на 70, из них половина — кеш скриптов.
В принципе кешед — это единственный кэшер который может «держать» хоть какой живой обьем данных, а не те 100-500 метров что технически можно поднять через sharedmem cacher
> Т.е. к нему надо выполнять http-connect.
Не http-connect, а tcp
> Кеширование в файл будет быстрее.
Кеширование в файл не будет быстрее, потому что или у вас будет много-много файлов, или вам придется этот файл блокировать на каждое сохранение, и думать о хешировании внутри файла, и в итоге переписать memcached с нуля.
tcp-сокет, кстати, вполне быть и на localhost.
> Но memcached не нужно использовать, если у вас только один сайт.
А если у меня один сайт на FastCGI? :)
Не http-connect, а tcp
> Кеширование в файл будет быстрее.
Кеширование в файл не будет быстрее, потому что или у вас будет много-много файлов, или вам придется этот файл блокировать на каждое сохранение, и думать о хешировании внутри файла, и в итоге переписать memcached с нуля.
tcp-сокет, кстати, вполне быть и на localhost.
> Но memcached не нужно использовать, если у вас только один сайт.
А если у меня один сайт на FastCGI? :)
Да, верно, TCP.
Кеширование в файл все же будет быстрее. Потому что при взятии данных из файла его надо только считать, и не надо лочить. Лочнить надо при создании и изменении. А это существенно более редкий процесс, нежели считывание. Но рациональное звено есть — при частом изменении кеша да, memcached будет удобнее. Но нафиг тогда вообще кеш, если его надо постоянно перестраивать?
tcp-сокет, кстати, вполне быть и на localhost. — мог бы, но зачем он вообще нужен, если можно и без него?
Про FastCGI не совсем понял, на что вы намекали.
Memcached стоит использовать как Clipoard между системами. Тогда он раскрывает свою сущность полностью. А для кеширования существуют более эффективные решения.
Сугубо ИМХО.
Кеширование в файл все же будет быстрее. Потому что при взятии данных из файла его надо только считать, и не надо лочить. Лочнить надо при создании и изменении. А это существенно более редкий процесс, нежели считывание. Но рациональное звено есть — при частом изменении кеша да, memcached будет удобнее. Но нафиг тогда вообще кеш, если его надо постоянно перестраивать?
tcp-сокет, кстати, вполне быть и на localhost. — мог бы, но зачем он вообще нужен, если можно и без него?
Про FastCGI не совсем понял, на что вы намекали.
Memcached стоит использовать как Clipoard между системами. Тогда он раскрывает свою сущность полностью. А для кеширования существуют более эффективные решения.
Сугубо ИМХО.
Если мы говорим о кеше на файловой системе, то лучше использовать время последнего изменения и дату, для контроля изменений.
Плюс в папке кеша не должно находится более 1000 файлов. Иначе в большинстве случаев это производит к замедлению доступа.
Так что по идеи мы никогда не должны достигнуть лимита файлов, например как вы указали 32768
Плюс в папке кеша не должно находится более 1000 файлов. Иначе в большинстве случаев это производит к замедлению доступа.
Так что по идеи мы никогда не должны достигнуть лимита файлов, например как вы указали 32768
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Блин, одно дело практика, а другое — теория. Решать квадратные уравнения легко. А теоретические алгебраические выкладки более сложны (коммутативность, возведение в квадрат, понятие корня и т.д.).И да, деревья использовать — легко. А вспомните (если читали), сколько страниц у Кнута про деревья написано? Сколько алгоритмов поиска в деревьях вспомнить сходу сможете?
НЛО прилетело и опубликовало эту надпись здесь
> А вобще как показывает практика те кто ссылаются (как ты) на Кнута… впрочем ладно.
Просто недавно кое-что надо было перечитать, вот рядом на столе и лежал. Поэтому и припомнил дедушку Кнута.
А смысл сообщения был не с целью «задавить интеллектом», этим я не страдаю. Просто зацепила фраза
> Это офигенно сложно!
> Скоро напишут не юзайте деревья — оч сложно, сам пробовал нифига не вышло…
Более ярким примером было бы припомнить быструю сортировку. Не тяжело подключить библиотеку с математикой и вызвать qsort. Тяжело понять математичиский аппарат сортировки. Топик называется «Теория кэша», а не «я не умею использовать memcached» ;-)
Просто недавно кое-что надо было перечитать, вот рядом на столе и лежал. Поэтому и припомнил дедушку Кнута.
А смысл сообщения был не с целью «задавить интеллектом», этим я не страдаю. Просто зацепила фраза
> Это офигенно сложно!
> Скоро напишут не юзайте деревья — оч сложно, сам пробовал нифига не вышло…
Более ярким примером было бы припомнить быструю сортировку. Не тяжело подключить библиотеку с математикой и вызвать qsort. Тяжело понять математичиский аппарат сортировки. Топик называется «Теория кэша», а не «я не умею использовать memcached» ;-)
НЛО прилетело и опубликовало эту надпись здесь
> Печально что тебе тяжело понять сортировку, которая тоже тут не причём.
Ты плохо перефразировал мои слова. Я не говорил, что мне тяжело её понять.
Далее, по заключительной фразе «кеширование данных – это очень сложный процесс» нельзя сделать вывод, что автор не разбирается в теме. Биолог, описывая процессы, происходящие в мозгу, может закончить статью фразой «бег — это очень сложный процесс» и это ничего не скажет о его компетентности.
Ты плохо перефразировал мои слова. Я не говорил, что мне тяжело её понять.
Далее, по заключительной фразе «кеширование данных – это очень сложный процесс» нельзя сделать вывод, что автор не разбирается в теме. Биолог, описывая процессы, происходящие в мозгу, может закончить статью фразой «бег — это очень сложный процесс» и это ничего не скажет о его компетентности.
Если ты про этот топик, то у меня складывается такое же впечатление.
касательно первого пункта, стоило бы отметить что подобное решение (через static) нельзя использовать для классов, ибо статическая переменная внутри метода будет одинаковой для всех экземпляров класса, что, сокорее всего, не то что нам надо
1. Независимый или статичный
Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш.
Не вкурил. Что вы называете временными переменными? Про какие языки вы говорите? Я бы на вашем месте убрал эту фразу, чтобы не вводить в заблуждение читателей.
Уж не знаю как в PHP, но static, например в Java, имеет абсолютно другое значение. Рассуждая о кэше, полагаю следует опираться не только на PHP. Какая-то обособленная реализация («из трех строк») кэширования(??) на PHP ничего не демонстрирует.
2. Явно-зависимый
Алгоритмы здесь тоже достаточно простые – сводятся к проверкам условий, но в отличие от статического кэша он может независимо использоваться разными процессами.
Странное утверждение. Я всегда полагал, что статический кэш привязан не экзепляру класса, а к самому классу. И к этому кэшу могут лазить все экземляры класса. Тем более, раз он статичный и редко обновляется логично его использовать из многих процессов, т.к. многопоточный доступ к read-only данным (или редко обновляемым) не представляет большой опасности в многопоточном приложении.
3. Неявно-зависимый
Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
Например, функция, которая показывает информацию, взятую из базы данных. Мы можем закешировать результат функции, но мы должны знать, когда данные изменятся, что бы их обновить. А это эквивалентно обращению к таблице, что по ресурсоемкости равносильно выполнению функции. А если таблиц много? Смысл кэша теряется.
Ничего никуда не теряется. Допустим, вы используете какую-нибудь здоровенную BI систему, которая бацает отчеты. Время построения отчета от 5 до 15 минут. Очевидно, заставлять пользователя ждать столько времени — садизм.
Ваша функция кэширует отчет, который будет отдан пользователю, при этом в фоновом режиме эта же функция запускается каждые 5 — 15 минут для построения нового отчета. Таким образом время между появлением обновленных отчетов примерно равно времени построению отчетов. Так что смысл кэша никуда не девается.
Можно следить за временем генерации отчета и динамически изменять периодичность запуска функции отчета.
Если вместо 5 -15 минут время построения отчета увеличилось до 25 минут (а такое бывает, поверьте), логично увеличить интервал между запусками. И никаких таблиц и еще чего-то там не нужно.
Как видно, кеширование данных – это очень сложный процесс, требующий большое количество ресурсов на его разработку. Не стоит забывать, что в наше время стоимость железа может оказать дешевле, чем стоимость разработки сложных алгоритмов.
Полностью согласен. Чаще всего дешевле обходится мощная железка, чем разработка и последующая поддержка с заклеиванием багов.
Меня очень смущает ваша «категоризация кэша». Она спорная. И вообще статья спорная и странная.
Производит впечатление, что вы не очень-то разбираетесь в том, что пытаетесь написать.
Если у вас есть возможность пояснить отмеченные мною моменты, с радостью прочитаю.
Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш.
Не вкурил. Что вы называете временными переменными? Про какие языки вы говорите? Я бы на вашем месте убрал эту фразу, чтобы не вводить в заблуждение читателей.
Уж не знаю как в PHP, но static, например в Java, имеет абсолютно другое значение. Рассуждая о кэше, полагаю следует опираться не только на PHP. Какая-то обособленная реализация («из трех строк») кэширования(??) на PHP ничего не демонстрирует.
2. Явно-зависимый
Алгоритмы здесь тоже достаточно простые – сводятся к проверкам условий, но в отличие от статического кэша он может независимо использоваться разными процессами.
Странное утверждение. Я всегда полагал, что статический кэш привязан не экзепляру класса, а к самому классу. И к этому кэшу могут лазить все экземляры класса. Тем более, раз он статичный и редко обновляется логично его использовать из многих процессов, т.к. многопоточный доступ к read-only данным (или редко обновляемым) не представляет большой опасности в многопоточном приложении.
3. Неявно-зависимый
Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
Например, функция, которая показывает информацию, взятую из базы данных. Мы можем закешировать результат функции, но мы должны знать, когда данные изменятся, что бы их обновить. А это эквивалентно обращению к таблице, что по ресурсоемкости равносильно выполнению функции. А если таблиц много? Смысл кэша теряется.
Ничего никуда не теряется. Допустим, вы используете какую-нибудь здоровенную BI систему, которая бацает отчеты. Время построения отчета от 5 до 15 минут. Очевидно, заставлять пользователя ждать столько времени — садизм.
Ваша функция кэширует отчет, который будет отдан пользователю, при этом в фоновом режиме эта же функция запускается каждые 5 — 15 минут для построения нового отчета. Таким образом время между появлением обновленных отчетов примерно равно времени построению отчетов. Так что смысл кэша никуда не девается.
Можно следить за временем генерации отчета и динамически изменять периодичность запуска функции отчета.
Если вместо 5 -15 минут время построения отчета увеличилось до 25 минут (а такое бывает, поверьте), логично увеличить интервал между запусками. И никаких таблиц и еще чего-то там не нужно.
Как видно, кеширование данных – это очень сложный процесс, требующий большое количество ресурсов на его разработку. Не стоит забывать, что в наше время стоимость железа может оказать дешевле, чем стоимость разработки сложных алгоритмов.
Полностью согласен. Чаще всего дешевле обходится мощная железка, чем разработка и последующая поддержка с заклеиванием багов.
Меня очень смущает ваша «категоризация кэша». Она спорная. И вообще статья спорная и странная.
Производит впечатление, что вы не очень-то разбираетесь в том, что пытаетесь написать.
Если у вас есть возможность пояснить отмеченные мною моменты, с радостью прочитаю.
Поясняю. Вопросов много, поэтому отвечу только на некоторые. Остальные считаю не без коментариев, потому что считаю, что вопросы заданы некорректно. Похоже вы плохо представляете, как работают приложения в вебе, иначе бы их не задавали.
> Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш.
for ($i =0; $i < sizeof($something); $i++)
или
$size = sizeof($something);
for ($i =0; $i < $size; $i++)
Смысл кода вам надеюсь, понятен. В данном случае переменную $size можно расматривать как своего рода кеш. Не согласны? В Си есть переменные типа static. Т.е. переменная которая не изменяется при повторном вызове функций. Уверен, в яве тоже есть что-то подобное.
> Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
A зависит от Б. Б зависит от С. Тогда А зависит от С, но прямой связи не сущетвует. Я это имел ввиду.
И еще раз соверую внимательно прочитать второй абзац, а так же обратить внимание на тему блога, в который я написал эту статью.
> Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш.
for ($i =0; $i < sizeof($something); $i++)
или
$size = sizeof($something);
for ($i =0; $i < $size; $i++)
Смысл кода вам надеюсь, понятен. В данном случае переменную $size можно расматривать как своего рода кеш. Не согласны? В Си есть переменные типа static. Т.е. переменная которая не изменяется при повторном вызове функций. Уверен, в яве тоже есть что-то подобное.
> Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
A зависит от Б. Б зависит от С. Тогда А зависит от С, но прямой связи не сущетвует. Я это имел ввиду.
И еще раз соверую внимательно прочитать второй абзац, а так же обратить внимание на тему блога, в который я написал эту статью.
Остальные считаю не без коментариев, потому что считаю, что вопросы заданы некорректно. Похоже вы плохо представляете, как работают приложения в вебе, иначе бы их не задавали.
enartemy, вы про какие вопросы говорите? Если вас не затруднит, перечислите их, пожалуйста.
Смысл кода вам надеюсь, понятен. В данном случае переменную $size можно расматривать как своего рода кеш.
В контексте Джавы, если это локальная примитивная переменная, то она живет внутри метода. Сборщик мусора ее в любом случае соберет. Причем здесь кэш я не понимаю.
> Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
A зависит от Б. Б зависит от С. Тогда А зависит от С, но прямой связи не сущетвует. Я это имел ввиду.
Это называется транзитивная зависимость.
enartemy, вы про какие вопросы говорите? Если вас не затруднит, перечислите их, пожалуйста.
Смысл кода вам надеюсь, понятен. В данном случае переменную $size можно расматривать как своего рода кеш.
В контексте Джавы, если это локальная примитивная переменная, то она живет внутри метода. Сборщик мусора ее в любом случае соберет. Причем здесь кэш я не понимаю.
> Когда один объект вложен в другой объект, это прямая зависимость (ООП). Прямее некуда :)
A зависит от Б. Б зависит от С. Тогда А зависит от С, но прямой связи не сущетвует. Я это имел ввиду.
Это называется транзитивная зависимость.
Вы похоже програмист на Java, я правильно понял? Скажите пожалуйста, Java часто используется для создания веб-приложений или сайтов? Да, я знаю, что она используется, в виде JSP. Вы знаете jsp?
Дело в том, что языки предназначены для разного. И методы, и мышление програмистов — тоже. Сейчас еще придет сюда поклонник ассемблера и вообще впадет в ужас — ах, как же вы обошли стороной первый и второй урони кэша, пробои и попадания кэш?
Я понимаю ваше возмущение, но я не могу с вами спорить. Мы всегда будем говорить о разных вещах.
Дело в том, что языки предназначены для разного. И методы, и мышление програмистов — тоже. Сейчас еще придет сюда поклонник ассемблера и вообще впадет в ужас — ах, как же вы обошли стороной первый и второй урони кэша, пробои и попадания кэш?
Я понимаю ваше возмущение, но я не могу с вами спорить. Мы всегда будем говорить о разных вещах.
Поскольку вы явно с Джавой не знакомы, перл про jsp я комментить не буду. Не может же человек вообще все знать, вы про это писали сегодня в этом топике, я с вами согласен.
На Джаве очень много всего пишут. Не намного меньше, чем на ПХП.
Дело не в мышлении, дело в том, что вы расуждаете о вещах, которые не очень-то вам знакомы. По всей видимости, вы не используете классы в ПХП, раз транзитивную зависимость обзываете как угодно, но не так как надо. Про кэш (не в браузере) у вас тоже какое-то странное представление.
Утверждение, что ПХП и Джава предназначены для разного — спорное утвержение. JEE как раз и предназначена для веб-приложений, веб-сервисов (в том числе RESTful, о которых вы писали), бизнес приложений и многих других вещей.
Написано приложение на Джаве, на ПХП, на еще чем-нибудь — не важно. Перед всеми встанет одна и та же задача — снижение нагрузки при помощи кэша. И абсолютно всеравно, на чем вы пишите, методы кэширования данных на сервере принципиально ни чем не отличаются.
Можно писать в файлы, можно вставать на голову и дрыгать ножками, разница заключается в том, на каком языке вы будете в этот момент произносить заклинания: на ПХП или Джаве.
На Джаве очень много всего пишут. Не намного меньше, чем на ПХП.
Дело не в мышлении, дело в том, что вы расуждаете о вещах, которые не очень-то вам знакомы. По всей видимости, вы не используете классы в ПХП, раз транзитивную зависимость обзываете как угодно, но не так как надо. Про кэш (не в браузере) у вас тоже какое-то странное представление.
Утверждение, что ПХП и Джава предназначены для разного — спорное утвержение. JEE как раз и предназначена для веб-приложений, веб-сервисов (в том числе RESTful, о которых вы писали), бизнес приложений и многих других вещей.
Написано приложение на Джаве, на ПХП, на еще чем-нибудь — не важно. Перед всеми встанет одна и та же задача — снижение нагрузки при помощи кэша. И абсолютно всеравно, на чем вы пишите, методы кэширования данных на сервере принципиально ни чем не отличаются.
Можно писать в файлы, можно вставать на голову и дрыгать ножками, разница заключается в том, на каком языке вы будете в этот момент произносить заклинания: на ПХП или Джаве.
Ладно, не буду кривить душой — я просто не понимаю ваших вопросов. Я не понимаю, что вы имеете ввиду, когда говорите про мультизадачность и про что, что что-то выполняется в фоне. Потому как на php это делается через очень большую жопу, которая не явно не оправдана. Я не понимаю, почему вы говорите что методы кеширования должны быть одинаковыми, и тут же переходите на непосредственную реализацию — а вот так это лучше делается на джаве. Но мы же говорим о методах, а не о реализации. Вобщем, ваши посты меня конкретно запутали.
Алгоритмы здесь тоже достаточно простые – сводятся к проверкам условий, но в отличие от статического кэша он (yaneblog: он=«Явно-зависимый» кэш?) может независимо использоваться разными процессами.
Это вы говорите про мультипоточность.
Как делается на ПХП, я не знаю. Я рассчитавал, что если вы пишите, значит многозадачность в пхп есть и она используется.
Еще раз прочитал свои сообщения. Я не писал про то, как это делается на Джаве. Я писал про то, как это делается вообще.
Кэширование, это как условные операторы в разных языках. Как не обзови, всеравно они делают одно и тоже.
про кэш — тоже самое. На чем ни пиши, методы кэширования одни для всех.
Прочитайте две странички
Там и про мою Джаву, и про ваш ПХП.
Прочитав, обратите свое внимание сюда.
Хоть и про Рэйлз, но принципиальных отличий нет.
Вот пример про CMS Joomla. только концовку не читайте. Автор пишет:
.Тем не менее, использование кэш-памяти не всегда ускоряет процесс.
Кэширование в память и кэширование на диск — принципиально разные вещи. Автор «урока» глупость написал
Я вам так скажу — вы фигню какую-то написали, а читатели ее проглотили. Не пойму почему. Мне кажется, потому что не пытались понять, о чем же вы пишите.
Это вы говорите про мультипоточность.
Как делается на ПХП, я не знаю. Я рассчитавал, что если вы пишите, значит многозадачность в пхп есть и она используется.
Еще раз прочитал свои сообщения. Я не писал про то, как это делается на Джаве. Я писал про то, как это делается вообще.
Кэширование, это как условные операторы в разных языках. Как не обзови, всеравно они делают одно и тоже.
про кэш — тоже самое. На чем ни пиши, методы кэширования одни для всех.
Прочитайте две странички
Там и про мою Джаву, и про ваш ПХП.
Прочитав, обратите свое внимание сюда.
Хоть и про Рэйлз, но принципиальных отличий нет.
Вот пример про CMS Joomla. только концовку не читайте. Автор пишет:
.Тем не менее, использование кэш-памяти не всегда ускоряет процесс.
Кэширование в память и кэширование на диск — принципиально разные вещи. Автор «урока» глупость написал
Я вам так скажу — вы фигню какую-то написали, а читатели ее проглотили. Не пойму почему. Мне кажется, потому что не пытались понять, о чем же вы пишите.
>>>> Смысл кода вам надеюсь, понятен. В данном случае переменную $size можно расматривать как
>>>> своего рода кеш.
>> В контексте Джавы, если это локальная примитивная переменная, то она живет внутри метода.
>> Сборщик мусора ее в любом случае соберет. Причем здесь кэш я не понимаю.
Слегка не поняли. Автор говорил, что переменная $size здесь играет роль кеша, чтобы не считать каждый раз длину массива. В данном случае длина массива записана в переменную, т.е. как бы «закеширована». Предлагаю мыслить абстрактней :)
>>>> своего рода кеш.
>> В контексте Джавы, если это локальная примитивная переменная, то она живет внутри метода.
>> Сборщик мусора ее в любом случае соберет. Причем здесь кэш я не понимаю.
Слегка не поняли. Автор говорил, что переменная $size здесь играет роль кеша, чтобы не считать каждый раз длину массива. В данном случае длина массива записана в переменную, т.е. как бы «закеширована». Предлагаю мыслить абстрактней :)
Ну, знаете ли, Adelf, я так что угодно могу кэшем обозвать. Пример безжизненный. Никакой это не кэш. Любой программист знает, что функция в условии цикла, это пипец. А уж если говорить про Джаву, в условии цикла попадает объект, не «защищенный от потоков», то это пипец в квадрате, или даже больше.
Я вашу мысль и ход мысли автора понял, но не надо мешать с кэшем значение локальных примитивов. Это лишний раз подтвержает несостоятельность доводов автора.
Я вашу мысль и ход мысли автора понял, но не надо мешать с кэшем значение локальных примитивов. Это лишний раз подтвержает несостоятельность доводов автора.
«Кэш (англ. cache[1]) — промежуточный буфер с быстрым доступом, содержащий копию той информации, которая хранится в памяти с менее быстрым доступом, но с наибольшей вероятностью может быть оттуда запрошена.» — из википедии. Почему же это нельзя назвать кэшем, если полностью соответствует определению?
«Как видно, кеширование данных – это очень сложный процесс, требующий большое количество ресурсов на его разработку. Не стоит забывать, что в наше время стоимость железа может оказать дешевле, чем стоимость разработки сложных алгоритмов. Поэтому, если возникли проблемы с быстродействием сайта, то может стоит купить просто помощнее сервер – в ряде случаев это окажется дешевле.»
Обычно в долговременной перспективе окупается вариант, когда вкладываются ресурсы, а не выбирается более простой путь.
Обычно в долговременной перспективе окупается вариант, когда вкладываются ресурсы, а не выбирается более простой путь.
Хорошая статья на эту тему, написана специалистом: nomagic.ru/article.php? aid=58
Специалист пишет про кэширование на стороне пользователя, а автор топика рассуждает о кэшировании данных на стороне сервера, т.е. кэширование внутри системы.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теория кэша