ipswitch8259
New Member
- Messages
- 32
- Reaction score
- 0
- Points
- 0
could you give us an idea of how much in mb, if we are already using a high resource usage.. tnx..
High Resource Usage
- Thread starter ipswitch8259
- Start date
- Messages
- 4,565
- Reaction score
- 245
- Points
- 63
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
It's not about storage. "High resource usage" means that either your scripts are using too much RAM, too many CPU cycles, too much file system I/O, or are making too many database queries.
"Too much RAM" can be caused by running algorithms that use a lot of memory space to gain speed (large parse trees, tries, naive quicksort) over large data sets or by scripts that try to cache things in memory for faster retrieval.
"Too many CPU cycles" can be caused by inefficient code, or by algorithms that maintain a small memory footprint at the expense of computational speed (again, over large or large-ish data sets), or by simply trying to solve problems that are too big for what you're allotted on a free hosting account.
"Too much filesystem I/O" is usually caused by scripts that create or modify static HTML files either based on user input or by scraping an external data source (either web page scraping or fetching external files like XML data files, CSV files or spreadsheets).
"Too many database queries" can be the result of poor database design, not understanding the power of JOINs, failure to use stored procedures when appropriate, or simply building an application that updates too often (again, relative to what you're allowed on a free hosting account), like chats, shoutboxes, or Facebook-style AJAX applications that try to be a little too "real-time".
If you are building an application yourself, you can take these things into account, do a little profiling, and come up with some pretty spectacular applications that stay well within the boundaries. (What you are allowed on a free hosting account here is WAY more than you'd find on anything but the most powerful servers twelve years ago, and I was able to build apps that could support 1500 simultaneous users on a LAN back in those days.) If you are using off-the-shelf software, particularly anything claiming to be a CMS (most of them are really nothing more than blogs on steroids), then you are at the mercy of the application's designers/developers, and they probably weren't too worried about your free hosting account when they wrote it. Most of the "performance" plug-ins and extensions just make the problem worse -- they use a lot of CPU to generate the cached elements, and a lot of memory to store them. Steer clear -- you don't need to be that fast (you don't have an audience like Facebook or Digg have).
"Too much RAM" can be caused by running algorithms that use a lot of memory space to gain speed (large parse trees, tries, naive quicksort) over large data sets or by scripts that try to cache things in memory for faster retrieval.
"Too many CPU cycles" can be caused by inefficient code, or by algorithms that maintain a small memory footprint at the expense of computational speed (again, over large or large-ish data sets), or by simply trying to solve problems that are too big for what you're allotted on a free hosting account.
"Too much filesystem I/O" is usually caused by scripts that create or modify static HTML files either based on user input or by scraping an external data source (either web page scraping or fetching external files like XML data files, CSV files or spreadsheets).
"Too many database queries" can be the result of poor database design, not understanding the power of JOINs, failure to use stored procedures when appropriate, or simply building an application that updates too often (again, relative to what you're allowed on a free hosting account), like chats, shoutboxes, or Facebook-style AJAX applications that try to be a little too "real-time".
If you are building an application yourself, you can take these things into account, do a little profiling, and come up with some pretty spectacular applications that stay well within the boundaries. (What you are allowed on a free hosting account here is WAY more than you'd find on anything but the most powerful servers twelve years ago, and I was able to build apps that could support 1500 simultaneous users on a LAN back in those days.) If you are using off-the-shelf software, particularly anything claiming to be a CMS (most of them are really nothing more than blogs on steroids), then you are at the mercy of the application's designers/developers, and they probably weren't too worried about your free hosting account when they wrote it. Most of the "performance" plug-ins and extensions just make the problem worse -- they use a lot of CPU to generate the cached elements, and a lot of memory to store them. Steer clear -- you don't need to be that fast (you don't have an audience like Facebook or Digg have).
ipswitch8259
New Member
- Messages
- 32
- Reaction score
- 0
- Points
- 0
tnx.. of u both.. its a lil bit clearer n0w..
bhupendra2895
New Member
- Messages
- 554
- Reaction score
- 20
- Points
- 0
I think disk inodes used are counted in terms of resource usage.Although I don't know what exactly it means but I had used another webhost and their ftp server was setup to prevent users to write more than 6000 files on the disk.I used a component/plugin to back up joomla there which caused this.
Even if you have a lot of files inside a folder then it requires more resources to handle them.
It is hard to assume for me that how data centers handle lot of files having total size in terabytes?
Even if you have a lot of files inside a folder then it requires more resources to handle them.
It is hard to assume for me that how data centers handle lot of files having total size in terabytes?