[
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204522#comment-15204522
]
Shawn Heisey commented on SOLR-8393:
------------------------------------
Although I understand that you're going for readability with output like "1000
KB", please strongly consider calculating everything to the same unit size and
including it in the attribute name, such as queryResultCacheKB. With a value
like "1000 KB" or "44.68 MB", it is extremely difficult to write tools that can
do calculations on those numbers.
The same thing needs to be done for other informational responses that Solr
produces. DIH status is one of the really bad ones for parsing in a program.
If human readability is important for a particular response, then two sets of
numbers should be in the output.
> Component for Solr resource usage planning
> ------------------------------------------
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
> Issue Type: Improvement
> Reporter: Steve Molloy
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch,
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run
> Solr. The most common response is that it highly depends on your data. While
> true, it makes for frustrated users trying to plan their deployments.
> The idea I'm bringing is to create a new component that will attempt to
> extrapolate resources needed in the future by looking at resources currently
> used. By adding a parameter for the target number of documents, current
> resources are adapted by a ratio relative to current number of documents.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
