Opvragen aantal records in applicatie

[Chris-1992]

Dag Tweakers,

Ik hoop dat jullie met de weinig info dat ik heb iets kunnen doen.

Via onze app gaan wij relaties ophalen (Woonplaats, naam,..)
App > Clientservice op iis > SQL DB

In de URL gaat hij 5000records willen ophalen (Standaard meegegeven vanuit de app)

Als men dit veranderd naar 50records dan lukt het wel.

Dit haalt hij op:

Output:


Volgens onze dev wordt dat aantal records beperkt tot 2185 op de IIS server.
Is er een mogelijkheid om dat te verhogen op de IIS?

Alvast bedankt,

[ Voor 17% gewijzigd door Chris-1992 op 12-07-2018 20:35 ]

[alt-92]

Blijkbaar weet die dev voldoende om de max HTTP byte limit exact te relateren aan het aantal records....

[Chris-1992]

@alt-92 die aantal 2185 heb ik zelf uitgezocht.. Ik vraag het hier omdat ik van dev verder geen hulp krijg

maar de HTTP byte limit moet verhoogd worden?
Dit kan ik misschien nog wel terug vinden in de config van de clientservice

<?xml version="1.0"?>
<configuration>
<appSettings configSource="Web.AppSettings.config" />
<system.web>
<compilation targetFramework="4.0"/>
<httpRuntime maxQueryStringLength="2097151" maxUrlLength="2097151"/>
</system.web>
<system.serviceModel>
<!--<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" />
</diagnostics>-->
<bindings>
<webHttpBinding>
<binding name="TransferService" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" transferMode="Streamed">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
<security mode="None"/>
</binding>
</webHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="ServiceBehaviour" name="TechAppService.TechAppService">
<endpoint address="" behaviorConfiguration="web" binding="webHttpBinding" bindingConfiguration="TransferService" contract="TechAppService.ITechAppService"/>
</service>
<service behaviorConfiguration="ServiceBehaviour" name="TechAppService.AppService01346">
<endpoint address="" behaviorConfiguration="web" binding="webHttpBinding" bindingConfiguration="TransferService" contract="TechAppService.ILambrechtsAppService"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviour">
<!-- To avoid disclosing metadata information, set the values below to false before deployment -->
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="web">
<webHttp defaultOutgoingResponseFormat="Json" defaultBodyStyle="Bare"/>
</behavior>
</endpointBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" minFreeMemoryPercentageToActivateService="0"/>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<!--
To browse web app root directory during debugging, set the value below to true.
Set to false before deployment to avoid disclosing web app folder information.
-->
<directoryBrowse enabled="true"/>
<security>
<requestFiltering>
<requestLimits maxQueryString="2097151"/>
</requestFiltering>
</security>
</system.webServer>
</configuration>

[ Voor 122% gewijzigd door Chris-1992 op 12-07-2018 13:26 ]

[Dido]

Je kunt je ook afvragen of je echt wel zo'n hoeveelheid data over je lijn wilt pompen in een enkel request.
Gaat je app iets doen met die data (als in, aggregeren)? Zo ja, doe dat dan lekker server-side.
Zo nee, waarom heb je dan 5000 records nodig? Geen enkele gebruiker gaat die in één keer bekijken.

Als je om de een of andere reden een snapshot van je data in je app beschikbaar wilt maken (bijvoorbeeld voor off-line bewerking of beschikbaarheid, dan kun je altijd nog overwegen om de data naar je app te streamen.

[reb3lzrr]

Dido schreef op donderdag 12 juli 2018 @ 13:33:
Je kunt je ook afvragen of je echt wel zo'n hoeveelheid data over je lijn wilt pompen in een enkel request.
Gaat je app iets doen met die data (als in, aggregeren)? Zo ja, doe dat dan lekker server-side.
Zo nee, waarom heb je dan 5000 records nodig? Geen enkele gebruiker gaat die in één keer bekijken.

Als je om de een of andere reden een snapshot van je data in je app beschikbaar wilt maken (bijvoorbeeld voor off-line bewerking of beschikbaarheid, dan kun je altijd nog overwegen om de data naar je app te streamen.

Het is ook heel normaal om je API / Request te limiteren tot een max aantal data-enteiten wat de afnemer mag opvragen. Je server kan namelijk op deze manier heel makkelijk overloaded raken door iedereen die de hele database leeg trekt.

In het geval dat je alle records wil, dan moet je zorgen dat er paginering is geïmplementeerd of iets dergelijks. Dan kan je rate/request-limits toepassen en jezelf beschermen tegen kwaadwillende.

[Chris-1992]

@Dido Dat klopt, het is ver van ideaal maar de app is zo nu eenmaal geschreven en kunnen er niet meer omheen.
Deze synct de data volledig offline zodat bij (bijvoorbeeld) factureren de klant, aritkels,.. offline beschikbaar zijn.

@reb3lzrr En als die paginering niet geïmplementeerd is, hoe kan ik hier dan omheen?

[Dennism]

Ik zou mogelijk ook maar eens kijken of dit wel voldoet aan de privacy wetgeving. Als iedereen op deze wijze zomaar een hele database met persoonsgegevens kan opvragen heb ik daar toch zeer mijn twijfels bij. Tenzij dit op een andere wijze zeer zeer goed afgeschermd is.

[DJMaze]

Chris-1992 schreef op donderdag 12 juli 2018 @ 13:20:
....
In de URL gaat hij 5000 records willen ophalen (Standaard meegegeven vanuit de app)
....
Volgens onze dev wordt dat aantal records beperkt tot 2185 op de IIS server.
....

Tijd voor een andere ontwikkelaar die weet hoe het moet?

Er bestaat niet zoiets als een "beperking", er bestaat wel zoiets als een "beperkte ontwikkelaar".
Dat een SQL server maar 2185 records per keer kan opvragen, wil niet zeggen dat ik dan de query in een loop 1000x kan aanroepen om 2185000 records naar jouw app te sturen.

Waarom je dat überhaupt wilt geeft ook aan dat iets structureel fout zit in het proces.

[P_Tingen]

De app is 'nou eenmaal zo geschreven' en toch krijg je het advies om het max aantal te verlagen? Hoe doe je dat dan?

En als dat kennelijk wel mogelijk is - en je kennelijk persé alle records wil hebben (met anderen hierboven eens dat er ergens iets schuurt) - wat is er dan op tegen om het in meerdere stappen te doen? Doe een request met &StartIndex=0&EndIndex=2000 en dan nog een met &StartIndex=2001&EndIndex=4000 etc

[Dido]

DJMaze schreef op donderdag 12 juli 2018 @ 14:40:
Er bestaat niet zoiets als een "beperking", er bestaat wel zoiets als een "beperkte ontwikkelaar".
Dat een SQL server maar 2185 records per keer kan opvragen, wil niet zeggen dat ik dan de query in een loop 1000x kan aanroepen om 2185000 records naar jouw app te sturen.

Je weet dat er een verschil zit tussen een IIS server en een SQL server?

DJMaze schreef op donderdag 12 juli 2018 @ 16:04:
@Dido yep,

Het punt is dus dat het ging om een IIS-limitering, en je hele rant over incompetente developers die niet met een zogenaamde SQL-server-limitering om zouden kunnen gaan dus kant noch wal raakt...

[ Voor 26% gewijzigd door Dido op 12-07-2018 16:12 ]

[DJMaze]

@Dido yep, IIS is een verzameling serverdiensten.

Een SQL server is een server die als doel heeft alleen databases te serveren en niks anders. Daarvoor heb je RDBMS producten zoals PostgreSQL, Oracle Database, MySQL, MariaDB, Microsoft SQL Server, etc. etc. etc.

Dido schreef op donderdag 12 juli 2018 @ 15:09:
Het punt is dus dat het ging om een IIS-limitering, en je hele rant over incompetente developers die niet met een zogenaamde SQL-server-limitering om zouden kunnen gaan dus kant noch wal raakt...

Dan nog blijft mijn punt overeind.

"Volgens onze dev wordt dat aantal records beperkt tot 2185 op de IIS server."

De URI is geen records, maar bestaat uit karakters.
Als TS karakters bedoelt en niet records, had ie dat moeten formulieren.

En dan nog is het geen probleem want je kan heel makkelijk de maxUrlLength aanpassen of je code zodat je parameters POST ipv GET.

Als het om ASP of whatever gaat die klapt, had TS toch echt een compleet ander verhaal moeten typen dan nu. IIS doet namelijk niks (op de maxUrlLength na)

[ Voor 64% gewijzigd door DJMaze op 12-07-2018 16:23 ]

[Chris-1992]

@P_Tingen De App vraagt er 5000 op, maar er worden er maar max 2184 gegeven door de server.
Die 2184 moet ik verhogen omdat DEV het aantal niet wil verlagen
Probleem is dat ik niet weet waar ik dit moet of kan verhogen.. (Kan hier ook niks van terug vinden op google, weet ook niet hoe te zoeken)

Die request in verschillende stappen doen wordt meegegeven in de code van de app?
DEV krijg ik niet zover om dit te veranderen..

Antwoord:

dat is idd vast gecodeerd in de app.
er zijn klanten waarbij de sync te traag ging met kleinere requests
het was daar interessanter om met grotere blokken te werken.

dan kunnen we trouwens met hetzelfde probleem komen
tenzij we klein genoeg gaan, maar dan schiet het aantal requests naar de db en het aantal queries op de db navenant omhoog

[ Voor 29% gewijzigd door Chris-1992 op 12-07-2018 20:22 ]

[DJMaze]

@Chris-1992 weet je deze nog: Webservices - portaal - Onvoeldoende schrijruimte
Ik heb een déjà vu dat we nu alweer de deskundigheid van je IT partners aan het oplossen zijn.
Ik pas hiervoor.

[ Voor 4% gewijzigd door DJMaze op 12-07-2018 16:29 ]

[Chris-1992]

DJMaze schreef op donderdag 12 juli 2018 @ 16:28:
@Chris-1992 weet je deze nog: Webservices - portaal - Onvoeldoende schrijruimte
Ik heb een déjà vu dat we nu alweer de deskundigheid van je IT partners aan het oplossen zijn.
Ik pas hiervoor.

Haha, breek mij de mond niet open.
Dat probleem is wel opgelost geraakt door het op tweakers te posten

Jij bent wel actief op elk forum

Als het om ASP of whatever gaat die klapt, had TS toch echt een compleet ander verhaal moeten typen dan nu. IIS doet namelijk niks (op de maxUrlLength na)

Dat dacht ik dus ook..
En wat hij gaat ophalen zijn tabellen uit SQL.
Maar de developer was ervan overtuigd dat dit prob in IIS zat..

Eens kijken als ik op SQL niv ergens het aantal kan opvoeren


Dit haalt hij op:

Output:

[ Voor 41% gewijzigd door Chris-1992 op 12-07-2018 20:35 ]

[arvidbeheerder]

Je wilt de aantallen dus niet opvoeren, je wilt dat je dev een fatsoenlijke app schrijft. Die limieten zitten er niet voor niets in en er zijn hierboven prima oplossingen geschreven om de 5000 regels alsnog op te halen.

Overigens ben ik het helemaal met Dennism eens dat je wel een hele goede reden moet hebben om zoveel privacy gevoelige gegevens over te pompen naar een lokaal device.

[Chris-1992]

arvidbeheerder schreef op donderdag 12 juli 2018 @ 20:36:
Je wilt de aantallen dus niet opvoeren, je wilt dat je dev een fatsoenlijke app schrijft. Die limieten zitten er niet voor niets in en er zijn hierboven prima oplossingen geschreven om de 5000 regels alsnog op te halen.

Overigens ben ik het helemaal met Dennism eens dat je wel een hele goede reden moet hebben om zoveel privacy gevoelige gegevens over te pompen naar een lokaal device.

Ik ben het met iedereen eens die hierboven gepost heeft.
Ik wou dat ik de app kon aanpassen en het op die manier laten werken.
Maar dit kan ik helaas niet..

[Osxy]

Chris-1992 schreef op donderdag 12 juli 2018 @ 20:41:
[...]


Ik ben het met iedereen eens die hierboven gepost heeft.
Ik wou dat ik de app kon aanpassen en het op die manier laten werken.
Maar dit kan ik helaas niet..

Nee is ook een antwoord.

[DJMaze]

Chris-1992 schreef op donderdag 12 juli 2018 @ 20:41:
Ik wou dat ik de app kon aanpassen en het op die manier laten werken.
Maar dit kan ik helaas niet..

Hoeft ook niet, je moet gewoon een heel streng gesprek hebben met "DEV" waarom hij geen rekening houdt met de MaxJsonLength en de SQL max cache/buffer en de max memory.

Als ik een "chunk" script schrijf, krijg je als result meer iets als:

JavaScript:

{
    total: 456123, /* total records */
    records: [
        {
            id: 1,
            givenname: 'henk'
        },
        {
            id: 2,
            givenname: 'ingrid'
        }
    ]
}

[Question Mark]

Let daarna ook erg goed op de security omtrent dit soort constructies. De applicatie lijkt op het eerste gezicht redelijk gevoelig voor stringmanipulatie...

[Chris-1992]

@Osxy Toch krijg ik het als ik deze opmerkingen allemaal doorgeef

@DJMaze Dat is hopeloos, mijn vorige post heb ik dit al proberen doen.. Bij dit probleem trouwens nog eens..
Maar krijg altijd zelfde antwoord. "De app is nu eenmaal zo geschreven"

@Question Mark Ze zouden in orde zijn met de GDPR, de security hierrond.. geen idee.. Denk niet dat er ooit een pen tester hier opgezeten heeft.

[DJMaze]

Chris-1992 schreef op vrijdag 13 juli 2018 @ 18:02:
@DJMaze Dat is hopeloos, mijn vorige post heb ik dit al proberen doen.. Bij dit probleem trouwens nog eens..
Maar krijg altijd zelfde antwoord. "De app is nu eenmaal zo geschreven"

Dan zou ik de rekening / zijn loon niet uitbetalen onder het mom van "mijn administratie app is nu eenmaal zo geschreven"

[Question Mark]

Chris-1992 schreef op vrijdag 13 juli 2018 @ 18:02:
@Question Mark Ze zouden in orde zijn met de GDPR, de security hierrond.. geen idee.. Denk niet dat er ooit een pen tester hier opgezeten heeft.

Vraag het na bij de developer, of bij je management....

[Chris-1992]

@DJMaze Dag Tweakers,
Er is een nieuwe developer voor de APP's en uiteindelijk hebben ze de app's gewijzigd en ervoor gezorgd dat het aantal records dat ze per keer ophalen verlaagd is!

Bedankt voor jullie input alweer!