Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What I want to do is caching every database query into files. The queries will be cached with names including users' user names or user ids. Of course when a user changes its information, the cache file will be replaced with the new one. Even the interactons like friendship between users will be cached.
If I have 1.000.000 users, I will have millios (maybe billions) of files. Is this good or bad for the performance?
This will fill out your file system so it depends on the amount of space you have. Also, this would degrade performance based on the file lookups if you have a large number of active users.
In any case I would recommend using Memcache or APC as the laravel docs say.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have a website (Laravel + Mysql on top of 'dedicated server') where I save all the pages that every user sees for reporting.
My site is visited 10,000 times a day and this statistic makes the database size bigger after a few months. now 'visits' table occupied 85% of whole database!
Is there a way to do this that is the best way possible?
I have not encountered this problem before, but I think its better to take the logging with this much of heavy load out of primary database, you can move it to a file system or logging services (read this).
Or you can have job (background process) to remove the logs that you don't need Like logs from a month ago, this will help db a little bit.
Read some best practices
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I was wondering which is the most efficient. Assigning 7 session variables when the user is logged in or passing the user ID and making new sql queries when the information is needed. I want to cater for mobile users with low download allowanaces as well and we don't have free wifi around here.
PHP is all done server side so I don't think there are any considerations here for mobile users, other than the usual ones such as keeping the page downloads small and accessible. In other words, the server resources are the bottleneck here, so go whichever way you like! Generally speaking storing values (caching) is going to be faster in terms of processing, but could use more memory than fetching stuff as you need it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently working on a project that uses MySQL for configuration, but now I'm starting to think it could slow down page loads.
So my question is, would it be better to store configuration options (that are read almost every page load) inside an XML/JSON file, or a MySQL database?
Thanks.
One thing to conside is how much config data there is, and perhaps how often it is likely to change. If the amount of data is small, then saving this in a database (if your not already using a db for anything else), would be overkill, equally maintaining a db for something that gets changed once every 6 months would probably be a waste of resources.
I think this depends on your projects. If you want someone else to configure the application through the UI you can put the configurations into the database.
If its just you and some developers, and changes are not made frequently, put them in a file.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
One of the first things I noticed while installing Wordpress MS and creating my network was that 9 db tables are created for each new site. Obviously this means that if I had, for example, 10,000 users, I would end up with 90,000+ database tables. Since this could obviously be avoided (I think) by instead modifying the existing Wordpress database schema, why was the system designed this way? For compatability, ease of use, etc.? Because they don't expect to be able to support that many sites? I am trying to figure out if I should proceed with the system as-is or start hacking to make the db schema scale well. Should I be worried about potentially ending up with so many tables?
Yes, the code can support thousands of sites, and many users per site. Hardware will be the limiting factor.
To answer your other question of why was it done this way? It keeps the WordPress code base from having to be altered a LOT from when it was created. It is one of the important reasons that plugin authors and theme authors use $wpdb->prefix instead of assuming wp_ for table names.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the mysql database best practices for multiple users?
When build a SAAS cloud projects are you best to have a new database for all users or put a users data in their own table or just put it all in the same database and use primary key to find a users data?
What are the pro's and con's?
I NEVER create per-used tables. If the logical meaning of the data is the same, then they should share a table. I also never allow automatic creation of tables - creation of tables is done by a DBA, by hand (sometimes by running a program or a script, but always initiated by a human being.
I also have a hard-and-fast rule to have static SQL (using bound parameters for values only). This lets me keep tight control of what is read from/written to the database, and where - very important to avoid SQL injection.