to post messages and comments.

Вопрос на тему lazy vs strict. Насколько я понимаю ленивые строки имеет смысл использовать только тогда, когда у нас есть данные неопределённой длины (или не влазят в память). В случае когда используются небольшие порции данных strict экономнее и удобнее. Т.е. в случае memcached вообще не имеет смысла пытаться пихать данные в ленивые строки и для сериализации лучше cereal. Я правильно мыслю или ошибаюсь?

При активном использовании JSONP'вызовов в сочетании с Memcached порой возникает естественное желание: а пусть данные из memcached отдает прямо nginx, не доводя дело до backend'а. В принципе, nginx умеет ходить в memcached за данными, НО в случае JSONP-вызова, в отдаваемые данных нужно приписываеть callback. Тут есть 2 пути: использовать модуль echo или взять решение, вроде этого: github.com

Но, увы, в Debian'овский nginx данный модуль не входит. По этой причине я пересобрал Nginx (под Squeeze) с его (xss) поддержкой. Кому нужно — пакеты в packages.gnolltech.org. Баги можно репортить сюда.

Впечатления: нагрузка упала на 2 десятичных порядка. Ура-ура!

Неисповедимы пути memcached. Если в него класть 20-символьные строки, состоящие из русских букв, то в 10Mb умещается 94278, а если латиницу, то 17820. Чудо какое-то.

Пришла в голову идея организовать конференцию с хранением сообщений внутри memcached. Получается для всего организуется ассоциативный массив, который сериализуется и хранится внутри memcached. Выборка и отдача из него через php/json. Подгрузка на клиент посредством Ajax. Вот насчет многопоточности не совсем уверен. Покритикуйте. Подскажите как лучше.

Команды Membase и CouchOne объединились в нечто новое...CouchBase!
О том что из этого может выйти можно почитать на couchone.com (не смотря на то, что есть сайт couchbase.com , вся инфа находится в другом месте)
Особенно интересен раздел Technical Vision: неужели у нас появится шанс получить динамическое маштабирование из коробки? Хотя нет, ребята из cloudant будут огорчены таким поворотом событий — все таки старались и bigcouch удался, хоть и костыль, как ни крути, но лучший из имеющихся.

Наконец закончил работу над полосой статистики для progimp.ru Теперь данные собираются и сторятся внутри memcached на минуту. Готовимся потихоньку к апдейту сайта.

Я худею. В PHP перестала работать команда delete, обращённая к memcached! Причём, я так и не понял, чья вина: с одной стороны там что-то изменился протокол memcached, а с другой — PHP как-то криво один из параметров передаёт. Ну кто так делает?!

поставил memcached под винду. чтобы запустить эту байду пришлось найти в интернетахъ DLL-ку. хорошо под FreeBSD всегда из сырцов можно собрать и MSVS ставить не приходится для этого.

Слушайте, вот я точно помню что мне не раз утверждали что у мемкеша скорость доступа к данным O(1). Тоесть не зависит от количества ключей. А есть у кого-нить ссылка на статейку где это доказывают?

rails — тормозной монстр. на средний сайтик не хватило 2х ядерного пня и 2 гиг оперативы. все дико тормозило. пришлось покупать qore2quad и 3G оперативы. еще прикрутил memcached к nginx. вот теперь все летает

Блин. В memcached аж с 2007го года даже есть append!!! Но python'овские библиотеки этот метод нифига не поддерживают!
Кусок готового кода неоткуда стырить даже. Люди чего, зря этот append писали?! Мне, вот, он как раз позарез сейчас нужен!

Запустил memcached 1.2.8 с параметром "-m 2". К нему через unix socket подключены 3 клиента. Средний размер объекта — 2Кб. Потребление памяти — 17 Мб.
Это как понимать?! Я просил остановиться на двух мегабайтах!