Comments 66
ниче так, только тэги поправьте (через запятую нужно, а не через пробел)
Спасибо за статью.
Я сейчас делаю движок небольшой для сайта и несколько других статьей про кеш читал… но так и не понял, чем APC от memcached отличается с точки зрения разработчика. Может кто пояснит?
Я сейчас делаю движок небольшой для сайта и несколько других статьей про кеш читал… но так и не понял, чем APC от memcached отличается с точки зрения разработчика. Может кто пояснит?
APC в первую очередь код кэширует. memcashed - данные
Разница в полной мере ощущается, когда у вас несколько аппликэйшн серверов. APC, может быть только свой у каждого сервера, а memcached может быть общий для них всех, на отдельном серваке, например. Соответственно, в этом случае сессии, например, хранить в APC уже нельзя, а в memchached можно.
как пример, вот реализация кешера из Solar
http://solarphp.com/class
Solar_Cache Factory class for cache adapters.
Solar_Cache_Adapter Abstract cache adapter.
Solar_Cache_Adapter_Apc APC cache controller.
Solar_Cache_Adapter_Eaccelerator eAccellerator cache controller.
Solar_Cache_Adapter_File File-based cache controller.
Solar_Cache_Adapter_Memcache Memcache cache controller.
Solar_Cache_Adapter_Var Variable (in-memory) cache controller.
Solar_Cache_Adapter_Xcache XCache cache controller.
просто кроме APC есть еще Eaccelerator и Xcache и т.д....
http://solarphp.com/class
Solar_Cache Factory class for cache adapters.
Solar_Cache_Adapter Abstract cache adapter.
Solar_Cache_Adapter_Apc APC cache controller.
Solar_Cache_Adapter_Eaccelerator eAccellerator cache controller.
Solar_Cache_Adapter_File File-based cache controller.
Solar_Cache_Adapter_Memcache Memcache cache controller.
Solar_Cache_Adapter_Var Variable (in-memory) cache controller.
Solar_Cache_Adapter_Xcache XCache cache controller.
просто кроме APC есть еще Eaccelerator и Xcache и т.д....
косвенно связанный с топиком вопрос, кто какие php-профайлеры использует?
Очень хороша видна работа кэшеров при использовании ORM, скажем phpdoctrine позволяет использовать различные кэшеры для хранения запросов и данных, что ощутимо сказывается на быстродействии. Скажем в своей разработке использую связь доктрина + хкэш.
Хм, статья еще в оригинале показалась неструктурированной. В тех же заголовках перемешаны и хранилища, и методы, и уровни кеширования. Но все равно кому-то полезно ;)
Собственно, кому оказалась интересна эта статья, милости просим претендовать на нашу вакансию: http://habrahabr.ru/job/3188/
Скажите, а есть какие-нибудь способы зеркалировать папки/файлы с одного сервера в RAM Disk другого ?
Это скорее вопрос по администрированию nfs (но я могу ошибаться)
а зачем вам это, может обойти с использованием другого решения?
а зачем вам это, может обойти с использованием другого решения?
Через nfs уже работает.
У нас есть сервер, где лежат оригиналы файлов. Есть каталог, в котором в обшей сложности около 20 тысяч файлов. Есть несколько рабочих серверов с Apache+PHP. Для формирования любой страницы сайта нужно произвести очень много операций чтения из этого каталога.
По сути ответом на Ваш вопрос будет "очень хочется минимизировать количество файловых операций (чтобы было не через сеть + чтобы было не с физического диска". Если внедрить подобное "зеркалирование", то производительность очень возрастёт (это факт) + не нужно будет ничего переделывать.
У нас есть сервер, где лежат оригиналы файлов. Есть каталог, в котором в обшей сложности около 20 тысяч файлов. Есть несколько рабочих серверов с Apache+PHP. Для формирования любой страницы сайта нужно произвести очень много операций чтения из этого каталога.
По сути ответом на Ваш вопрос будет "очень хочется минимизировать количество файловых операций (чтобы было не через сеть + чтобы было не с физического диска". Если внедрить подобное "зеркалирование", то производительность очень возрастёт (это факт) + не нужно будет ничего переделывать.
По описанию проблемы не понятно ваша ситуация соответственно предлагаемые решения будут пустыми. Опишите детально средний размер файлов и количество необходимых загрузок файлов за один запрос к веб-серверу
Да это не то, чтобы проблема. Она если и появится, то очень не скоро - покупку нового сервера ещё никто не отменял =)
Файлы очень маленькие (размер - до 10Кб). Для формирования средней страницы нужно около тысячи обращений к файлам. Так получилось после наворотов админки для верстальщика - ему стало удобно и количество файлов начало расти как снежный ком =)
Файлы очень маленькие (размер - до 10Кб). Для формирования средней страницы нужно около тысячи обращений к файлам. Так получилось после наворотов админки для верстальщика - ему стало удобно и количество файлов начало расти как снежный ком =)
nginx, squid
а если не секрет, rsync чем не угодил?
это скорее вопрос по администрированию nfs (но я могу ошибаться)
а зачем вам это, может обойти с использованием другого решения?
а зачем вам это, может обойти с использованием другого решения?
$cache->store($categories, 'categories');
Не нашел такого метода в документации по Cache_Lite.
Вы абсолютно правы, такого метода нет
автор статьи написал, а я не проверил. Речь идет о методе save
автор статьи написал, а я не проверил. Речь идет о методе save
спасибо!
поменял
поменял
Может, перенести в "Высокую производительность"?
При использовании memcache надо обращать внимание на время коннекта. Оно может быть на порядок больше времени самой выборки и, таким образом, свести все преимущество на нет.
Что касается Memory tables в MySQL, советую помнить об ограничении на максимальный размер такой таблицы. Он определяется минимальным из параметров tmp_table_size и max_heap_table_size. Если размер вырастет больше - сервер просто откажется добавлять новые строки.
Что касается Memory tables в MySQL, советую помнить об ограничении на максимальный размер такой таблицы. Он определяется минимальным из параметров tmp_table_size и max_heap_table_size. Если размер вырастет больше - сервер просто откажется добавлять новые строки.
по поводу первого сомнительно, чтобы коннект к mysql-серверу, был быстрее чем коннект к memchache-серверу. Однако, если выборка маленькая, можно сохранять и в памяти
По поводу второго, ничто же не мешает учитывать сохраняемых размер данных внутри класса обертки и описать сборщик мусора самостоятельно
По поводу второго, ничто же не мешает учитывать сохраняемых размер данных внутри класса обертки и описать сборщик мусора самостоятельно
Вопрос такой: какой из этих методов, или даже есть ли метод в php кешировать структуры данных не в сериализованном виде, а "такими как есть", т.е. чтобы при каждом запросе не происходила десериализация? На это тратится время. Ясное дело, что в файлы по-другому складывать не получится, но в shared_memory, как мне кажется, вполне. Знаю что shm_put_var точно сериализует. Кто знает как с этим в apc_store/fetch?
Спасибо большое, очень интересно!
При разработке высоконагруженых сервисов, в большинстве своем, все задержки упираются в БД, а не в скорость выполнения скриптов. Что мешает доставить дополнительных дешевых машинок под выполнение php? Главной проблемой все равно будет оптимизация (а желательно и реплицирование или даже кластеризация) БД, ну а здесь уже без memcache просто никак не обойтись!
ну стоимость 1 машинки соизмерима со стоимостью 2 месяцев работы хорошего программиста. Может лучше прооптимизировать приложение. Более того вы не учитываете оплату места в стойке, оплату питания и т.д.
Полностью с вами согласен, насчет того что узкие места в приложении это БД и коммуникации с другими сервисами.
Однако не стоит забывать и про скриптовую часть, а именно алгоритм реализации. Не даром же господин Кнут написал 3 том "Сортировка и поиск", более 10 видов сортировки, он же не написал, забейте на все...используйте сортировку методом пузырька, а когда будет тормозить - купите машинку
Полностью с вами согласен, насчет того что узкие места в приложении это БД и коммуникации с другими сервисами.
Однако не стоит забывать и про скриптовую часть, а именно алгоритм реализации. Не даром же господин Кнут написал 3 том "Сортировка и поиск", более 10 видов сортировки, он же не написал, забейте на все...используйте сортировку методом пузырька, а когда будет тормозить - купите машинку
Боюсь, Вы ошибаетесь. Стоимость аренды машинки под php-приложения колеблется около 100$. Стоимость простеньких серверов - это порядка 15-20 000 рублей. Зачастую нагрузка появляется очень быстрыми темпами и оптимизировать весь код и протестировать его вы явно не успеете!!! На это нужны месяцы (для большого проекта). Остается только спасаться дешевеньким железом, а уж потом ждать пока программисты (+ архитектор БД + иногда и администраторы) оптимизируют весь код и программные компоненты и тестеры все это протестируют.
Под купить машинку я подразумевал покупку сервера, а не его аренду
Под качественными программистами я имел ввиду не студентов, а людей со большим ОПЫТОМ работы. Насчет простенького сервера не знаю, не давно покупали сервер стоимостью где-то в районе 6-8 тыс. $ для проекта с высокой посещаемостью. Чаще всего весь код оптимизировать не надо, не все сценарии работы с системой являются часто используемыми. А для остального есть профайлер. Можно выяснить узкие места и заострить внимание на них
Под качественными программистами я имел ввиду не студентов, а людей со большим ОПЫТОМ работы. Насчет простенького сервера не знаю, не давно покупали сервер стоимостью где-то в районе 6-8 тыс. $ для проекта с высокой посещаемостью. Чаще всего весь код оптимизировать не надо, не все сценарии работы с системой являются часто используемыми. А для остального есть профайлер. Можно выяснить узкие места и заострить внимание на них
Я работаю ведущим разработчиком в компании, которая владеет нескольким нагруженными социальными сетями. Так вот, вывод из практики такой... вы купили машинку за 6-8 тысяч долларов, а теперь подумайте, что будет работать стабильнее и быстрее: одна мощная машинка или кластер из 6-8 обычных за эти же деньги?)))
1) несколько нагруженных социальных сетей, это сколько загрузок в день?
2) машинка была куплена с огромным количеством оперативной памяти для кеширования и не одним процессором + никто не говорит, что машинка одна
3) я вас уверяю запустив глючной код на любом количестве машин он будет тормозить
4) главный вопрос, вы никогда не пробовали создавать популярные сервисы за СОБСТВЕННЫЕ ДЕНЬГИ?
2) машинка была куплена с огромным количеством оперативной памяти для кеширования и не одним процессором + никто не говорит, что машинка одна
3) я вас уверяю запустив глючной код на любом количестве машин он будет тормозить
4) главный вопрос, вы никогда не пробовали создавать популярные сервисы за СОБСТВЕННЫЕ ДЕНЬГИ?
1)несколько миллионов хитов на каждую
2)кшеирование в оперативе (говорю про memcache) обычно выводят на отдельный кластер из дешевого железа, но с большим кол-вом оперативы (подойдут даже десктопные машинки)
3) исходя из размера заработной платы нормального программиста и сроков переписывания "говнокода", легче купить (читать быстрее и дешевле) дешевого железа, нежели оплачивать зарплату
4)да, поэтому там заранее была заложена возможность "горячего" масштабирования за малые деньги. Т.е. я имею ввиду, что при резком росте посещаемости, к примеру, на порядок, гораздо проще и самое главное ДЕШЕВЛЕ было просто докупить самое дешевое железо и доставить его в массив.
2)кшеирование в оперативе (говорю про memcache) обычно выводят на отдельный кластер из дешевого железа, но с большим кол-вом оперативы (подойдут даже десктопные машинки)
3) исходя из размера заработной платы нормального программиста и сроков переписывания "говнокода", легче купить (читать быстрее и дешевле) дешевого железа, нежели оплачивать зарплату
4)да, поэтому там заранее была заложена возможность "горячего" масштабирования за малые деньги. Т.е. я имею ввиду, что при резком росте посещаемости, к примеру, на порядок, гораздо проще и самое главное ДЕШЕВЛЕ было просто докупить самое дешевое железо и доставить его в массив.
по вашему резюме не смог догадаться в каких нагруженных социальных сетях вы работаете, но есть догадка (мойкруг).
чувствую часть понимания у нас общая, а до некоторых вещей
договориться никак не можем.
А куда вы будите ставить такое количество десктопов, ну если только организовать собственный дата-центр.
немного непонятно словосочетание дешевое железо с большим количеством оперативки...могу ошибаться, но таких материнских плат да чтобы они были дешевые...
Сведу наш спор к утверждению, с которым вы наверняка согласитесь.
Код надо писать правильно, но какой бы код не был хороший всегда наступает момент, когда необходимы новые серверные мощности
чувствую часть понимания у нас общая, а до некоторых вещей
договориться никак не можем.
А куда вы будите ставить такое количество десктопов, ну если только организовать собственный дата-центр.
немного непонятно словосочетание дешевое железо с большим количеством оперативки...могу ошибаться, но таких материнских плат да чтобы они были дешевые...
Сведу наш спор к утверждению, с которым вы наверняка согласитесь.
Код надо писать правильно, но какой бы код не был хороший всегда наступает момент, когда необходимы новые серверные мощности
1) с утверждением согласен))) самое главное - планировать человеческий код заранее
2) по поводу догодок напишу в приват
3) дешевое железо - это до 8000 руб за десктопную машинку. Нынче оперативная память не дорогая... в среднем 1руб за 1 мегабайт, а внекоторых местах и того меньше.
4)Свой дата-центр можно организовать и в подвале за МКАДом, главное, чтоб канал хороший был, а это теперь не такая редкость.
2) по поводу догодок напишу в приват
3) дешевое железо - это до 8000 руб за десктопную машинку. Нынче оперативная память не дорогая... в среднем 1руб за 1 мегабайт, а внекоторых местах и того меньше.
4)Свой дата-центр можно организовать и в подвале за МКАДом, главное, чтоб канал хороший был, а это теперь не такая редкость.
в догонку, пока вы на меня не успели обидеться.
работал в одной компании, пришел на место программиста, оптимизировал местную crm
страница генерировалась больше минуты, проблема была в том, что предыдущий программист не знал, что такое индексы в БД...понимаю, что пример дурацкий, но все же коду надо уделять внимание
работал в одной компании, пришел на место программиста, оптимизировал местную crm
страница генерировалась больше минуты, проблема была в том, что предыдущий программист не знал, что такое индексы в БД...понимаю, что пример дурацкий, но все же коду надо уделять внимание
в избранное!
Люди, подскажите пожалуйста, как кешировать запросы из БД? Т.е. строки вида /catalog/1934/536/A3446 - запрос к БД, по айдишникам. Как можно кешировать такие запросы, что бы по данному пути, можно было быстро вывести данные. Т.к. постоянно запросы делать в БД нецелесообразно. И ещё: как данные в кеш будут обновляться, если добавлен новый товар. Нужно прописывать обновление кеша? Или его полное стирание, при добавлении новой записи в БД.
При загрузке страницы необходимо проверять, создан для нее кэш. если да, показываем из кеша (под кешом можно понимать какое-либо хранилище), если нет создаем в кеше
Кэширование может быть разным. например если страницы с неизменяемым контентом, перед веб-сервером можно поставить какой-нибудь кэширующий прокси, либо создавать прегенерированные страницы (в случае если такой страницы нет, то , например, ее создает перехватчик ошибки 404), либо сохранять в каком-нибудь другом хранилище
1) старые записи можно кэшировать спрятав web-сервер за каким-нибудь proxy (например squid). Либо
Кэширование может быть разным. например если страницы с неизменяемым контентом, перед веб-сервером можно поставить какой-нибудь кэширующий прокси, либо создавать прегенерированные страницы (в случае если такой страницы нет, то , например, ее создает перехватчик ошибки 404), либо сохранять в каком-нибудь другом хранилище
1) старые записи можно кэшировать спрятав web-сервер за каким-нибудь proxy (например squid). Либо
спасибо за развернутый ответ!!! только я не понимаю технологию, как проверять, обновилась ли запись в БД или нет? т.е. есть ли смысл тогда, если постоянно проверять обновилась ли запись или можно показывать то что находится в кеше (т.е. устаревание записи). вот это меня беспокоит.
А что вам мешает в БД создать два поля, дата создания записи в кеше и дата изменения записи
По поводу использования кеша, вы можете создавать кеш с устареванием, если данные кеша устарели, то пересоздать запись
По поводу использования кеша, вы можете создавать кеш с устареванием, если данные кеша устарели, то пересоздать запись
я обычно делаю проще — закидываю в кеш, а при изменении какой либо части страницы удаляю страницу из кеша, что вынуждает её перегенерироваться
Подскажите, а какой инструмент позволяет хранить связи, что страница состоит из частей-кусков?
Суть вопроса, как найти все страницы в которых есть «протухший» кусок, чтобы удалить эти страницы из кеша.
Суть вопроса, как найти все страницы в которых есть «протухший» кусок, чтобы удалить эти страницы из кеша.
Это решается установкой времени годности (timeout) информации.
вот тут php.net/manual/ru/memcache.add.php можно посмотреть
вот тут php.net/manual/ru/memcache.add.php можно посмотреть
Время годности это хорошо, но вопрос был о другом. Постараюсь чуть подробнее расписать.
Допустим, есть страницы с описанием квартир в каталоге. Эти страницы мы и хотим закэшировать.
И на этих страницах есть блоки информации — «Похожие объявления».
Одно и то же объявление может быть в похожих на страницах многих объявлений.
И если это объявление изменяется — удалили это объявление, или изменили контент — то надо найти все страницы где оно было в похожих, чтобы удалить только эти страницы из кеша.
Получается есть родительский объект (страница объявления) со своим сроком протухания и есть несколько дочерних кусков внутри этого объекта (блоки похожих объявлений) со своим сроком протухания.
Вот есть ли такое Cache хранилище, которое умеет такие взаимосвязи поддерживать?
Допустим, есть страницы с описанием квартир в каталоге. Эти страницы мы и хотим закэшировать.
И на этих страницах есть блоки информации — «Похожие объявления».
Одно и то же объявление может быть в похожих на страницах многих объявлений.
И если это объявление изменяется — удалили это объявление, или изменили контент — то надо найти все страницы где оно было в похожих, чтобы удалить только эти страницы из кеша.
Получается есть родительский объект (страница объявления) со своим сроком протухания и есть несколько дочерних кусков внутри этого объекта (блоки похожих объявлений) со своим сроком протухания.
Вот есть ли такое Cache хранилище, которое умеет такие взаимосвязи поддерживать?
Это называется "Заход солнца вручную".
В JSP кэширование байткода реализовано автоматически.
В JSP кэширование байткода реализовано автоматически.
Sign up to leave a comment.
PHP Performance Series: Caching Techniques