Утилита в данном случае — генератор пользовательских запросов. Чтобы тест был релевантным, нужна еще одна прослойка. Согласитесь, если точки A и B обмениваются данными со скоростью 340 тыс. rps, а B и C тоже со скоростью 340 rps, то вовсе не факт, что A и C через B тоже будут обмениваться с такой же скоростью. Про memcached уже писал.
У FARа собственный обработчик командной строки, в частности, echo, cd он не передает в cmd.exe.
Хотя у меня Far 2.0 b1777 на «echo.ON» напечатал, как и полагается, ON.
Используется FIFO по принципу циклического буфера. Полное обновление сегмента происходит в течение 8-12 часов, т.е. время жизни объекта в кеше составляет не менее 8 часов. При таких показателях FIFO полностью устраивает, в то время как честная реализация LRU значительно усложнила бы логику распределения памяти.
Вот эта фраза не очень понятна:
если сегмент заполнен, линейным поиском по массиву ссылок находятся и удаляются из индекса ключи, чьи данные будут перезаписаны очередным блоком
Старые данные (картинки) вытеснять из кеша не надо, они и так перезаписываются поверх. Но нужно удалять их id из индекса. Для этого пробегаем по порядку весь индекс, удаляя те ключи, чьи значения попадают в перезаписываемую область.
На самом деле, я знал правильный ответ, поэтому и задал вопрос.
Но вам плюс за то, что провели анализ и исправились.
Мало того, что использование массива делает пример менее читаемым, так этот вариант еще и медленнее, и менее эффективен по памяти (массив содержит дополнительное поле с длиной). Доступ к полю объекта компилируется в одну машинную инструкцию, в то время как доступ к элементу массива сопровождается дополнительными проверками на выход за границы.
Не знаю, почему ваш тест не показал разницы — возможно, из-за несоблюдений правил микробенчмаркинга, — но в моем тесте, который можно взять здесь, четко прослеживается, что и аллокация массива, и доступ к нему оказывается на ~30% медленнее.
Немного быстрее будет если заменить класс-обертку одноэлементным массивов. И то, и другое HotSpot успешно компилирует в быстрый код, но доступ к элементам массива происходит немного быстрее.
Можно с этого места поподробнее? Почему доступ к элементам массива быстрее?
Может, MutableInteger и полезен, но пример не совсем удачный. Для указанной задачи идеально подходит TObjectIntHashMap из библиотеки Trove с его методом adjustOrPutValue.
Не далее как вчера обнаружил ошибку в JIT-компиляторе Oracle JVM, где как раз генерируется неправильный код, приводящий к Segmentation Fault. Перед этим два дня тщетно искал ошибку в своей программе. Зарепортил баг.
Запрос к хранилищу — около 1 мс. Обращение в локальный кеш — 2 мкс. Число потоков выбирали экспериментально: от 64 до 128 разницы почти не было, при >200 начала снижаться максимальная пропускная способность, при <32 росло максимальное время отклика.
1. Потоки ждут в epoll_wait(). Некоторые висят на запросе в хранилище. С трафиком справилось бы и меньшее число потоков, но так мы уменьшаем максимальное время отклика. И 100 потоков — это не 10 тысяч, накладные расходы на переключение незаметны.
2. Справедливая, чтобы не могла возникнуть ситуация «голодания» записывающего потока. Сравнивали производительность со случайной стратегией — никакой разницы.
3. Генератор простой, и хеш простой. Про любой хеш-функции будут перекосы из-за того, что одни картинки более популярны, другие менее. Но это нестрашно: время полного обновления сегментов составляет несколько часов. Память в кеше используется в среднем на 99.4%.
Не так. Раньше smile download сервис обслуживался 8-ю серверами с Tomcat. На время эксперимента весь трафик вместо этих серверов был направлен на один единственный сервер, про который идет речь в статье, и он выдержал с хорошим запасом. HTTP-сервер, blob storage клиент и кеш работают в одном Java-процессе.
Все так. С той лишь оговоркой, что семафор должен быть справедливым (fair), дабы избежать зависания (starvation) потока-писателя.
Примитивы синхронизации в Java, в том числе ReentrantReadWriteLock и Semaphore, при захвате и освобожении обеспечивают полный memory barrier, в частности, все записи памяти в одном потоке (неважно, чем они сделаны, записью в поле объекта или через Unsafe) будут видны в другом потоке.
У Apache JCS принципиально другой подход к кешированию — патчем там не обойтись.
Исходники нашей реализации открыты — если под условия задачи подходит, можно брать и пользоваться.
Насколько медленнее — не замерял, но прежде всего с количеством запросов не справится. Сейчас смотрю на один из наших blob-storage серверов с 4мя дисками — он обрабатывает в пике около 2 тыс. запросов в секунду. При этом IO Utilization составляет 20%. Т.е. при 10 тыс. запросов сервер загнется на дисковом I/O. Наш же download обрабатывает 70 тыс. запросов, и при этом остается еще приличный запас.
Причем здесь NFS?
Узкие места бывают разного рода и устраняются разными способами: проблема с latency похода в хранилище решается размером локального кеша, нагрузка на CPU — быстрым алгоритмом кеширования и эффективным HTTP-сервером.
Что этот пример показывает? Где здесь out-of-process?
Хотя у меня Far 2.0 b1777 на «echo.ON» напечатал, как и полагается, ON.
Старые данные (картинки) вытеснять из кеша не надо, они и так перезаписываются поверх. Но нужно удалять их id из индекса. Для этого пробегаем по порядку весь индекс, удаляя те ключи, чьи значения попадают в перезаписываемую область.
Но вам плюс за то, что провели анализ и исправились.
Мало того, что использование массива делает пример менее читаемым, так этот вариант еще и медленнее, и менее эффективен по памяти (массив содержит дополнительное поле с длиной). Доступ к полю объекта компилируется в одну машинную инструкцию, в то время как доступ к элементу массива сопровождается дополнительными проверками на выход за границы.
Не знаю, почему ваш тест не показал разницы — возможно, из-за несоблюдений правил микробенчмаркинга, — но в моем тесте, который можно взять здесь, четко прослеживается, что и аллокация массива, и доступ к нему оказывается на ~30% медленнее.
Можно с этого места поподробнее? Почему доступ к элементам массива быстрее?
adjustOrPutValue.2. Справедливая, чтобы не могла возникнуть ситуация «голодания» записывающего потока. Сравнивали производительность со случайной стратегией — никакой разницы.
3. Генератор простой, и хеш простой. Про любой хеш-функции будут перекосы из-за того, что одни картинки более популярны, другие менее. Но это нестрашно: время полного обновления сегментов составляет несколько часов. Память в кеше используется в среднем на 99.4%.
4. Очень даже используем, но здесь не та ситуация. Напомню одно из требований к кешу — in-proccess. Сравнить с Memcached или Tarantool/Box можно, но смысл? См. habrahabr.ru/company/odnoklassniki/blog/148139/#comment_5000546
Примитивы синхронизации в Java, в том числе ReentrantReadWriteLock и Semaphore, при захвате и освобожении обеспечивают полный memory barrier, в частности, все записи памяти в одном потоке (неважно, чем они сделаны, записью в поле объекта или через Unsafe) будут видны в другом потоке.
Исходники нашей реализации открыты — если под условия задачи подходит, можно брать и пользоваться.
Узкие места бывают разного рода и устраняются разными способами: проблема с latency похода в хранилище решается размером локального кеша, нагрузка на CPU — быстрым алгоритмом кеширования и эффективным HTTP-сервером.