1

I'm aware of the hugely trafficked sites built in Django or Ruby On Rails. I'm considering one of these frameworks for an application that will be deployed on ONE box and used internally by a company. I'm a noob and I'm wondering how may concurrent users I can support with a response time of under 2 seconds.

Example box spec: Core i5, 8Gb Ram 2.3Ghz. Apache webserver. Postgres DB.

App overview: Simple CRUD operations. Small models of 10-20 fields probably <1K data per record. Relational database schema, around 20 tables.

Example usage scenario: 100 users making a CRUD request every 5 seconds (=20 requests per second). At the same time 2 users uploading a video and one background search process running to identify potentially related data entries.

1) Would a video upload process run outside the GIL once an initial request set it off uploading?

2) For the above system built in Django with the full stack deployed on the box described above, with the usage figures above, should I expect response times <2s? If so what would you estimate my maximum hits per second could be for response time <2s?

3) For the the same scenario with Ruby On Rails, could I expect response times of <2s?

4) Specifically with regards to response times at the above usage levels, would it be significantly better built in Java (play framework) due to JVM support for concurrent processing.

Many thanks

Duncan

Duncan
  • 151
  • 1
  • 4
  • Django buffers large uploads (>25MB) to disk, so video uploads are most likely bound by disk IO speed, not CPU speed. As such the GIL won't have any significant effect on uploads. Anyway, a proper architecture that allows scaling the number of threads, processes and servers is much more important for the scalability of web applications than whatever language you choose. 20 requests/sec sounds [pretty reasonable](http://stackoverflow.com/a/887363/2615075) for a single server to handle without any performance degradation. That should work for any reasonable language and framework. – knbk Mar 31 '17 at 14:02
  • Thank you for the thorough answer knbk. You've given me a clearer picture. I agree a multi threaded architecture will ultimately be more scalable – Duncan Apr 01 '17 at 10:32
  • So are you saying for video uploads the interpreter will quickly deal with the request to begin upload, the upload will then buffer to disk for the duration of the upload, thus taking no Python processing, then just momentarily grab the gil to complete the file write. – Duncan Apr 01 '17 at 10:48
  • The exact behaviour depends on your WSGI- and webserver. Worst-case Django will read chunks from memory and buffer them to disk, but then the thread will wait for disk IO most of the time, and other threads will have a chance to get the GIL. The same happens with database queries: while the thread waits for the database to respond, other threads will be able to get the GIL and perform CPU tasks. In general you won't notice the GIL if you use a reasonable number of threads, unless your application _heavily_ depends on long-running CPU tasks. – knbk Apr 01 '17 at 12:02
  • Cool thanks. That helps me understand a bit better. Also good to be reminded that multiple webserver threads should still be used. – Duncan Apr 03 '17 at 14:17

0 Answers0