Всё равно эти цифры вызывают когнитивный диссонанс :)
Хочется думать, что кешер — это что-то маленькое, шустрое, очевидное в понимании (понять как работает libevent совсем не сложно). А тут получается 41М кода крутится в памяти, и непонятно чем эта вся машинерия занимается. К слову, memcached занимает 2-3К на сервер-процесс.
Всё сказанное выше — личное субъективное мнение. Уверен, что у ehcache есть своя ниша и он там успешно применяется.
1. Я в Java не спец, не буду спорить :)
2. Именно сколько сервер занимает места в памяти. Например, мне нужен 1Г кеш, а сервер+JVM занимает 150М (условно). Тогда, чтобы всё влезло в память и не свопилось, мне нужно смотреть, чтобы в системе было 1.15Г свободной памяти.
>При превышении памяти все будет идти на диск, так что это не будет сильной проблемой
То есть это будет не cache, а storage. И весь выигрыш в производительности будет съеден дисковыми операциями, от которых мы активно уклонялись. А полученная система будет всё больше похожа на RDBMS, где «горячие» данных хранятся в памяти, а всё остальное укладывается на диск.
По ходу прочтения возникло пару вопросов:
1. Как-то подозрительно, что по скорости он обгоняет memcached. Выделение памяти в JVM просиходит быстрее, чем обычный allocate операционной системы?
2. Если импользовать этот кешер, какие накладные расходы по памяти могут возникнуть? Т.е. используюя например memcached ясно, что сервер занимает несколько килобайт (сотен килобайт) памяти. А как дело обстоит с ehcache?
Но ведь по сути, фреймворк — не более чем собрание чужих протестированных «велосипедов». Если понадобится какая-то из ряда вон выходящая возможность, придется разбираться в тонне чужих идей и в еще бОльшем количестве кода.
Я веду к тому, что не надо идеализировать тот же django. Если разрабатываемый проект полностью укладывается в возможности того или иного фреймворка, то тогда да, действительно, всё что нужно сделать — это просто использовать предоставленные наработки.
Простите, но прочитав код и описание, не нашел ничего «действительно умного». Просто реализация сессий под свои конкретные нужды (т.е. временное кеширование сессионной инофрмации в memcache).
Ага. Таки съел.
Там еще есть нюанс с приоритетами операций в PHP. Второй тернарный оператор надо взять в круглые скобки. Вставить правильный код так и не получилось :(
Удивительно, но у меня тоже вчера сломался мой 959NF. Отдал в сервис центр. Надеюсь, что они не закатают огромную цену.
Порадовала тётя, которая на приёме сидит. Говорит, ну мол бывали случаи, когда ремонтировали месяц и взяли 200 грн. А ремонт состоял в замене предохранителя.
В PHP простые типы оттдельно, классы (объекты) отдельно. Возвращая строку «lol» ты возвращаешь именно строку.
Но есть фишки — можно преобразовать массив в объект и объект в строку.
А вообще, всё в мануалах написано :)
Не стоит на нее смотреть как на серьезную production библиотеку. Скорее как на забаву, развлечение. К тому же, она наглядно показывает, как работают fluent interfaces. И можно в код поглядеть, возможно какие-то мысли пригодятся при разработке asList :)
Хочется думать, что кешер — это что-то маленькое, шустрое, очевидное в понимании (понять как работает libevent совсем не сложно). А тут получается 41М кода крутится в памяти, и непонятно чем эта вся машинерия занимается. К слову, memcached занимает 2-3К на сервер-процесс.
Всё сказанное выше — личное субъективное мнение. Уверен, что у ehcache есть своя ниша и он там успешно применяется.
2. Именно сколько сервер занимает места в памяти. Например, мне нужен 1Г кеш, а сервер+JVM занимает 150М (условно). Тогда, чтобы всё влезло в память и не свопилось, мне нужно смотреть, чтобы в системе было 1.15Г свободной памяти.
>При превышении памяти все будет идти на диск, так что это не будет сильной проблемой
То есть это будет не cache, а storage. И весь выигрыш в производительности будет съеден дисковыми операциями, от которых мы активно уклонялись. А полученная система будет всё больше похожа на RDBMS, где «горячие» данных хранятся в памяти, а всё остальное укладывается на диск.
По ходу прочтения возникло пару вопросов:
1. Как-то подозрительно, что по скорости он обгоняет memcached. Выделение памяти в JVM просиходит быстрее, чем обычный allocate операционной системы?
2. Если импользовать этот кешер, какие накладные расходы по памяти могут возникнуть? Т.е. используюя например memcached ясно, что сервер занимает несколько килобайт (сотен килобайт) памяти. А как дело обстоит с ehcache?
Я веду к тому, что не надо идеализировать тот же django. Если разрабатываемый проект полностью укладывается в возможности того или иного фреймворка, то тогда да, действительно, всё что нужно сделать — это просто использовать предоставленные наработки.
как-то подозрительно выглядит. Может быть так
kill –HUP `cat /var/log/nginx/nginx.pid`
Особенно стоит обратить внимание на:
Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset().
Там еще есть нюанс с приоритетами операций в PHP. Второй тернарный оператор надо взять в круглые скобки. Вставить правильный код так и не получилось :(
$plural=($n%10==1 && $n%100!=11? 0: ($n%10>=2 && $n%10
Кстати, хозяйке на заметку :) meld также умеет делать сравнение 3х файлов/папок.
Порадовала тётя, которая на приёме сидит. Говорит, ну мол бывали случаи, когда ремонтировали месяц и взяли 200 грн. А ремонт состоял в замене предохранителя.
такое не кушает, потому что array зарезервированное слово
Но есть фишки — можно преобразовать массив в объект и объект в строку.
А вообще, всё в мануалах написано :)