Re: new to Django and building web applications. Advice with postgresql

[Kevin Daum]

On Sunday, May 19, 2013 6:51:09 PM UTC-4, Scott Anderson wrote:
>
>
> I highly recommend *against* waiting for PostgreSQL until deployment. 
> There are significant differences between SQLite, PostgreSQL, and MySQL. If 
> you wait until deployment to test on your production database you will find 
> yourself fixing and changing things at the last minute. Start testing on 
> your production deployment database as soon as possible.
>
>
I'm going to echo Scott's sentiment. I ran into enough 
difficult-to-troubleshoot (or just annoying) issues resulting from 
inconsistencies between sqlite and postgres that I no longer allow my 
developers to use sqlite at all. We now use vagrant to install debian VMs 
running postgres on all our developer machines. We have a shell script that 
automatically creates and configures a database for the project, so it 
doesn't end up taking too much longer to set up than sqlite.

That said, if you're just getting started with django, you probably don't 
want to deal with postgres yet. Feel free to tinker and learn against 
sqlite, but once you start writing code that you're eventually going to put 
into production, I'd start using whatever database you're going to use in 
production.

Kevin 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Benchmarking django application using ab (apache benchmark)

[Kevin Daum]

ab is one of the standard options. There are more listed here on 
StackOverflow.
 
You could also check out loads , 
though it's still a prototype.

Kevin

On Tuesday, May 7, 2013 12:24:00 PM UTC-4, Subodh Nijsure wrote:
>
> Hi, 
>
> I have deployed a web site that using nginx for serving static content 
> and apache2 (mod_wsgi) to handle the django requests. I have optimized 
> obvious things  that chrome browser show things like compression, 
> expiration, js minification etc. 
>
> Now I am looking at doing some bench marking of this setup. 
>
> Basically I have extracted the sessionid and csrftoken after I login 
> to my web site and then run 
>
> ab -n 1 -c 1 -C 
> "csrftoken=4BAfoZRrvvATWISgLcCIOOA963YpmNk0;sessionid=bxw1yy9jpmx1ox9y1nxfl8t8aptkkd0r"
>  
>
> http://mywebsite.com/customer/list 
>
> Is that how most people do the performance bench mark of the web site 
> or is there better way to keep tab on web site performance. 
>
> Is there another, better way to do stress testing and keeping tab of 
> django based web site? 
>
> -Subodh 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Automated updating of data across staging and production environments?

[Kevin Daum]

Do you need to preload the staging database with production data in order 
to properly test the site? If not, you could create a fresh staging 
database (no data) every time you update staging. After people test it and 
if there are no issues, you could use dumpdata with natural keys to export 
the staging data. Then convert the 
primarykeys
 to 
null.
 
Finally, use loaddata to load the data into the production database. Using 
Fabric, as Victor mentioned, would be a step towards automating the process.

Kevin

On Thursday, July 26, 2012 10:29:58 AM UTC-4, Victor Rocha wrote:
>
> I partly agree with the above question. It's a solution, but you usually 
> never want to use your production database on a development server. 
>
> As for his problem, I would look into fabric. You can easily write a 
> function that dumps data from one database and into another.
>
>
> On Thursday, July 26, 2012 6:10:33 AM UTC-4, Lloyd Dube wrote:
>>
>> Hi all,
>>
>> We have an Ubuntu Linux server which is running virtual environments (one 
>> for staging, one for prod.). Our clients test their sites on the staging 
>> environment and then proceed to capture the same data on the live sites. 
>> They want to be able to, at the click of a button, migrate only the latest 
>> data to the live sites. If users have submitted new data (e.g. contact 
>> requests) on the prod. server, this data must not be affected.
>>
>> Is it possible to achieve this, and if so, are there any tools oout there 
>> to consider? Any feedback would be appreciated.
>>
>> Thanks.
>>
>> -- 
>> Regards,
>> Sithembewena Lloyd Dube
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-5TLxRPI8J4J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Automated updating of data across staging and production environments?

[Kevin Daum]

Sithembewena,
Have you considered using the same database for staging and production? 
Then the problem would be solved by purging the old test data they no 
longer want, which I think would be much easier than partial, conditional 
synchronization. 

Kevin

On Thursday, July 26, 2012 6:10:33 AM UTC-4, Lloyd Dube wrote:
>
> Hi all,
>
> We have an Ubuntu Linux server which is running virtual environments (one 
> for staging, one for prod.). Our clients test their sites on the staging 
> environment and then proceed to capture the same data on the live sites. 
> They want to be able to, at the click of a button, migrate only the latest 
> data to the live sites. If users have submitted new data (e.g. contact 
> requests) on the prod. server, this data must not be affected.
>
> Is it possible to achieve this, and if so, are there any tools oout there 
> to consider? Any feedback would be appreciated.
>
> Thanks.
>
> -- 
> Regards,
> Sithembewena Lloyd Dube
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/u82IRzTwfmwJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to deploy new code to the Production Server?

[Kevin Daum]

I use pip and virtualenv for reproducible environments, nginx and
gunicorn as production web servers, init.d scripts (on debian) for
managing gunicorn (and just about everything other important process
on the server), mercurial for source control and fabric for
deployment. I keep all files necessary for deployment in the project
directory (and therefore in source control) so that they stay
together. This includes templates for nginx configuration and the init
script, since I use fabric for both initial deployment and all
subsequent updates.

I have three separate settings files for deployment, test, and
production. They don't import from each other yet, but that would be
much better (thanks John). Fabric symlinks settings.py to whichever
one is appropriate for the environment.

My fabric file has separate functions for test and production which
just set some fabric environment variables (domain, IP, etc.).

This setup has worked well thus far. In the future I'd like to have
the settings, fabfiles, nginx and init script templates all import
common settings from some central place.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.