search

Aexyn / caliper

Automatically exported from code.google.com/p/caliper
Apache License 2.0
0 stars 0 forks source link

Error in the persistence layer blocking some benchmark uploads #282

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Long values for parameters are failing to persist properly.

Original issue reported on code.google.com by gk5...@gmail.com on 20 Dec 2013 at 5:48

GoogleCodeExporter commented 9 years ago 
It looks like the Strings are all stored in columns that are woefully short.  
I'll resize them tomorrow (as to have people awake if anything goes wrong).

Original comment by gak@google.com on 20 Dec 2013 at 5:55

GoogleCodeExporter commented 9 years ago 
I have bumped the size on many of the likely suspects.  Hopefully, this should 
fix it.

Original comment by gak@google.com on 20 Dec 2013 at 8:56

GoogleCodeExporter commented 9 years ago 
This has been reported as fixed.

Original comment by gk5...@gmail.com on 21 Dec 2013 at 2:51

GoogleCodeExporter commented 9 years ago 
I'm again seeing HTTP 500 ISEs when Caliper tries to upload benchmark results. 
See attachment for a sample JSON result file that's failing.

Original comment by robin.sh...@gmail.com on 27 Dec 2013 at 12:22

Attachments:

GoogleCodeExporter commented 9 years ago 
Doing a curl also results in the same error:

curl -X POST -d 
@JSONParsersBenchmark.JSONParsersBenchmark.2013-12-26T23:44:10Z.json 
https://microbenchmarks.appspot.com/data/trials?key=[my-key] --header 
"Content-Type:application/json"

<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>500 Server Error</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Server Error</h1>
<h2>The server encountered an error and could not complete your request.<p>If 
the problem persists, please <A 
HREF="https://code.google.com/appengine/community.html">report</A> your problem 
and mention this error message and the query that caused it.</h2>
<h2></h2>
</body></html>

Original comment by robin.sh...@gmail.com on 27 Dec 2013 at 12:24

GoogleCodeExporter commented 9 years ago 
Back from the holiday break and I got a chance to take a look at this.  The 
issue is your payload parameter.  It's huge (25k characters).  I'm ambivalent 
about allocating storage for columns _that_ large.  Typically, parameters are 
small tokens that represent larger data structures (usable as a flag value) 
rather than a large json string.  Would it be possible to refactor your 
benchmark to work in that style?

Original comment by gak@google.com on 30 Dec 2013 at 7:53

GoogleCodeExporter commented 9 years ago 
I understand. The reason I was using @Param was for convenience. But I really 
do want to benchmark the various JSON parsers against a substantially large 
input string. What do you think would be a better way to pass this data then? 
Should I just read it from a file on startup in a static block and reference it 
in the various testXxx() methods?

Original comment by robin.sh...@gmail.com on 30 Dec 2013 at 9:09

GoogleCodeExporter commented 9 years ago 
I have found that enums are good parameters for this type of thing.  Give the 
values meaningful names and then give the enum a method that returns your test 
data.

Original comment by gak@google.com on 6 Jan 2014 at 5:25