The first site will soon become a reality. Last minute questions

I'm really close to completing the project I'm working on. I used to make websites, but never on my own and never used a website that included user generated data.

I read things to consider before starting to live , and I have some questions.

1) Staging ... (Deploying updates without affecting users). I'm not quite sure what this will entail, since I'm sure that any type of update will affect users in some way. Does this mean some type of temporary downtime for each update? can someone please explain this and the solution to this.

2) Limits ... I use the Kohana framework and I use the Auth module to login. I was wondering if this already has a certain type of restrictions (when trying to login), and if not, what would be the best way to implement this. (saving attempts in the database, cookie, etc.). If this is not what is meant by the limit, someone can clarify.

Edit: I think a good way to do this would be to freeze the login for a certain period of time (e.g. 15 minutes) or display an interception after several (about 10) fuzzy login attempts

3) Caching ... As I said, this is my first site based on user content. Given this, should it be cached?

4) Backups ... How often do I need to backup my (MySQL) database and how do I create it (export MySQL?).

Currently, the site is up, not yet finished , if someone wants to look at it and see that something pops up for you, which should be viewed / fixed. Clashing Thoughts .

If there is anything else that I forgot, it is not yet listed on the list above, please let me know.

Edit: If anyone has any advice regarding getting the word (marketing), I will appreciate it too.

Thanks.

EDIT: I made changes, and the site is now live.

+4
source share
3 answers

1) Most sites that include frequent updates, or when they are a massive update that takes some time, use a beta domain such as beta.example.com, which is limited to staff until it is released to the main site for the public.

2) If you use cookies, then they can simply turn off cookies and have endless attempts to log in, so your efforts will be in vain. So yes, use a database. How you want it to track is up to you.

3) Depends on what type of content it is and how much it is. If you have many different variables, you should only store key variables that recognize data in the database, and store all additional data in the cache so that database queries are executed faster. You can quickly find the desired results, and then simply open the cache file associated with them.

4) It is up to you, it really depends on the traffic. If you get only 2 or 3 new data per day, you probably won't want to waste time and space maintaining it every day. Postscript Export MySQL works very well, I find them much easier to import and work.

+1
source

1) You will need to minimize your site. I try to create jobs and then do a big update at the end of the month.

2) In terms of restricting login attempts; Cookies will be easy to implement, but not perfect, this will prevent most of your users, but it can be easily bypassed, so it would be better to choose a different method. Using a database would be better, but a little more difficult to implement and could increase the load on the database.

3) Cacheing largely depends on how often content is updated or changed. If the content changes a lot, it may not be worth caching data, but if there is a lot of static, perhaps using something like memcache or APC will be useful.

4) You should always make regular backups. I do one day with a cron job on my home server, although a weekly one will be enough.

+1
source

Side notes: YSlow indicates that:

  • you don’t upload headings to your CSS or images (makes pages load slower and costs more bandwidth)
  • You have CSS files that are not handled by gzip compression (same problems).
  • Also consider moving your static content (CSS, images, etc.) to a separate domain (CDN) for faster loading times.
0
source

Source: https://habr.com/ru/post/1304666/


All Articles