Как стать автором
Обновить

Комментарии 9

Добротная статья, еще и написанная в 04:24 :)

По ходу прочтения возникло пару вопросов:
1. Как-то подозрительно, что по скорости он обгоняет memcached. Выделение памяти в JVM просиходит быстрее, чем обычный allocate операционной системы?

2. Если импользовать этот кешер, какие накладные расходы по памяти могут возникнуть? Т.е. используюя например memcached ясно, что сервер занимает несколько килобайт (сотен килобайт) памяти. А как дело обстоит с ehcache?
спасибо :) писалась где-то с 21:00 вечера, и незаметно так дошло до четырех утра :)

1. Я никак не берусь утверждать, что обгоняет. На java-платформе есть тесты (когда нативное Java-приложение обращается к EHCache и к Memcached) — там да, обгоняет, частично это связано с различной архитектурой. Не забываем также, что в случае репликаций ситуация также другая.

2. В смысле — сколько сервер в памяти занимает или сам кеш? JVM запускается с ограничениями по памяти, да и по статистике можно получить текущий расход. Кроме этого, я бы не стал постоянно думать о памяти, а сосредоточился на количестве элементов — это более наглядная оценка, да и важная приложению (хотя когда как). При превышении памяти все будет идти на диск, так что это не будет сильной проблемой.
1. Я в Java не спец, не буду спорить :)
2. Именно сколько сервер занимает места в памяти. Например, мне нужен 1Г кеш, а сервер+JVM занимает 150М (условно). Тогда, чтобы всё влезло в память и не свопилось, мне нужно смотреть, чтобы в системе было 1.15Г свободной памяти.

>При превышении памяти все будет идти на диск, так что это не будет сильной проблемой

То есть это будет не cache, а storage. И весь выигрыш в производительности будет съеден дисковыми операциями, от которых мы активно уклонялись. А полученная система будет всё больше похожа на RDBMS, где «горячие» данных хранятся в памяти, а всё остальное укладывается на диск.
в случае стандартного дистрибутива (я отключил все неиспользуемые кеши и SOAP) — 62.5 Мб. Попробую протестировать после переноса на Tjws, для интереса.

Нет, это просто комбинированый кеш — можно конечно отключить диск вообще, но это уже по потребностям конкретным. До баз оно далеко все равно будет :) ближе к key/Value стораджам, чего я и хотел добиться, если честно (первоначальная идея вообще почему стал смотреть сюда)
Подтверждаю — если использовать ehcache-server (в виде war-файла) 0.8 версии (последняя на сегодня) и запускать под самым миниатюрным и быстрым сервером — Tjws, то java-процесс занимает 41 Мб памяти вместо 62.5 для сервера под GassFish :) скорость пока не тестировал
Всё равно эти цифры вызывают когнитивный диссонанс :)
Хочется думать, что кешер — это что-то маленькое, шустрое, очевидное в понимании (понять как работает libevent совсем не сложно). А тут получается 41М кода крутится в памяти, и непонятно чем эта вся машинерия занимается. К слову, memcached занимает 2-3К на сервер-процесс.

Всё сказанное выше — личное субъективное мнение. Уверен, что у ehcache есть своя ниша и он там успешно применяется.
более гибкое управление кешом.
когда я начинал исп кеширование были только гет, сет и делит… а теперь сколько там методов+ еще и бинарный протокол.

мир не стоит на месте, и этому проектту наверное будет зеленый свет.
JVM по определению не может обогнать написанные на Си программы.
что-то с измерениями ни так на счет с memcached.
скорее тормозит где-то в самом пшп, ну и для масштабируемых и высокопроизводительных систем ZF не лучший инструмент разработки.

в nginx есть замечательный модуль memcached, который читает напрямую из кеша, что вполне можно построить для AJAX
с записью в кеш посложнее, но я разработал модуль, который может писать в кеш, так что производительность не страдает.

мемкеш, тоже может масштабироваться,

за статью спасибо, интересный материал.
возможно, если бы она мне попалась раньше
мы бы это дело обсосали бы на одном их Hi++ проектах

пока обошлись AJAX с исп: nginx+ memceched + memcecheset {модуль проходит тестирование}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации