openstack/performance-docs
Code Issues Proposed changes

Add short summary

Browse Source 
Change-Id: I4ba4c9659f7babf1cb6ceed39cc510f44ed4108b
This commit is contained in:
Dina Belova 2016-03-30 19:12:46 +03:00
parent e0b9e9a87c
commit 3dcd357915
2 changed files with 43 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/source/test_results/keystone/all-in-one/index.rst
View File

@ -43,6 +43,44 @@ set of commands need to be processed::
openstack --profile SECRET_KEY service list
openstack --profile SECRET_KEY server create --image <image_id> --flavor <flavor_id> <server_name>
Short summary
^^^^^^^^^^^^^
Detailed information about every topology (out of 8 that were examined) can
be found in the next `Reports` section.
Every topology was examined with 5 different profiled control plane requests to
figure out number and relative time spent on the DB / Memcached caching.
All collected data needs to be deeply examined in future, although several
interesting moments can be highlighted right now to pay special attention to
them further.
Due to the collected profiling information, it can be clearly seen that
Keystone was significantly changed during Mitaka timeframe, and lots of changes
seem to be related to the following:
* Federation support (introduced more complexity on the DB level)
* Moving to oslo.cache instead of local `dogpile.cache` usage in Liberty.
Federation support introduced multiple SQL JOINs usage in Keystone and made
the database scheme a bit more complex. As for the caching layer usage, one
specific issue is clearly seen in Mitaka keystone operations caching. Although
all Liberty and Mitaka environments had identical caching layer configuration,
from HTML reports it can be clearly seen that on Liberty all possible methods
were successfully cached and while their calling cached copy was always used.
On Mitaka OpenStack for some reason cached copy was not used sometimes and the
DB requests were processed.
One more interesting moment is related to the `keystone_authtoken` middleware
(and, more specifically, its cache) usage. Although all environments that took
part in the research had exactly the same `keystone_authtoken` middleware
configuration, described in the test plan and containing `memcache_servers`
parameter set up, Mitaka environments profiling shows that all OpenStack
services that used `keystone_authtoken` middleware did not use the external
Memcached cached token copy. All of them used Keystone API every time REST API
request was coming to the OpenStack services. This behaviour needs to be
investigated separately.
Reports
^^^^^^^

5
doc/source/test_results/keystone/index.rst
View File

@ -2,6 +2,11 @@
Keystone Performance Test Reports
=================================
Currently this documentation section includes data and preliminary analysis
collected for all-in-one environment Keystone profiling.
Multi node case needs to be covered separately.
Reports
^^^^^^^