> I guess it was 16.
Sounds good.
> Separation of django and static content is part of the deployment/setup
> change anyway.
Yes that would definitely help. As mentioned before look at varnish.
rgds
vivek
--
You received this message because you are subscribed to the Google Groups
"Django
On Mon, Jun 4, 2012 at 12:15 PM, vivek wrote:
>
>
> >
> > That's aggregated load time, and not a single page loading time. The test
> > comprised of navigating to multiple pages to generate more real life
> > scenario.
> >
>
> How many pages?
>
I guess it was 16.
>
> >
> > > 3. text/html , whic
>
> That's aggregated load time, and not a single page loading time. The test
> comprised of navigating to multiple pages to generate more real life
> scenario.
>
How many pages?
>
> > 3. text/html , which is the output of django app, is taking 62.74 %
> > time.
>
> This number might not be bad
On Monday, June 4, 2012, vivek wrote:
> Hi,
>
> > To load test I used loadimpact.com and the results of which can be
> found on:
> http://loadimpact.com/load-test/www.reviews42.com-18774e46e8f562a6eb4...
> > The test configuration consisted of 600 VUs with 10 mins step duration.
> > Got around .1
Hi,
> To load test I used loadimpact.com and the results of which can be found
> on:http://loadimpact.com/load-test/www.reviews42.com-18774e46e8f562a6eb4...
> The test configuration consisted of 600 VUs with 10 mins step duration.
> Got around .1 millions requests and around 200+ requests/sec max
On Sat, Jun 2, 2012 at 7:14 AM, Tim Chase wrote:
> On 06/01/12 09:17, Subhranath Chunder wrote:
> > (Given the fact that the server is deployed in Amazon EC2
> > Singapore location, as m1.xlarge with all it's network, memory
> > constrains in place)
>
> A couple of the other aspects that occurred
On 06/01/12 09:17, Subhranath Chunder wrote:
> (Given the fact that the server is deployed in Amazon EC2
> Singapore location, as m1.xlarge with all it's network, memory
> constrains in place)
A couple of the other aspects that occurred to me:
Is there geographical separation between your Django/
On Fri, Jun 1, 2012 at 8:20 PM, Kurtis Mullins wrote:
> To me, the biggest bottleneck in a "Django Application Installation" (not
> application) is not going to be Django at all. It's going to be I/O --
> typically to the database and/or file system.
Yup.
> Another large part are the templates
level.
>
> Just to keep the thread a bit more focused on it's purpose, I would like
> to remind ourselves that, the discussion is on "Scaling django
> installation" and not "Scaling django application".
> For e.g. (with random number representations)
> -
ot;Scaling django installation"
and not "Scaling django application".
For e.g. (with random number representations)
- Setup 1: Single server setup:
x1 Computation Units, x2 GB memory, n Geographical location, Max Serves
2000 requests/sec
- Setup 2: 2 servers cluster setup (1 server se
Check out django-cache-machine. It uses memcache to cache your ORM qureies
and updates (invalidates) that cache when they change.
On Fri, Jun 1, 2012 at 10:35 AM, Tim Chase
wrote:
> On 06/01/12 09:17, Subhranath Chunder wrote:
> > On Fri, Jun 1, 2012 at 6:57 PM, Tim Chase <
> django.us...@tim.the
On 06/01/12 09:17, Subhranath Chunder wrote:
> On Fri, Jun 1, 2012 at 6:57 PM, Tim Chase
> wrote:
>> 2) I/O
>> 2a) disk
>> 2b) network
>> 2c) memory
>>
> Don't think these might be creating much bottleneck in my scenario. But
> still, nothing like getting to exact figures. Again, how would you mea
On Fri, Jun 1, 2012 at 6:57 PM, Tim Chase wrote:
> On 06/01/12 03:56, Subhranath Chunder wrote:
> > With that in mind, how should we measure response complexity?
> > Any particular parameter, scale? Probably I can measure against
> > that, and share the numbers to shed more light on how many
> > r
On Fri, Jun 1, 2012 at 3:56 AM, Subhranath Chunder wrote:
> how should we measure response complexity?
a simple first approximation is the number of DB queries per page.
the debug toolbar nicely gives that figure while developing.
--
Javier
--
You received this message because you are subscr
On 06/01/12 03:56, Subhranath Chunder wrote:
> With that in mind, how should we measure response complexity?
> Any particular parameter, scale? Probably I can measure against
> that, and share the numbers to shed more light on how many
> requests can be handled in with a particular hardware config.
On Fri, Jun 1, 2012 at 1:39 AM, Doug Ballance wrote:
> I don't think anyone will be able to give you a good evaluation
> without knowing more about the requests. Django itself could probably
> handle 10k requests per second returning a simple "hello world"
> response, or less than 10 if you are
I don't think anyone will be able to give you a good evaluation
without knowing more about the requests. Django itself could probably
handle 10k requests per second returning a simple "hello world"
response, or less than 10 if you are returning very large/difficult to
generate responses. It is wh
Bump!
On Wednesday, May 30, 2012, Subhranath Chunder wrote:
> As the subject suggests, wanted to discuss, acquire and share some
> knowledge on scaling django installation.
>
> Firstly, my current project is a product Reviews platform, and I wanted to
> benchmark or load t
As the subject suggests, wanted to discuss, acquire and share some
knowledge on scaling django installation.
Firstly, my current project is a product Reviews platform, and I wanted to
benchmark or load test the current deployment.
Currently the deployment/installation stands on a single server
19 matches
Mail list logo