Comments 11
Отдельное спасибо за информацию что JVM теперь доступна для open-source разработчиков!
можно пояснить доступным языком что такое «Перцентили»? :)
Говорят что N-й перцентиль — это такое значение, ниже которого расположено N процентов наблюдений данной переменной.
Например, 95-й перцентиль — это значение, ниже которого расположено 95% результатов наблюдений; 50-й перцентиль называется медианой, а 25-й и 75-й перцентили — нижним и верхним квартилями соответственно…
Например, 95-й перцентиль — это значение, ниже которого расположено 95% результатов наблюдений; 50-й перцентиль называется медианой, а 25-й и 75-й перцентили — нижним и верхним квартилями соответственно…
т.е. по подобию линий тренда, только по максимальным, средним и минимальным значениям?
Ну не совсем. Например график с перцентилем 95% показывает что в результате теста более чем 5% запросов отработало дольше чем 4,5 секунды (Вплоть до 20 секунд).
Учитывая, что мы в течении часа пускали запросы на скорости 225 запросов в секунду, то всего отработало 3600*225=810 000 запросов, при этом 40 500 из них работало крайне медленно. Т.е. потенциально мы потеряли 40 с половиной тысяч клиентов.
Учитывая, что мы в течении часа пускали запросы на скорости 225 запросов в секунду, то всего отработало 3600*225=810 000 запросов, при этом 40 500 из них работало крайне медленно. Т.е. потенциально мы потеряли 40 с половиной тысяч клиентов.
Теперь понятно. Интересный опыт.
Я на данный момент использую вариацию из 2х индексов, один (большой) на диске, только для чтения, второй в памяти для хранения всех изменений. Сами изменения из второго периодически мержатся на диск, при накоплении «критического» числа изменений, либо при остановке приложения, также предусмотрено и аварийное завершение.
По сколько к диску операции идут только на чтение, а размер второго индекса в памяти относительно небольшой, то работает все очень быстро, покрывая наши потребности, 10-15 тыс запросов в секунду не заставляют даже толком задуматься сервер, но это максимум, обычно рабочая нагрузка 5-7 тыс запросов в секунду, на данный момент.
Основная проблема в этом решение — организовать поиск по двум индексам сразу, исключая при этом удаленные данные и используя актуальные из памяти, для конкретных задач я ее решил.
Размер самого индекса не превышает 20 Гб. Пробовал полностью индекс запихнуть в память через RAMDirectory, но наблюдал при этом значительное падение производительности, сколько бы серверу памяти не выделял (пробовал до 64 гб). Возможно, при росте нагрузке, попробую и ваше решение.
Я на данный момент использую вариацию из 2х индексов, один (большой) на диске, только для чтения, второй в памяти для хранения всех изменений. Сами изменения из второго периодически мержатся на диск, при накоплении «критического» числа изменений, либо при остановке приложения, также предусмотрено и аварийное завершение.
По сколько к диску операции идут только на чтение, а размер второго индекса в памяти относительно небольшой, то работает все очень быстро, покрывая наши потребности, 10-15 тыс запросов в секунду не заставляют даже толком задуматься сервер, но это максимум, обычно рабочая нагрузка 5-7 тыс запросов в секунду, на данный момент.
Основная проблема в этом решение — организовать поиск по двум индексам сразу, исключая при этом удаленные данные и используя актуальные из памяти, для конкретных задач я ее решил.
Размер самого индекса не превышает 20 Гб. Пробовал полностью индекс запихнуть в память через RAMDirectory, но наблюдал при этом значительное падение производительности, сколько бы серверу памяти не выделял (пробовал до 64 гб). Возможно, при росте нагрузке, попробую и ваше решение.
Да, в моем решении еще бывают простои на несколько секунд в момент мержа, но стараюсь данные дробить, чтобы все проходило прозрачно для пользователей.
Кстати, не секрет — что это у вас за задача такая, где тоже немаленький индекс, и при этом хорошая такая нагрузка в 5-7 запросов в секунду?
сервис apishops, могу написать в грубом приближении, т.к. подробно выйдет отдельная статья :)
у нас десятки тысяч прайсов разных рекламодателей, которые загружаются по несколько раз на дню, товаров в прайсе может быть неск сотен тысяч, для каждого товара из каждого прайса по названию, модели, производителю и еще паре десятков правил производится привязка товаров к системной базе (по размерам сравнима с яндекс-маркетом), тут и используется lucene, т.к. необходим постоянный полнотекстовый поиск.
Такая скорость необходима, чтобы клиенты не засыпали саппорт тикетами про долгую обработку их прайсов.
у нас десятки тысяч прайсов разных рекламодателей, которые загружаются по несколько раз на дню, товаров в прайсе может быть неск сотен тысяч, для каждого товара из каждого прайса по названию, модели, производителю и еще паре десятков правил производится привязка товаров к системной базе (по размерам сравнима с яндекс-маркетом), тут и используется lucene, т.к. необходим постоянный полнотекстовый поиск.
Такая скорость необходима, чтобы клиенты не засыпали саппорт тикетами про долгую обработку их прайсов.
А можно и не ждать увеличения нагрузки, а уже сейчас сильно упростить архитектуру, запихнув полный 20Гб индекс в память, при этом не потеряете производительность.
Sign up to leave a comment.
Размещаем индекс Lucene в RAM при помощи Azul Zing JVM