alexkuklin | (no subject)

(no subject)

Есть ли хоть одна причина не использовать storage engine MEMORY для хранения сессий на сайте при условии наличия достаточного количества памяти?....

Flat | Top-Level Comments Only

Зачем использовать это когда есть memcached?..

Кроме того, тебе может пригодиться переменная max_heap_table_size.

затем, что код переписывать я не буду.
а вот alter table - сделать могу легко.

Тогда читай про max_heap_table_size, чтобы та таблица всю память внезапно не съела.

эт я знаю...

Ну а зачем использовать memcached, если, например, машина всего одна?

Как временную помойку в памяти, например?

на frontend приходят за объектом, он ищет его в memcache и если не нашел просит backend сгенерировать его.

Если машина одна, то сетевое соединение - лишний оверхед. Тот же MySQL через сокет или внутрипроцессный кэш будут на порядки быстрее.

1) как вы хотите работать через «внутрипроцессорный кэш»?

2) Соеденение через unix-сокет к mysql лишний оверхед тоже, даешь свою структуру данных!

Вообще плюс этого всего что оно уже есть, написано и отлажено. А еще оно работает и есть примеры как их состыковывать. Написать можно все самому, но сразу возникает вопрос о времени и трудозатратах на поддержку.

Решение nginx + memcached + масенький скрипт на php/python + mysql в поддержке много проще, чем все свое.

1) внутриПРОЦЕССный
2) Да. Лишний. Потому я сказал что лучше внутриПРОЦЕССный. Например berkleydb.

berkleydb тоже написан и отлажен. А memcached нужен только в случае DHT (Distributed Hash Table). Когда нужен ОДИН кэш, ОБЩИЙ кэш, но при этом распределённый по нескольким машинам. Если же у вас не более одной машины, то memcached не нужен.

В список рассылки memcached и libmemcached почти каждую неделю приходят с такими вот идеями и сами разработчики им говорят что memcached им не нужен.

1) внутриПРОЦЕССный

Приношу извенения, не так прочел.

2) Да. Лишний. Потому я сказал что лучше внутриПРОЦЕССный. Например berkleydb.

А чистить его кто будет? Мы сами ручками? А не проще тогда уж memcache интегрировать в приложение и использовать его как кеш? Ну и приложение в веб-сервер интегрировать, что бы не мучаться с оверхедом при передачи данных?

Я в memcache вижу плюс в том, что он сам чистит данные, и не заставляет нас, пользователей, думать, а когда нам данные в кеше больше не нужны и что можно выкинуть.

Ну LRU алгоритм не так уж и сложно запрограммировать. Да и я не сомневаюсь что уже существует куча готовых решений. Не исследовал подробно, так что не могу назвать конкретных представителей.

Не стоит идеализировать memcached. Это всего лишь неплохой hash table с LRU алгоритмом очистки и доступом по сети. Прелесть memcached в его связке с клиентскими библиотеками, которые и реализуют DHT (распределение ключей по различным серверам).

Я говорю лишь о том, что memcached не эффективно использовать в случае одное машины. Это факт. Который подтверждается не только моими экспериментами, но и самими разработчиками memcached и клиентских библиотек.

Одна есть:

ALTER TABLE `sessions` ENGINE = MEMORY
Ответ MySQL:
#1163 - The used table type doesn't support BLOB/TEXT columns

Нельзя пережить без этого? не верю...

Как учит нас Алекс чуть выше:

затем, что код переписывать я не буду.
а вот alter table - сделать могу легко

А разве есть увереность что у него есть blob/text?

а есть уверенность, что нет?

вообще-то в таблице php-шных сессий не используются блобы..

тьфу блин, пропустил мимо мозга, что это не общий случай, а именно частный с сессиями.

Flat | Top-Level Comments Only