GraphQL server response is very slow with a large number of types and interfaces - apollo-server

Env Details :
"#neo4j/graphql": "^3.12.0",
"#neo4j/introspector": "^1.0.2",
"apollo-server": "^3.11.1",
"dotenv": "^16.0.3",
"graphql": "^16.6.0",
"neo4j-driver": "^4.4.3"
OS : Windows10
We have 201 type definitions and 105 interface definitions in graphql file.
neo4j graphql generates SDL file of size around 26 MB ( around 8002 type def in SDL )
Problem is , a simple query takes around 10-15 minutes to get the response and sometimes we don't even get the response.
Below is code snippet to start server
const server = new ApolloServer({
schema: schema,
introspection: true,
playground: true,
});
However, if we work with a smaller number(~20-25) of type definitions then it works as expected.
Is there any size limit or restriction on the number of type definitions in graphql?

Related

Dumping Beam-scores to an HDF File

I have a translation model (TM), which synthesizes its hypotheses using beam-search. For analysis purposes, I would like to study all hypotheses in each beam emitted by the TM’s ChoiceLayer. I’m able to fetch the hypotheses for each input sequence from the TM’s ChoiceLayer and write it to my file system, using the HDFDumpLayer:
'__SEARCH_dump_beam__': {
'class': 'hdf_dump',
'from': ['output'],
'filename': "<my-path>/beams.hdf",
'is_output_layer': True
}
But beside the hypotheses, I would also like to store the score of each hypothesis. I’m able to fetch the beam scores from the ChoiceLayer using a ChoiceGetBeamScoresLayer, but I was not able to dump the scores using an HDFDumpLayer:
'get_scores': {'class': 'choice_get_beam_scores', 'from': ['output']},
'__SEARCH_dump_scores__': {
'class': 'hdf_dump',
'from': ['get_scores'],
'filename': "<my-path>/beam_scores.hdf",
'is_output_layer': True
}
Running the config like likes this, makes RETURNN complain about the ChoiceGetBeamScoresLayer output not having a time axis:
Exception creating layer root/'__SEARCH_dump_scores__' of class HDFDumpLayer with opts:
{'filename': '<my-path>/beam_scores.hdf',
'is_output_layer': True,
'name': '__SEARCH_dump_scores__',
'network': <TFNetwork 'root' train=False search>,
'output': Data(name='__SEARCH_dump_scores___output', shape=(), time_dim_axis=None, beam=SearchBeam(name='output/output', beam_size=12, dependency=SearchBeam(name='output/prev:output', beam_size=12)), batch_shape_meta=[B]),
'sources': [<ChoiceGetBeamScoresLayer 'get_scores' out_type=Data(shape=(), time_dim_axis=None, beam=SearchBeam(name='output/output', beam_size=12, dependency=SearchBeam(name='output/prev:output', beam_size=12)), batch_shape_meta=[B])>]}
Unhandled exception <class 'AssertionError'> in thread <_MainThread(MainThread, started 139964674299648)>, proc 31228.
...
File "<...>/returnn/repository/returnn/tf/layers/basic.py", line 6226, in __init__
line: assert self.sources[0].output.have_time_axis()
locals:
self = <local> <HDFDumpLayer '__SEARCH_dump_scores__' out_type=Data(shape=(), time_dim_axis=None, beam=SearchBeam(name='output/output', beam_size=12, dependency=SearchBeam(name='output/prev:output', beam_size=12)), batch_shape_meta=[B])>
self.sources = <local> [<ChoiceGetBeamScoresLayer 'get_scores' out_type=Data(shape=(), time_dim_axis=None, beam=SearchBeam(name='output/output', beam_size=12, dependency=SearchBeam(name='output/prev:output', beam_size=12)), batch_shape_meta=[B])>]
output = <not found>
output.have_time_axis = <not found>
AssertionError
I tried to alter the shape of the score data using ExpandDimsLayer and EvalLayer, with several different configurations, but those all lead to different errors.
I’m sure I am not the first person trying to dump beam scores. Can anybody tell me, how to do that properly?
To answer the question:
The HDFDumpLayer assert you are hitting is simply due to the fact that this is not implemented yet (support of dumping data without time axis).
You can create a pull request and add this support for HDFDumpLayer.
If you just want to dump this information in any way, not necessarily via HDFDumpLayer, there are a couple of other options:
With task="search", as the search_output_layer, just select the layer which still includes the beam information, i.e. not after a DecideLayer.
That will simply dump all hypotheses including their beam scores.
Use a custom EvalLayer and dump it in whatever way you want.

Always some test cases getting jasmine.DEFAULT_TIMEOUT_INTERVAL

I am going to create end to end(e2e) test using protractor with jasmine and angular 6. I have written some test cases almost 10 cases. That's all working fine, but always some cases become fails. And its failed because of jasmine timeout. I have configure timeout value like below. But I am not getting consistant result. sometimes a test cases is success but at next run it will goes to success or fail. I have searched on google but I have not found any useful solution.
I have defined some common properties for wait
waitForElement(element: ElementFinder){
browser.waitForAngularEnabled(false);
browser.wait(() => element.isPresent(), 100000, 'timeout: ');
}
waitForUrl(url: string){
browser.wait(() => protractor.ExpectedConditions.urlContains(url), 100000, 'timeout')
}
And protractor.conf.js file I have defined that
jasmineNodeOpts: {
showColors: true,
includeStackTrace: true,
defaultTimeoutInterval: 20000,
print: function () {
}
}
I am getting below error
- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
- Failed: stale element reference: element is not attached to the page document
(Session info: chrome=76.0.3809.100)
(Driver info: chromedriver=76.0.3809.12 (220b19a666554bdcac56dff9ffd44c300842c933-refs/branch-heads/3809#{#83}),platform=Windows NT 10.0.17134 x86_64)
I have got the solution:
I have configured waiting timeout 100000 ms for individual element find where whole script timeout was 20000 ms. So I have follow below process:
Keep full spec timeout below than sum of all elements find timeouts. I have configured defaultTimeoutInterval at jasmineNodeOpts greater than sum of value for all test cases timeout. And then add a large value to allScriptsTimeout: 2000000 inside of export.config. Its resolved my problem.
NB: I gave this answer because I think it may help others who will face this kind of problem.

Webpack 4.4.1 : performance issues with splitChunks

I'm working on an old project with a lot of code. This project uses Webpack 3.8.1 and I'm trying to update to 4.4.1, and it's a real obstacle course!
The main pain is that the projects uses the CommonsChunkPlugin:
new CommonsChunkPlugin({
name: 'common',
minChunks: 3,
chunks: _.without(_.keys(entry), 'ace-iframe', 'custom-theme-ace'),
}),
new CommonsChunkPlugin({
name: 'vendors',
minChunks(module, count) {
return isVendorModule(module) && count >= 2;
},
chunks: _.without(_.keys(entry), 'ace-iframe', 'custom-theme-ace'),
})
I know that Webpack 4 does not provide CommonsChunkPlugin anymore. A big thanks a lot to the below articles, they've saved hours of researches:
https://gist.github.com/sokra/1522d586b8e5c0f5072d7565c2bee693
https://medium.com/webpack/webpack-4-code-splitting-chunk-graph-and-the-splitchunks-optimization-be739a861366
Thanks to these amazing links, I've replaced CommonsChunkPlugin with these lines:
optimization: {
splitChunks: {
cacheGroups: {
vendors: {
priority: 50,
name: 'vendors',
chunks: 'async',
reuseExistingChunk: true,
minChunks: 2,
enforce: true,
test: /node_modules/,
},
common: {
name: 'common',
priority: 10,
chunks: 'async',
reuseExistingChunk: true,
minChunks: 2,
enforce: true,
},
},
},
},
},
Thanks to this config, the application is correctly building, chunks are created and the app is running as expected.
But the building time is really slow: more than 7 minutes!
Funny thing, if I totally remove the whole optimization.splitChunks configuration, the applications still works perfectly, and the building time is still around 7 minutes: it's totally like what I've done in optimization.splitChunks is useless.
I've tried to change the chunks properties: to be honest I don't really understand its role...
If I set them to all, the build is way quicker: around 1 minute.
But unfortunately, the generated files from my entries points are not running well: Webpack seems to wait that the chunks are loaded before executing my own code:
// Code from webpack
function checkDeferredModules() {
var result;
for(var i = 0; i < deferredModules.length; i++) {
var deferredModule = deferredModules[i];
var fulfilled = true;
for(var j = 1; j < deferredModule.length; j++) {
var depId = deferredModule[j];
if(installedChunks[depId] !== 0) fulfilled = false;
}
// If I understand well, Webpack checked that deferred modules are loaded
if(fulfilled) {
// If so, it runs the code of my entry point
deferredModules.splice(i--, 1);
result = __webpack_require__(__webpack_require__.s = deferredModule[0]);
}
}
return result;
}
Please tell me I am not wrong here: Webpack seems to wait deferred modules to be loaded, but it does not run the code which is actually loading them... How am I suppose to make this work?
In brief:
with chunks set to async: all is working well, but building time is not viable (more than 7 minutes)
with chunks set to all: building time is correct (around 1 minute), but my code is not running ¯\_(ツ)_/¯
Sorry for this long post, but if someone can help me to make all of this working with correct building time, it would be perfect.
Or at least helping me to understand how all of this is supposed to work, official documentation is not very helpful :(
Thanks in advance!
EDIT: I've tried to continue with chunks set to async, despite the 7mn building time.
I have 20 entries points, and if I add an import instruction importing jQuery and jQuery-UI in one of them, building time is doubling.
If I add it into 5 files, the build crashes:
<--- Last few GCs --->
[15623:0x103000000] 222145 ms: Mark-sweep 1405.0 (1717.4) ->
1405.2 (1717.4) MB, 671.3 / 0.0 ms allocation failure GC in old space requested [15623:0x103000000] 222807 ms: Mark-sweep 1405.2
(1717.4) -> 1405.0 (1667.9) MB, 662.4 / 0.0 ms last resort GC in old
space requested [15623:0x103000000] 223475 ms: Mark-sweep 1405.0
(1667.9) -> 1405.1 (1645.4) MB, 667.1 / 0.0 ms last resort GC in old
space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x1b6415c25ee1
1: fromString(aka fromString) [buffer.js:~298] [pc=0x1973a88756aa](this=0x1b6462b82311
,string=0x1b642d3fe779 ,encoding=0x1b6462b82311 )
3: from [buffer.js:177] [bytecode=0x1b6488c3b7c1 offset=11](this=0x1b644b936599 ,value=0x1b642d3fe779 ,encodingOrOffset=0x1b6462b82311
>> FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Out of memory... I think setting chunks to async is not the correct way to solve this issue :/

increase pageSize of Generic Test Data results in sonarqube 6.2

I have imported test results according to https://docs.sonarqube.org/display/SONAR/Generic+Test+Data into SonarQube 6.2.
I can look at the detailed test results in sonar by navigating to the test file and then by clicking menu "Show Measures". The opened page then shows me the correct total number of tests 293 of which 31 failed. The test result details section however only shows 100 test results.
This page seems to get its data through a request like: http://localhost:9000/api/tests/list?testFileId=AVpC5Jod-2ky3xCh908m
with a result of:
{
paging: {
pageIndex: 1,
pageSize: 100,
total: 293
},
tests: [
{
id: "AVpDK1X_-2ky3xCh91QQ",
name: "GuiButton:Type Checks->disabledBackgroundColor",
fileId: "AVpC5Jod-2ky3xCh908m",
fileKey: "org.sonarqube:Scripting-Tests-Publishing:dummytests/ScriptingEngine.Objects.GuiButtonTest.js",
fileName: "dummytests/ScriptingEngine.Objects.GuiButtonTest.js",
status: "OK",
durationInMs: 8
...
}
From this I gather that the page size is set to 100 in the backend. Is there a way to increase it so that I can see all test results?
You can certainly call the web service with a larger page size parameter value, but you cannot change the page size requested by the UI

API Blueprint and Dredd - Required field missing from response, but tests still pass

I am using a combination of API Blueprint and Dredd to test an API my application is dependent on. I am using attributes in API blueprint to define the structure of the response's body.
Apparently I'm missing something though because the tests always pass even though I've purposefully defined a fake "required" parameter that I know is missing from the API's response. It seems that Dredd is only testing whether the type of the response body (array) rather than the type and the parameters within it.
My API Blueprint file:
FORMAT: 1A
HOST: http://somehost.net
# API Title
## Endpoints [GET /endpoint/{date}]
+ Parameters
+ date: `2016-09-01` (string, required) - Date
+ Response 200 (application/json; charset=utf-8)
+ Attributes (array[Data])
## Data Structures
### Data
- realParameter: 2432432 (number)
- realParameter2: `some string` (string, required)
- realParameter3: `Something else` (string, required)
- realParameter4: 1 (number, required)
- fakeParam: 1 (number, required)
The response body:
[
{
"realParameter": 31,
"realParameter2": "some value",
"realParameter3": "another value",
"realParameter4": 8908
},
{
"realParameter": 54,
"realParameter2": "something here",
"realParameter3": "and here too",
"realParameter4": 6589
}
]
And my Dredd config file:
reporter: apiary
custom:
apiaryApiKey: somekey
apiaryApiName: somename
dry-run: null
hookfiles: null
language: nodejs
sandbox: false
server: null
server-wait: 3
init: false
names: false
only: []
output: []
header: []
sorted: false
user: null
inline-errors: false
details: false
method: []
color: true
level: info
timestamp: false
silent: false
path: []
blueprint: myApiBlueprintFile.apib
endpoint: 'http://ahost.com'
Does anyone have any idea why Dredd ignores the fact that "fakeParameter" doesn't actually show up in the response body and still allows the test to pass?
You've run into a limitation of MSON, the language API Blueprint uses for describing attributes. In many cases, MSON describes what MAY be present in the data structure rather than what MUST exactly be present.
The most prominent case are arrays, where basically any content of the array is optional and thus the underlying generated JSON Schema doesn't put any constraints on array contents. Dredd just respects that, so indirectly it becomes a Dredd issue too, however there's not much Dredd can do about it.
There's an issue for the problem: apiaryio/mson#66 You can follow and comment under the issue to get updated about this. Dredd is usually very prompt in getting the latest API Blueprint parser, so once it's implemented in the language itself, it won't take long to appear in Dredd.
Obvious (but tedious) workaround is to specify your own JSON Schema with stricter rules using the + Schema section alongside the + Attributes section.

Resources