Announcement

Collapse
No announcement yet.

PHP/SQL vs. HTML - speed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PHP/SQL vs. HTML - speed

    Ok, I'm planning helping move a customer site which is a picture-based site, to vBulletin. Right now it's straight HTML, and CPU usage for apache rarely tops 1% (http tasks sometimes spike to 10% (only for about 1sec) but all http tasks on the server are usually below 1% CPU usage).

    There's a rather large amount of pictures - which will become attachments - and I'm wondering if making them available as PHP->MySQL queries is significantly more CPU hungry than the current HTML requests.

    There's just over 240,000 pictures to be moved, but we're using a batch system to do it and it's migrating very smoothly. Right now the site flies with absolutely zero lag, being HTML based. I'm just scared that making everything dbase-driven will bog everything down. Is there going to be a LOT more CPU time required to handle the site through vB, than it currently is through html ?
    Last edited by z0diac; Sat 20 Jun '09, 9:49am.

  • #2
    The benefit of using PHP is that your site can be made a bit more dynamic, flexible. You can cache data, you can optimize results, you can leave out parts of code that doesn't need to be loaded. And you re-load the same content such as the header/footer, etc.

    I would put 20,000+ images in the file system, rather than the database. But use MySQL to store the other data, and I would use PHP to query and manage it all.

    Any 'templates' can be static html that can be called when needed.

    If someone has just a few pages, and no need to handle users, a few static html pages will do just fine. You can have 5 or 50,000 users on it. And the server will be the bottleneck.

    If someone has 50+ pages, I do recommend to at least use PHP to include_once "header.html" to avoid having to load it 50+ times, etc. And it makes managing the pages for updates a lot easier.

    Using PHP you can also lower the server load if you get 50,000 visitors loading 1 image. A popular image could be cached, lowering the stress on the web server, php and mysql. Instead of querying it each time, it can just use cache.

    The choice to use a framework, or an engine like vBulletin, or wordpress, or some gallery script, etc .. is simply up to what sort of traffic you are expecting, wish to deal with, and how much time you want to spend on managing things or editing pages, etc.

    Comment


    • #3
      Yeah as Floris said, do not put all these images into the database, serve them from the filesystem.

      Besides that it's hard to say if PHP and MySQL will do the job on your current hardware without knowing anything about your traffic, amount of concurrent users and the hardware you are using.

      But in general PHP and MySQL can be very fast and powerful. And personally I definitely do not want to create a website without a template driven backend ever again
      Planning to continue using VB 3.8 post EOL? Then join the VB 3.8 Forever group and vB3Forever.org!

      Comment


      • #4
        Originally posted by Floris View Post
        I would put 20,000+ images in the file system, rather than the database. But use MySQL to store the other data, and I would use PHP to query and manage it all.
        Sorry - yes that's what I meant by database. The files are actually in the file system, but what I meant is that all the locations of them, access privs, and whatnot are called from the vB database.

        Any 'templates' can be static html that can be called when needed.

        Using PHP you can also lower the server load if you get 50,000 visitors loading 1 image. A popular image could be cached, lowering the stress on the web server, php and mysql. Instead of querying it each time, it can just use cache.
        Great! The tech guy who handles all the php/sql part of it can hopefully work it out like that (I'll forward him this msg actually)

        The choice to use a framework, or an engine like vBulletin, or wordpress, or some gallery script, etc .. is simply up to what sort of traffic you are expecting, wish to deal with, and how much time you want to spend on managing things or editing pages, etc.
        Well the main reason to move to vB from static HTML pages is to make things easier editing, moving threads around, etc. Rightnow, each time pictures are added, he has to manually edit the <Back and Next> pages with a new .html link, he has to create and save a new page each time in his html editor, and making a change to the design of things means changing EVERY html page. By using PHP he can simply make a new post and SOO much work is instantly done for him as far as page navigation.

        I'm just not sure if one or more queries is made each time a picture thumbnail is shown in a vB post - many thread pages will have 200-300 images on each page. With maybe 100 or more users online at a time, I'm not sure how intensive it would be on the CPU. With html, it seems there's hardly any CPU usage for each html task running.

        Comment


        • #5
          Originally posted by mlx View Post
          Yeah as Floris said, do not put all these images into the database, serve them from the filesystem.

          Besides that it's hard to say if PHP and MySQL will do the job on your current hardware without knowing anything about your traffic, amount of concurrent users and the hardware you are using.

          But in general PHP and MySQL can be very fast and powerful. And personally I definitely do not want to create a website without a template driven backend ever again
          Yes, having 2000+ static html pages is just becoming to hard to work with. You're absolutely stuck with what you have as it's just not feasible to make small changes that require editing a whole group of pages each time.

          Current traffic isn't very much. Maybe 30-50 users online at a time. But each user can be viewing pages that display a HUNDRED thumbnails.

          The server is: GenuineIntel, Intel(R) Xeon(TM) CPU 3.20GHz
          with 2GB ram, on Linux 2.6.18-92.1.10.el5

          Comment

          Related Topics

          Collapse

          Working...
          X