The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз Memcached 1.4.10 со значительным увеличением производительности

15.11.2011 17:54

Анонсирован выход нового релиза системы кеширования данных в оперативной памяти Memcached 1.4.10, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Новая версия примечательна работой, проделанной в направлении увеличения производительности и улучшения поддержки многопоточности. Внесённые оптимизации позволили заметно увеличить производительность конфигураций, в которых memcached работает в 3-6 потоков (от "-t 3" до "-t 6", при использовании значений "-t" больше 6 - производительность падает).

Тестирование пакетом mc-crusher на сервере с четырёхядерным процессором показало, что пропускная способность Memcached возросла с 300 до 930 тысяч операций "set" в секунду, а скорость извлечения данных по ключам увеличилась с 1.6 до 3.7 миллионов операций "get" в секунду. Производительность операций Incr/Decr увеличилась соразмерно с операцией "set". Для систем с большим числом процессорных ядер, по заявлению разработчиков, вполне реально достичь производительности отдачи в 6 миллионов ключей в секунду. При использовании нескольких NUMA-узлов наблюдается незначительное снижение производительности, но не настолько большое, чтобы повлиять на общие показатели.

  1. Главная ссылка к новости (http://groups.google.com/group...)
  2. OpenNews: Некорректное использование Memcached приводит к уязвимостям сайтов
  3. OpenNews: Основатель проекта Memcached представил новую NoSQL СУБД Membase
  4. OpenNews: Bullet Cache - высокопроизводительная система кэширования данных в памяти
  5. OpenNews: Релиз БД Apache Cassandra 1.0
  6. OpenNews: Релиз БД Redis 2.4
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/32306-memcached
Ключевые слова: memcached, speed, cache
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 18:47, 15/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Ни чего себе так поаптомайзили
     
     
  • 2.3, Карбофос (ok), 18:59, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    гораздо интереснее, какой там запас еще остался
     
     
  • 3.12, Аноним (-), 00:31, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > гораздо интереснее, какой там запас еще остался

    Еще около сотни строчек вида for (i=1,i<1000,i++) {};

     
     
  • 4.14, Карбофос (ok), 03:01, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    пустые циклы? они выкидываются компилятором
     

  • 1.2, pavlinux (ok), 18:56, 15/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Осталось придумать куда бы его засунуть?! :)
     
     
  • 2.4, Аноним (-), 19:40, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В кэширующий прокси - фронт-энд балансировки нагрузки на БД, не?
     
     
  • 3.6, all_glory_to_the_hypnotoad (ok), 21:56, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    у всего этого обычно есть свои кеши и memcached там ни в каком виде не нужен.
     
     
  • 4.8, Аноним (-), 22:36, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот я дурак, когда Memcached в помощь nginx использовал, а тот, в свою очередь, отдавал накопленную статику из кэша! Надо было напрямую отдавать SQL-сервер на растерзание, без прикрытия фронт-эндом!..
     
     
  • 5.11, Аноним (-), 00:29, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Простите, у вас nginx кэшировал ответы БД-сервера?
    Скажите, как вам это удалось?
     
     
  • 6.17, Аноним (-), 10:35, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Используй голову, Люк (С)

    Что, не доходит? Динамические страницы можно формировать в БД. Новость?

     
  • 6.18, Аноним (-), 19:14, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем он используется лишь при нестандартных запросах, которых менее 5% от общего числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.
     
     
  • 7.20, Аноним (-), 19:48, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем
    > он используется лишь при нестандартных запросах, которых менее 5% от общего
    > числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.

    Ты совершенно прав, анон. +100500

     

  • 1.5, Аноним (-), 20:23, 15/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эх только перелез на редис.
    Хотя и правильно перелез. ТТЛ нужен, а самому его делать не охото и не правильно.
    Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.
    Короче упреждающее обновление кеша нужно. а без TTL неудобно.
     
     
  • 2.7, Aquarius (ok), 22:31, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а устранить условие гонки никак?
     
  • 2.9, san (??), 22:52, 15/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, сделай, например, чтобы первый, кто полез за данными в базу, установил в memcache в качестве результата для этой операции специальное значение "Work in progress", чтобы другие подождали. Или если получил данные из memcache и точно знаешь, что их нужно закешировать, а TTL вот-вот обнулиться, продли его (чтобы ты был один такой умный) и обнови данные из SQL (как вариант, можно сделать это с некоторой вероятностью, которая тем больше, чем длительнее рассчет этих данных, вместо продлевания TTL, тогда чем больше запросов лезут к этим данным и больше время тратится на их перерассчет, тем больше шансов, что кто-то попытается их продлить до обнуления TTL). Можно оба подхода скомбинировать. Да и сам, если подумаешь, сможешь придумать получше варианты для своей задачи. Тут только главное не переусердствовать, потому что кеш должен содержать данные, которые (часто нужны)*(длительно рассчитываемы), так как все подряд туда не поместится - оперативка ограничена.
     
     
  • 3.19, Аноним (-), 19:47, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Плашка оперативы стоит как лопата д.рьма" (С)

    Ты ничо не напутал, Сан? На дворе 2011й, не 1996й. Чем ограничена оператива? Воображением логистика фирмы?

     
  • 2.21, имя (?), 21:47, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    мда мне бы такие проблемы ...
    php?
    А если серьёзно:
    ключевое слово синхронизация.
     

  • 1.15, AlexAT (ok), 07:32, 16/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>> Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.

    Если у вас при холодном кеше система неустойчива - её пора серьёзно дорабатывать.

     
     
  • 2.16, Аноним (-), 08:45, 16/11/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот поэтому и редис
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру