Я создавал простое приложение для запроса базы данных cassandra с использованием драйвера python cassandra-driver. Мое требование - получать 5 000 запросов в секунду.
Spec goes as below:
1. Cassandra 3.11 has one keyspace and one table with 10k records
2. Using Python cassandra-driver to query the data from above table.
3. Deployed cassandra on kubernetes using statefulset on 3 nodes. I am using standard settings with 6 core vCPUs in GKE.
Я запустил 10k запросов за 2-3 минуты. Я мог получить ответ из таблицы в течение 10 мс для 80% запросов, но иногда он превышает 50 мс до 100 мс для других 20%. Когда я исследовал обнаружил, что это может быть связано с проблемой JVM (2019-03-09T15: 30: 11.110-0530: 908.491: Общее время, в течение которого потоки приложения были остановлены: 0,0203039 секунд).
журналы для справки:
2019-03-09 15:30:11.076271 DB time taken ! 0:00:00.011658
2019-03-09 15:30:11.080144 DB time taken ! 0:00:00.013943
2019-03-09 15:30:11.080273 DB time taken ! 0:00:00.013248
2019-03-09 15:30:11.148072 DB time taken ! 0:00:00.079689
2019-03-09 15:30:11.148147 DB time taken ! 0:00:00.079215
2019-03-09 15:30:11.148367 DB time taken ! 0:00:00.067695
2019-03-09 15:30:11.148464 DB time taken ! 0:00:00.066383
2019-03-09 15:30:11.154260 DB time taken ! 0:00:00.069872
фрагмент кода:
t1 = datetime.now()
result = session.execute('SELECT * FROM a.b WHERE key = %s', [key])
t2 = datetime.now()
logger.debug('DB time ! ' + ' ' + str(t2 - t1))
Здесь я хочу, чтобы 95% запросов были в пределах 50 мс, но из-за JVM 20-30% из них превышают 50 мс.
Когда я выполнял нагрузочное тестирование с помощью инструмента стресса, результаты были удовлетворительными, но не тогда, когда я запускал запросы с помощью приведенного выше кода:
Results:
Op rate : 33,700 op/s [single_read: 33,700 op/s]
Partition rate : 5,301 pk/s [single_read: 5,301 pk/s]
Row rate : 5,301 row/s [single_read: 5,301 row/s]
Latency mean : 11.6 ms [single_read: 11.6 ms]
Latency median : 6.2 ms [single_read: 6.2 ms]
Latency 95th percentile : 41.5 ms [single_read: 41.5 ms]
Latency 99th percentile : 61.8 ms [single_read: 61.8 ms]
Latency 99.9th percentile : 100.9 ms [single_read: 100.9 ms]
Latency max : 263.7 ms [single_read: 263.7 ms]
Total partitions : 318,523 [single_read: 318,523]
Total errors : 0 [single_read: 0]
Total GC count : 0
Total GC memory : 0.000 KiB
Total GC time : 0.0 seconds
Avg GC time : NaN ms
StdDev GC time : 0.0 ms
Total operation time : 00:01:00
Я прошел через очень много предложений, но нигде не нашел решения с этим требованием.
Может ли кто-нибудь подсказать мне, как сократить время, затрачиваемое JVM на кассандру, или сократить время, которое затрачивает кассандра на запуск JVM?
Примечание:
Я выполнил все возможные рекомендации по настройке (кеш строк, фильтр Блума, уплотнение и т. Д.), Чтобы получить вышеуказанную производительность.
cqlsh:a> select * from b where key = '34823049392304' ;
key | name | password
----------------+------+-----------
34823049392304 | test | test33k23
(1 rows)
Tracing session: 467f0a90-4489-11e9-88ab-3ff1c33f5d2f
activity | timestamp | source | source_elapsed | client
--------------------------------------------------------------------------------------+----------------------------+------------+----------------+-----------
Execute CQL3 query | 2019-03-12 05:39:59.545000 | 10.12.88.4 | 0 | 127.0.0.1
Parsing select * from b where key = '34823049392304' ; [Native-Transport-Requests-1] | 2019-03-12 05:39:59.545000 | 10.12.88.4 | 328 | 127.0.0.1
Preparing statement [Native-Transport-Requests-1] | 2019-03-12 05:39:59.546000 | 10.12.88.4 | 565 | 127.0.0.1
Row cache hit [ReadStage-3] | 2019-03-12 05:39:59.547000 | 10.12.88.4 | 1467 | 127.0.0.1
Read 1 live rows and 0 tombstone cells [ReadStage-3] | 2019-03-12 05:39:59.547000 | 10.12.88.4 | 1729 | 127.0.0.1
Request complete | 2019-03-12 05:39:59.547018 | 10.12.88.4 | 2018 | 127.0.0.1