Производительность AWS Neptune - PullRequest
Новая
       22

Производительность AWS Neptune

0 голосов
/ 08 января 2019

Я работаю над переносом данных из нашей базы данных, которая является базой данных rdf-хранилища, в AWS Neptune, и у меня возникают некоторые проблемы с производительностью.

У меня есть экземпляр db.r4.large Neptune & ec2 на том же виртуальном частном процессоре, что и Neptune.

Обычно я пытаюсь загрузить данные в Нептун, используя следующий http-запрос: <myinstance>:8182/sparql.

На самом деле, я отправляю http-запрос от моего экземпляра ec2, и кажется, что обработка Neptune идет медленно. Кроме того, кажется, что обработка Нептуна не параллельна.

Ниже приведены мои тесты и результаты:

  1. Я отправил следующий запрос Нептуну:

    time curl -X POST -d @/tmp/my_file_32m.txt http://myneptune-poc.c0zm6uyrnnwp.us-east-1.neptune.amazonaws.com:8182/sparql

    /tmp/my_file_32m.txt содержит команды вставки sparql, и время для этого запроса равно 34.037s, в то время как Нептун утверждает, что он занял 21.846 s: 

    {
"type" : "Commit",
"totalElapsedMillis" : 21846
}

    real 0m34.037s
    user 0m0.044s
    sys 0m0.062s

    A tcpdump может убедительно доказать, что ответ от Нептуна был получен с задержкой в ​​34 секунды.

  2. Когда я отправил данные на 100 м, это заняло более 1 минуты.

  3. Когда я отправил один и тот же файл длиной 32 метра, время было кратно 2:

    time xargs -I % -P 8 curl -vX POST -d @/tmp/my_file_32m.txt "http://myneptune-poc.c0zm6uyrnnwp.us-east-1.neptune.amazonaws.com:8182/sparql" < <(printf '%s\n' {1..2})<

    {
"type" : "Commit",
"totalElapsedMillis" : 29797
}
{
"type" : "Commit",
"totalElapsedMillis" : 30362
}

    real 0m57.752s
    user 0m0.137s
    sys 0m0.101s

    Я взял tcpdump и ясно вижу из wireshark, что запрос был отправлен параллельно, но есть задержка ~ 1 мин, пока Нептун не вернул 200 OK для обоих запросов.

    На самом деле кажется, что обработка Нептуна не параллельная.

    запрос был отправлен во время 12 и 200 ok для обоих запросов был отправлен во время 69, что составляет ровно 57 секунд задержки.

  4. Я пытался увеличить размер экземпляра Neptune до db.r4.xlarge, а также до db.r4.2xlarge, дБ, но я получил ту же производительность.

  5. Я пытался отправить сжатые данные в формате gzip, чтобы улучшить время, но, похоже, Нептун его не поддерживает (при проверке wireshark запрос был отправлен правильно).

Хотелось бы услышать ваше мнение о моих тестах и ​​результатах:

  1. почему скорость выполнения одного HTTP-запроса низкая?
  2. почему обработка Нептуна не параллельна?

1 Ответ

0 голосов
/ 10 января 2019

Вы сравниваете вывод time (время приема-передачи на стороне клиента) с сообщенным сервером totalEllapsedMillis. Первый включает в себя время передачи в вашей сети, где в качестве второго используется только время, которое БД потребовалось для вычисления запроса с момента, когда он принял запрос. У вас есть какие-либо показатели времени, необходимого для передачи файла размером 100 МБ?

Нептун обрабатывает запросы параллельно (фактически количество параллелизма масштабируется в зависимости от типа вашего экземпляра). Если ваши запросы действительно малы по сравнению с тем временем, которое они проводят в сети, тогда они могут выглядеть как результаты, выполненные один за другим. Я хотел бы увидеть более детальную информацию о ваших экспериментах, чтобы увидеть, есть ли проблема с вашей настройкой.

Для начала, какова задержка сети между вашим клиентом и конечной точкой БД? (т.е. сколько времени у вас занимает, например, чтобы сделать запрос к / status API)

...