1. В gradle символ ":" используется вместо "/" и для более ветвистой структуры ссылки на проект могут выглядеть так ":loaders:xml-loader"
2. Если не ошибаюсь, в последних версиях таск wrapper можно не описывать в build.gradle
3. Т.к. файлы gradlew и gradlew.bat расположены в корневой папке проекта, запускать сборку приходится используя "../gradlew". Либо можно использовать специальные скрипты (необходимо положить в папку прописанную в PATH): forums.gradle.org/gradle/topics/gradlew_scripts_in_gradle_bin_to_find_gradlew_scripts_upwards_within_project_space
Насчет того, что в HTTP большую часть времени занимает установка соединения — категорически рекомендую использовать HTTP клиент с поддержкой keep-alive.
В первом тесте «ростил» очередь до 1кк сообщений.
И цель была не сравнить производительность очередей, а узнать что можно получить от Rabbit в амазоновском окружении. Стоит ли использовать Rabbit или хватит SQS.
Мне кажется, что держать стабильно 300-500к сообщений в очереди — это плохая практика, очередь плохое место для хранения данных. Такое возможно в исключительных случаях, но этот вариант я и проверил в первом тесте — средняя скорость отдачи не сильно зависит от количества сообщений в очереди.
В первом тесте я загружал в очередь 1кк сообщений, а потом выгружал. Всё в 5 потоков. Появилялись проблемы и скорость падала, но не критично.
Если у вас размер очереди доходит до 300к сообщений, то может стоит увеличить количество обработчиков?
К сожалению не могу сказать про игры.
Вот статистика по SO:
— 800 http requests per second
— 55 mbit per second
Можете охарактеризовать нагрузку в real-time играх?
Почему пинг должен сильно возрасти? Балансировщик и игровые сервера будут находиться в одной сети и интерфейсы могут быть достаточно быстрыми.
Для HotSpot есть опция -XX:BiasedLockingStartupDelay=xxx которая указывает после какого времени после запуска можно начинать использовать оптимизацию.
Ещё добавлю линк на этот тест, выглядит довольно интересно: java.dzone.com/articles/biased-locking-osr-and
Потоки в Executor не хранят состояния и их там не так много, что бы был заметен оверхед. Вся информация о задаче хранится в объектах с интерфейсами Runnable или Callable. Они создаются при необходимости и отправляются в очередь, откуда их заберут свободные потоки Executor'а и выполнят.
Я не спорю, что Erlang был бы оптимальнее для этой задаче — мне самому так кажется. Я за правильное понимание работы java.util.concurrent.
P.S. У Erlang'a не треды, а процессы. Разница в разделяемой памяти — у процессов её нет. По этой причине нельзя сказать, что в Erlang'е используются зелёные потоки.
Создание — да, дорогое. Но в Java есть реализация ExecutorService которая позволяет переиспользовать ранее созданные потоки: ThreadPoolExecutor
При правильном подборе параметров и выборе очереди можно подстроиться под многие задачи.
Нет, не относится. High I/O инстансы, о которых я говорил имеют пометку:
I/O Performance: Very High (10 Gigabit Ethernet).
+ про них отдельно написано, что они используют SSD.
P.S. Cluster Compute так же имеют Very High (10 Gigabit Ethernet) в описании, но SSD не используют.
Есть желание собрать дома полигон для экспериментов, т.к. играться с амазоном не всегда удобно.
Что можете посоветовать по железу в рамках 1к $?
Для организации storage планирую отдельный NAS. И тут ещё один вопрос: взять NAS типа QNAP TS-412
и использовать 2 массива RAID1 и RAID0 — один для хранения своих данных, второй для виртуалок, или взять тот же QNAP на 2 винта и пару винтов в сам сервер поставить?
За ранее извиняюсь за возможное ламерство, но с виртуализацией знаком пока только на уровне конечного пользователя.
Тут как говорится «вам шашечки или ехать?» :)
В контексте использования DynamoDB цены не такие уж и дорогие.
Стоимость динамо на 10к чтения и 1к записи будет примерно 2к$ в месяц. На ssd с mongo, мне кажется, можно добиться более высоких скоростей за меньшие деньги.
Есть ещё Cluster Computing инстансы, стоят в 2.5 раза меньше, чем High I/O. В них обычные ebs или тоже на базе ssd?
Помимо raid 10 на ebs посмотрите в сторону high i/o instances.
На них обещают бОльшую производительность io, чем на High-Memory Quadruple Extra Large Instance.
Про них можно почитать в конце странички: aws.amazon.com/ec2/instance-types/
Но сразу скажу: сам я с ними не работал, поэтому стоит почитать отзывы в интернете.
Согласен, не интересен в рамках амазона, если у них не падают узлы.
Разница в функционале всё-таки есть:
Heartbeat — для общего ресурса, когда надо не более одного владельца.
Keepalived — для общего ip адреса, когда надо не менее одного владельца.
keepalived работает там же, где и ngnix, т.е. если 2 сервера с nginx, то на обоих работает keepalived и следит, что бы как минимум за одним из серверов был закреплён определённый ip адрес.
1. В gradle символ
":"используется вместо"/"и для более ветвистой структуры ссылки на проект могут выглядеть так":loaders:xml-loader"2. Если не ошибаюсь, в последних версиях таск
wrapperможно не описывать вbuild.gradle3. Т.к. файлы
gradlewиgradlew.batрасположены в корневой папке проекта, запускать сборку приходится используя"../gradlew". Либо можно использовать специальные скрипты (необходимо положить в папку прописанную в PATH): forums.gradle.org/gradle/topics/gradlew_scripts_in_gradle_bin_to_find_gradlew_scripts_upwards_within_project_spaceА можно тут подробнее?
Тут согласен — стоило всё же включить его в тесты.
Использовал. Только с durable очередями возможно организовать репликацию active-active в рэбите.
И цель была не сравнить производительность очередей, а узнать что можно получить от Rabbit в амазоновском окружении. Стоит ли использовать Rabbit или хватит SQS.
Мне кажется, что держать стабильно 300-500к сообщений в очереди — это плохая практика, очередь плохое место для хранения данных. Такое возможно в исключительных случаях, но этот вариант я и проверил в первом тесте — средняя скорость отдачи не сильно зависит от количества сообщений в очереди.
Если у вас размер очереди доходит до 300к сообщений, то может стоит увеличить количество обработчиков?
Вот статистика по SO:
— 800 http requests per second
— 55 mbit per second
Можете охарактеризовать нагрузку в real-time играх?
Почему пинг должен сильно возрасти? Балансировщик и игровые сервера будут находиться в одной сети и интерфейсы могут быть достаточно быстрыми.
serverfault.com/questions/281230/how-to-setup-haproxy-with-failover
Ещё добавлю линк на этот тест, выглядит довольно интересно:
java.dzone.com/articles/biased-locking-osr-and
Я не спорю, что Erlang был бы оптимальнее для этой задаче — мне самому так кажется. Я за правильное понимание работы java.util.concurrent.
P.S. У Erlang'a не треды, а процессы. Разница в разделяемой памяти — у процессов её нет. По этой причине нельзя сказать, что в Erlang'е используются зелёные потоки.
При правильном подборе параметров и выборе очереди можно подстроиться под многие задачи.
I/O Performance: Very High (10 Gigabit Ethernet).
+ про них отдельно написано, что они используют SSD.
P.S. Cluster Compute так же имеют Very High (10 Gigabit Ethernet) в описании, но SSD не используют.
Есть желание собрать дома полигон для экспериментов, т.к. играться с амазоном не всегда удобно.
Что можете посоветовать по железу в рамках 1к $?
Для организации storage планирую отдельный NAS. И тут ещё один вопрос: взять NAS типа QNAP TS-412
и использовать 2 массива RAID1 и RAID0 — один для хранения своих данных, второй для виртуалок, или взять тот же QNAP на 2 винта и пару винтов в сам сервер поставить?
За ранее извиняюсь за возможное ламерство, но с виртуализацией знаком пока только на уровне конечного пользователя.
В контексте использования DynamoDB цены не такие уж и дорогие.
Стоимость динамо на 10к чтения и 1к записи будет примерно 2к$ в месяц. На ssd с mongo, мне кажется, можно добиться более высоких скоростей за меньшие деньги.
Есть ещё Cluster Computing инстансы, стоят в 2.5 раза меньше, чем High I/O. В них обычные ebs или тоже на базе ssd?
На них обещают бОльшую производительность io, чем на High-Memory Quadruple Extra Large Instance.
Про них можно почитать в конце странички: aws.amazon.com/ec2/instance-types/
Но сразу скажу: сам я с ними не работал, поэтому стоит почитать отзывы в интернете.
Разница в функционале всё-таки есть:
Heartbeat — для общего ресурса, когда надо не более одного владельца.
Keepalived — для общего ip адреса, когда надо не менее одного владельца.