As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've took a look at the PHP script behind my father website which has been built by a hired programmer. Now, I'm not thinking that I'm better than him, but I think its technique might not be the best.
The website has dynamic page body, in the meaning that my dad can, via a specific admin page, modify the HTML content of most of the webpages in the website. Right now it's made via database: the pages are all stored in the database and every request deals with a query that fetches the page from the database and implement it.
Now, I think this way is very bad mostly because it requires (even if not that expensive if cached) an additional query to the database.
Wouldn't it be more efficient to store the pages as HTML files and then just modify the file itself when required? In this way the editing of the file, I think, is faster, and the loading of the content of an html file per request is a lot easier and faster than perform a query.
Is it? Is there any other (more efficient) way to handling this situation?
this is the question of the century :) there is no exact answer to this question. just performance tips. people are working to optimize page load times during recent 30 years.
No it isnt better to have fixed HTML pages under an hypothetical '/mypages' folder.
What if the user wants about 500 contents in his webpage? he'll end up with 500 files.
Yeah sure, they'll be served faster but is that enough against the massive problems below?
What about page translation? this would be nightmare in static html files.
Pages are rendered that way because they're dynamic; that is, stuff can be "entered" by third parties/plugins (say) and applied into multiple contents at once; what about applying the same stuff into numerous HTMLs and then changing it again?
What about if you want to change the < HEAD>*er and *< SCRIPT>**s loaded? you'll be forced to do that in all 500 contents in every change.
What about the PHP included in those .html files? This is not a reason if you're not putting PHP into this but in case of an included php file renamed/removed you'll need to change all files in a massive update.
Think of templates; the reason the modern CMS (or admin pages) are dynamic today is because they can change classes/styles etc. without affecting content itself. A single change to theme used or a single class would cause (again) a massive update.
Database is files too, but run faster. If you worry about performance you can program the database to use caching (queries like SELECT data FROM content WHERE id=1) so the query is almost no-query in performance terms.
I can think of more.
There are several good reasons why a CMS should use a Database to store/fetch the dynamic content. Just as there are several reasons why you might prefer not to rely on a DB.
Pro Db:
Security: It's an obvious, and slightly ambivalent argument, but nonetheless. If you decide to store your content as separate files on your server, they'll need to be stored in a directory that doesn't allow public access. If not, users might be able to access the chunks of your site separatly, which comes across as unprofessional. People with ignoble intentions will have an easy time altering your site's content, too. Of course, there are many ways to prevent this, and increase overall security. Database systems, when left to their own devices, aren't exactly safe either, but provide an extra obstacle to hackers with minimal effort.note: The security argument stands, or falls with how well your script filters out injection, and how secure you set up your server.
Disk usage. When using separate files to compose each requested page, The server has to access its HD on each request. Again, caching solves this issue to some extend, but it's easier and (in general) better to cache DB query results (performance wise). Either on your Database server, in PHP, or, better still, both.
Logging. By this I mean: when you alter the content, a database driven CMS is a lot easier to manage. If you altered the content, and want to undo/rollback the changes, a DB is the easiest way to implement such a feature. Using HTML, you'll soon find yourself wading through tons of files called site_menu_block_YYYY-mm-dd.html.backup. Even if this is done by a script, it'll almost certainly be slower than using a DB.
Translation: as vlzvl pointed out, if you're using static pages, you'll either end up with each page N times, once for each language. When altering the stylesheets, you'll then have to alter N files, too. Which is resource expensive. Alternatively, your scripts will parse an HTML template file for each request, and an XML file with the actual contents. This way you loose the SEO benefit of the HTML files, and cause extra server load and slow down your site.
Pro HTML:
I can only give 1 solid pro argument here: it's a lot easier to get an SEO site this way. Just allow search engines to index the separate files. This does decrease the overall security of your CMS drastically .
That said, I think I'm right in saying that all major CMS's use both methods, depending on what type of data they're dealing with. HTML headers, for example, are often partially stored as separate files, just like JS files and style-sheets.
This all depends on the content. When you have much different content, like news it's easier to store the data inside a database for each newsentry and load the data into a template. But when you have single content (like a huge article or info page) you can use a HTML to store the data.
It also depends on if you want a multi-language page or not. You can surly create a multi-linugal page with only HTMLs. But here's the same as above. What content do you have. Much different entries or less same content?
But, what I have done so far was I did both at the same time: When a client wanted a page with news script and multi-language and so on I created the page that the user can log in for news entries and store the news in different languages, but changes to other sites are made via HTML and there was for every language a different html file.
EDIT:
It depends on the user, too. If the user don't know how to use HTML but wants to change the site hisself than the only available option is the option to give him an admin center to make changes. OR if you don't want give to much power to the user :D
My opinion: Most CMS handle lots of DB accesses and load many files in order to compile one page that is eventually sent to a visitor. Still, for most sites there's no performance problem (i.e. most pages loading in < 1s). So I'd be surprised if you have a problem there, with just one single DB access.
But for handling, why use a database, when your site doesn't really need it?
I made a couple of sites for clients where I use one index.php that loads one menu file and one footer file that are the same for all pages, and inbetween it loads the individual selected html files. So in order to edit a page, you use any editor to open and edit the corresponding html. Very simple.
Related
I need to design a website which has friendly URLs configurable by some specific users. They must be in a database to manage them (which user created it, which module and data must load, etc.), and they must have some permissions system (view, actions, etc.).
The question is: It would have better performance if I created a php file for each path (like /section/subsection/index.php) to be loaded directly by Apache, it would be better if I check every query in the database, or it depends of the kind of page?
There would be 3 kind of pages:
- Mostly static (once created won't need to connect with database)
- Periodically updated (I can delete that pages when they are not updated)
- Mostly dynamic (like load user events, which would require to perform database queries)
Is there any existing brenchmark about this?
Simple answer: Do what is easier to code. The performance difference is too small to matter.
I find it easier for static pages to be files. And constructed pages built by PHP. Sometimes I have 1 php file building 1 page. Sometimes I have 1 php file building many pages, usually minor variants on one page. But then, I have to pass arguments to say which variant I am building.
Without a more substantial description of your setup, the number of entries in each section/subsection, the kind of load, etc., noone can answer this question for you.
And really, except for some pathological use cases, noone should. You should answer your question with benchmark data from your implementation.
The only clear drawback I can see in the solution you describe with PHP files is code duplication, but that would be easily managed if you have some automated creation of the files.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Imagine we have a page with a form where users can create their own discussion forum by inserting some data. Inside each forum anyone will be able to post different threads and topics.
Scenario 1:
Use PHP to create a new HTML file every time a user creates his own forum. This would lead to hundreds maybe thousands of different html files.
Scenario 2:
We only have one html file in which contents change depending on the ID received (so it will display the contents for "discussion1", "discussion2" or any other discussion depending on the variable ID). This would mean having just one HTML file but a huge table in our SQL server.
I have seen examples of both scenarios for very large websites. For example, Wikipedia uses Scenario 1 while I believe other more dynamic websites use Scenario 2. What are the main pros & cons of each scenario?
I would love to know the pros & cons that matter most and also the ones related with:
- SEO
- Server response time & server load
- Site maintenance
- User experience (for bookmarks assume the ID is sent via the GET method)
Scenario 2 is certainly the way to go, keeping pages dynamic allows for editing far less files and means everything will always be the same.
With good MySQL tables and relationships the queries to the database shouldn't be that server heavy and your site will still perform a lot better than with hundreds of .html files.
I don't think many, if any sites use scenario 1, they will just .htaccess to alter the url and make them look like .html pages.
I actually believe Wikipedia uses a database as well. They are just parsing the URL to get the variables instead of using a query string in the URL. And I would have to believe the database would be the way to go. It's still going to be smaller because you'll have a lot less code. If you use HTML, you will be reproducing a lot of code that you just don't need to reproduce.
SEO-wise, as long as you do something like Wikipedia does and parse your URL with maybe an .htaccess file, google will be none-the-wiser. It just doesn't really matter if your content is hard coded or not as long as you set it up right.
The best case scenario would be a combination of the two, in this manner:
Use one template (scenario 2) to generate these pages on the fly, this way you can have millions of forums, with only one html.
With this, you should add a caching feature, which caches (creates a temporary html file) all the forums, so that users will not need to access the database every single page visit, but rather get the cached HTML from the server.
Currently i am wondering whether or not to use a MySQL DB to provide content on my website.
An example of what i mean is based loosely here: http://www.asual.com/jquery/address/samples/
find the sample called SEO. Alternatively Click Here
Anyone with HTML5 able browsers will notice the URL is 'pretty' and is what you'd expect to find on any standard website.
Anyone with IE8 or a browser which isnt 'Webkit' enabled, will see the use of the Hashbang (#!) in order for SEO.
The problem is this: the content is pulled from a MySQL DB.. I have approx 30 pages (some are PACKED with content) And im wondering if all this tedious modification of my website is necessary?
I use jQuery MySQL and PHP through a single page interface so my content is not indexable at all. What are your views?
Help me!!
PS. would it be easier to provide PHP Includes in my DB content to fetch pages without having to upload all my pages into my DB?
your question is made up of a lot of questions. :)
to mysql or not to mysql: most of the PHP-usng web world is using mysql as a database to store content. i don't see much of a problem there. 30 pages is peanuts.
jquery and php for a single page interface indexable: depends on the search engine. i've read somewhere (too lazy to look things up) that google uses a javascript enabled crawler. not sure if they use it in production already.
PHP includes in DB content: textpattern uses this approach. your worry is a problem of scale.
if your PHP code can serve pages properly, it wouldn't matter where it pulls content from. DB or filesystem wouldn't matter at this point.
just do it.
There is no such question.
Mysql is okay.
Its general purpose solution for storing site data, everyone using it with not a single problem and even Wikipedia is happy with it.
Mysql is irrelevant to any problems of your site.
Your problem is somewhere else but you forgot to state it. Let me suggest you to ask another question, pointing to the real problem you have, not some guess you made of it's reasons.
Well, if you can avoid it, avoir storing pages inside MySQL, unless you want to give the administrator the possibility to edit the pages.
Aside from that, there is no problem in storing pages in a DB, would it be MySQL or others. A lot of CMS do it (Drupal, Joomla, etc.).
You might encounter some performance issues on your DB server if your traffic becomes high, but this is another problem.
In my tests and comparison, mysql connectivity and queries do slow down responses. If your site is simple and you are only doing updates yourself, then using a template engine and storing content in a files is not a bad choice.
If you decide to put it into SQL, then eventually you might need to build a cache. Hopefully nginx and not the php cache, so it shouldn't be a problem too.
The deciding factor is how you are willing to edit the content. I found that myself and my team is much more comfortable with editing html files through notepad++, Vim or Coda. If content is inside a database you get a poorly-performing (compared to desktop app) WYSIWYG editor.
Always use SQL the content is generated by your users. And do use some lightweight CMS.
I am using the one bundled with Agile Toolkit myself and templates look like this:
https://github.com/atk4/atk4-web/tree/master/templates/jui
would it be easier to provide PHP Includes in my DB content
I think you'll find your site far easier to maintain for years IF you keep a very clear separation of duties: data goes in a database, presentation and code go in files.
While there is some contention whether it is a good idea to store templates in a database, my gut feeling says that you should avoid that temptation unless you have a very good reason.
But storing code (your PHP include statements) in the database is almost certainly not the best way forward.
Me and a colleague were discussing the best way to build a website last week. We both have different ideas about how to store content on the website. The way I have always approached this has been to store any sort of text or image link (not image file) on to a database. This way, if I needed to change a letter or a sentance I would just need to go on the database. I wouldn't have to touch the actual web page itself.
My colleague agreed with this to a point. He thinks that there are performance issues related to retrieving content from the database, especially if every character of content is coming from the database. When he builds a website, any content that won't be changed often (if at all) will be hard coded on to the page, and any content that would be changed or added regulary would come from the database.
I can't see the benefit of doing it like this, just from the perspective of everytime we make a change to an ASPX page we need to re-compile the site to upload it. So if a page has a misspelt "The" (so it'd be like "Teh") on one page, we have to change it on the page and then recompile the site (the whole site) and then upload it.
Likewise with my colleague, he thinks that if everything was to come from the database there would be performance issues with the site and the database, and that the overall loading speed of the web page to the browser would decrease.
What we were both left wondering was that if a website drew everything from the database (not HTML code as such, more like content for the headers, footers, links etc) would it slow down the website? And as well as this, if there is a performance issue, what would be better? A 100% database driven website with it's performance issues, or a website that contains hard coded content which would mean 10/20 minutes spent compiling and uploading a website just for the sake of a one word or letter change?
I'm interested to see if anyone else has heard of it, or if they have their own thoughts on this subject?
Cheers
Naturally it's a bit slower to retrieve information from a database rather than directly from the file system. But do you really care? If you design your application correctly then
a) you can implement caching so that the database is not hit for every page
b) the performance difference will be tiny anyway, particularly compared to the time to transmit the page from the server to the client
A 100% database approach opens up the potential for more flexibility and features in your application.
This is a classic case of putting caching / performance considerations before features / usability. Bottlenecks rarely occur where or when you expect them to - so focus on developing a powerful application and then implement caching later - when it's needed and where it's needed.
I'm not suggesting storing templates as static files is a bad idea - just that performance shouldn't be your primary driver in making these assessments. Static templates may be more secure or easier to edit using your development tools for example.
Hardcode the strings in the code (unless you plan to support multiple languages).
It is not worth the
extra code required for maintaining the strings
the added complexity
and possibly performance penalty
Would you extract the string "Cancel" from a button?
If so, would you be using the same string on multiple cancel buttons? Or one for each?
IF you decided to rename one button to "Cancel registration", how do you identify which "Cancel" to update in the database? You would be forced to set up a working process around how to deal with this, and in my opinion it's just not worth it.
For the following pretty straightforward task: query a list of products from a DB and present it on a webpage,
consider 2 setups:
Setup1: PHP script queries. All content is built on the server and the entire page is served back to the client.
Setup2: Static HTML "page skeleton" requesting content using AJAX. Received content is parsed on the client side using Javascript and rendered using innerHTML or similar.
Of course the second setup only makes sense when you have pages, categories and tags for the client user to choose from.
I need to compare these two, at least by means of:
time it will take content to be served
user experience (setup1 is delivered as a whole, setup2 is delivered in "two parts")
scalability - how do the setups compare when I have 100,000 queries daily
Any thoughts on the issue will be much appreciated.
You may find the following question helpful: Smarty Vs. Javascript/AJAX
I brought up a few points in my answer to that question:
You should use server-side scripts to show any data that is known at the moment the page is loaded. In this case, you know the list of products should be displayed. The fact that a question's answers should be shown is known at page load.
You should only use AJAX calls to load dynamic data that is not known at the moment the page is loaded. For example, when you click the "comments" link under a question or answer on Stack Overflow. The fact that you want to view a particular question's comments is not known at page load.
Javascript should not be required to access core functionality of your site.
You should gracefully degrade functionality when Javascript is disabled. For example, Stack Overflow works just fine with Javascript disabled. You don't have access to real-time Markdown previews or dynamic badge notices, but the core functionality is still intact.
A single HTTP request to a server-generated page will load significantly faster than a request to load a page that makes five or six additional AJAX calls, especially on high latency connections (like cellular networks). See Yahoo's Best Practices for Speeding Up Your Website.
You should think of Javascript as a bonus feature that might not be enabled, not as something that should be used to construct critical pieces of your website. There are exceptions to this rule. If you want to do some sort of pagination in which you click a "next page" button and only the product list changes, AJAX might be the right choice. You should, however, make sure users without Javascript are not excluded from viewing the entire list.
There's nothing more frustrating than when a page can't be accessed because the web developer didn't obey the KISS principle. As an example, take Friendly's Restaurants. I wanted to check out their menu while I was at the mall, so I loaded their website on my iPhone, only to find out that you literally can't get any meaningful information about the restaurant without Flash. It's nice to have fancy menus with swooshing desserts flying everywhere, but in the end, I just wanted to see the items on their menu. I couldn't do that because they required Flash. Graceful degradation in service would have been helpful in that case.
Some things on the web can't be done effectively without Javascript. Displaying a list of products is not one of them. If you are still unsure, look at how other popular websites do things. I think you'll find most of the successful, well-engineered websites follow the guidelines listed above.
AJAX is probably better choice when only a small part of the page changes.
I would recommend starting with the server side version and then building AJAX on top of that. This way you will get also a version of your site that works without javascript, which you probably need anyway if you care about being indexed in search engines.
But first concentrate on creating a page that just works - you can always optimize it later.
Performance on the client has many factors. What is running at the time, what browser, what the content is, what the CSS of the page is, how full is the browser's cache, what plug-ins are installed, what is happening on the network, etc. Just remember that when you are playing with the numbers.
Unless the implementation sucks, AJAX should win hands down. Among the benefits are:
parallelism due to parallel requests on the client side (i.e. you can use multiple server CPU cores to serve parts of one served web page, that can't be done easily using PHP)
refreshing only small parts of the page is faster (less data to transfer, generate ...)
it scales much better since the server has less work to do (esp. if you can offload some of the processing needed for generating html to the client instead of just delivering it)
Dynamic pages like http://www.startpagina.nl/ have been doing this successfully since way before the recent AJAX fad (1 static file delivered, all customization done on the client side - last time I checked anyway).
Of course you can screw things up with either method so that it becomes slower than the other.