Re: [Bigdata-developers] After a timeout I get only timeouts

[Michael S. <ms...@me...>]

Hi Daniel,

where are these parsing errors coming from, they might indicate some other problems? And did you change log4j settings or the like, possibly causing the logger to write out too much information? 

In case you’re still stuck, would it be an option to share the data (or an anonymised version thereof) + scripts for running the benchmark (or a set of generated queries that allow to reproduce the problem)? If setup is straightforward, I could give it a quick try on a my machine...

Best,
Michael


> On 21 Apr 2016, at 17:59, Daniel Hernández <da...@de...> wrote:
> 
> Brad, As you said that the thread pool size does not affect queries if I 
> am running them sequentially, then I have not proved modifying it yet. 
> Instead, I proved modifying the order of queries. I post the results here:
> 
> https://gist.github.com/danielhz/6066f0136ede5f50b495acb9236b8e3c
> 
> The first column is the id of the query (now I'm running only 50). 
> Queries are generated parametrically and are of the form
> 
> SELECT * WHERE { P1 OPTIONAL P1 } LIMIT 10000
> 
> Where P1 and P2 are two basic graph patterns generated parametrically. 
> They are not complex basic graph patterns. In fact, each of them has no 
> more than 3 triples patterns. The data is huge. It includes 583 millions 
> of triples.
> 
> The columns in the results are respectively the id of the query, the 
> time and the result status (200 if success) or an error explanation. In 
> the case of a timeout in the http client (timeout status), the time is 
> elapsed time for the query in the client. In the case of a timeout in 
> the server (parsing-error status), the body of the request truncated by 
> a Java exception message and thus not a valid JSON document.
> 
> I the two experiments timeout there are always timeouts. Also, the query 
> that produces the timeout is not necessary complex. In fact, I have run 
> again only the query 48 (that produces the timeout when shuffling 
> queries). I takes 0.9 seconds and gets only 9 solutions.
> 
> Note that between each experiment I restart Blazegraph, thus, I guess 
> that the query was not cached in RAM. Maybe disk pages where cached by 
> the system.
> 
> Thanks,
> Daniel
> 
> 
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers