The has_child and has_parent queries perform a join that is makes your search request slower. How much that depends on the context it is running in. (amount of data, number of primary shards and if these queries are part of a bigger query)
This is the worst possible scenario for the has_child query. If you have other queries next to the has_child query the response time should be much faster. The join will only be computed for documents that match with the other queries.
The has_child is a slow query and is executed as one of the last queries. Other faster queries (like term query) are evaluated first and then only documents that match with the faster queries are being evaluated by the has_child query.
It is very unlikely that has_child queries will ever be cached.
The query cache caches based on usage. So if a query is only used a couple of times, it might not be enough for the query cache to cache it.
Also the has_child query is one a few queries that also require that no changes are made to the index in between searches (the cache key is kind of based on the index itself). This is very rare for an active index.
Did you configure eager global ordinals loading on the _parent field?
(https://www.elastic.co/guide/en/elasticsearch/reference/2.3/mapping-parent-field.html#_global_ordinals)
This can improve the response time.
Parent/child in Elasticsearch scales well. So if the performance is not what you want it to be then you can always increase the number of primary shards (and reindex (from 2.3 their is a reindex api)) and add more nodes.
