1

Possible Duplicate:
Very large HTTP request vs many small requests

I need a 2D array(as Json) to be sent from server to client. It would be around 400X400 in size with each entry around 4 characters of text. So that makes it around 640KB of data.

Which of the following extreme approaches is better ?

  1. I make a large HTTP request of all the data at one go.
  2. I make 400 requests - each asking for a single row (around 1.6 KB)

I believe optimal approach would be somewhere in middle. Could anyone give me an idea what might be the optimal single request size for this data.

Thanks,

Community
  • 1
  • 1
Nikhil Garg
  • 3,944
  • 9
  • 30
  • 37
  • Please don't repost your questions, use the `edit` link if you need to change it. – falstro Jun 29 '10 at 07:08
  • I am sorry but I dint repost it knowingly . My connection was stuck & it was showing question status to be unsent. I refreshed the page after reconnecting & now we have duplicate copies. :( – Nikhil Garg Jun 29 '10 at 07:47

4 Answers4

7

When making a request you always have to deal with some overhead (like DNS request, opening connection and closing it). So it might be wiser to have 1 big request.

Also you might experience better gzip/deflate compression when having 1 big request.

Gertjan
  • 850
  • 6
  • 9
  • @eugeneK: json is no different than normal HTTP requests. The result is parsed as JSON when it gets back on the server. So use the same technique. – Gertjan Jun 29 '10 at 07:11
4

Depends on the application and the effect you wish to achieve. Here are two scenarios:

  • if you are dealing with a GUI then perhaps chunking is a good idea where a small chunk would update the visuals giving an illusion of 'speed' to human. Here you want to logically chunk up the data as per gui update requirements. You can apply this same concept to prioritizing any other pseudo-real-time scenario.

  • If on the other hand you are just dumping this data then don't chunk, since 100 6 byte requests are overall significantly more time consuming than 1 600 byte request.

Generally speaking however, network packet transportation (TCP) chunking and delivery is FAR more optimized than whatever you could come up with at the application transport layer (HTTP). Multiple requests / chunks means multiple fragments.

It is generally a futile effort to try to do transport layer optimizations using application layer protocol. And, IMHO it defeats the purpose of both :-)

If you have real time requirements for whatever reason, then you should take control of the transport itself and do optimization there (but that does not seem to be the case).

Happy coding

Elf King
  • 1,189
  • 5
  • 7
3

Definitely go with 1 request and if you enable gzip compression on the server you wont be sending anything near 640KB

All the page speed optimisation tools(eg yslow, google page speed etc) recommend reducing the number of requests to speed up page load times.

Geoff Appleford
  • 18,538
  • 4
  • 62
  • 85
-4

Small number of HTTP requests would be better so make one Request.

Prav
  • 183
  • 5
  • 2
    Please also share WHY it is better in your opinion. – Gertjan Jun 29 '10 at 07:12
  • The recommendation is to build small components/widgets with their own request. If you proceed in this way you will update and delete it easily because it has no dependency. It's easy to maintain and you will not face a bad user experience because the browser will render the first given server response(the users are giving feedback), so you have 1+ from me. – Spawn Mar 08 '16 at 08:44