what type web site use lots of resources of server?

If server resource is defined as processor/RAM

1) Sites with inefficient code.

We had a site on our server that was not only written in resource-intensive way-every page on the site was autogenerated on the fly by a perl script. And each user would spawn a new instance of that script-there were often hundreds of users on the site at once.

2) Sites with bad code

Unfortunately, the script would runaway on occasion, and start spawning exponential incidences of itself, driving the server load through the roof and our admin would have to go in and clean up the mess and disable the script, because if allowed to run free, it would use up all the server resources and take the whole machine out.

Eventually, they were given the option of having us fix the script or finding a new host. Script fixed, no problems.

If server resource is defined as hard drive

3) Sites with a multitude of large files, particularly music and video files. They will also hog up bandwidth when people download them.

ic.
Thanks.

Some forums also take their part of the cpu... Do a search, and you'll find out which ones to choose.

Am I right when saying that php uses less cpu power than perl?

Perl generally does take up more resources than php. Some hosts have banned cgi scripts like ubb and old versions of ikonboard. Plus cgi scripts are usually slow anyway.

Sites that offer a lot of files like warez, mp3s (which are also illegal anyway) for download also take up resources.

PHP rox :)

(although every programming language has its strengths and weaknesses)

Originally posted by lets.pretend
Am I right when saying that php uses less cpu power than perl? [/B]Strictly speaking? No.

It isn't the language or the language processor per se that makes the difference in load. The difference is that most, not all by any stretch, but most hosting providers are running PHP as mod_php - basically the PHP interpreter is running all the time within Apache itself.

This means that each page hit does not force the loading of 2MB + of php interpreter. Multiply that times 100 sites times x hits per second and you can see the savings in CPU and possibly disk depending on the load on the server.

Some providers run mod_perl or similar solutions, but not as many.

In fact, from a straight language performance standpoint, many are far better than PHP, including Perl and Python depending on use. For a detailed comparison, have a look at http://www.bagley.org/~doug/shootout/

There are many solutions that allow Perl or Python (my favorite) or others to run code in persistent fashion. On a moderately configured server its easy to churn out 400-500 request per second, which you could not do with CGI.

hm... wonder why it doesn't show the little "edited" by italics.

ack... need to have dinner. Was going to post some test results running "ab" on a fairly decent server with html and then python in both persistent and cgi mode to show the significant differences. No time right now.

ab on my dual cpu machine churns out 730 requests per second for the Apache 'welcome' index.html page. later I'll show the python versions.

Hmmm... Time for me to learn something :)
What's the difference between persistent and cgi mode?

If anyone has some spare time on their hands, I'd like to know exactly what those two modes are...

<whispering>We're getting off-topic here</whispering> :)

Well... not really off topic. The question was what type of software puts a load on the machine, and a common answer was given lumping Perl in with CGI. The two are not the same.

I'm not a Perl hacker so will demonstrate the concept of a persistent / long running application process done in Python instead. I was curious about this benchmark for my own purposes, so here's the result of my late night adventure.

Machine - dual 1.26 GHz Tualatin CPUs, Seagate Cheetah 15K RPM SCSI drives, 2GB RAM. I restarted httpd inbetween each test.

Baseline - access a straight forward index.html file 1296 bytes in size. Make 2000 requests, 8 concurrent

ab -n 2000 -c 8

Running the test against straight html is very quick as you'd expect. It runs so fast that its difficult to gauge the effect on the machine except that its clear there is lots more capacity sitting in reserve. Load might be around .40 - .50 / 60-75% idle.

Document Path: /index.html
Document Length: 1296 bytes

Concurrency Level: 8
Time taken for tests: 0.695 seconds
Complete requests: 2000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 3119116 bytes
HTML transferred: 2594592 bytes
Requests per second: 2877.70 [#/sec] (mean)
Time per request: 2.78 [ms] (mean)
Time per request: 0.35 [ms] (mean, across all concurrent requests)
Transfer rate: 4487.94 [Kbytes/sec] received



Here's Python returning an HTML document of the same size, run as a CGI application. The load average on the box peaked at over 8.50 and the CPU's were 0% idle (mostly user):

Document Path: /cgi-bin/demo.cgi/
Document Length: 1296 bytes

Concurrency Level: 8
Time taken for tests: 163.855 seconds
Complete requests: 2000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2988000 bytes
HTML transferred: 2592000 bytes
Requests per second: 12.21 [#/sec] (mean)
Time per request: 655.42 [ms] (mean)
Time per request: 81.93 [ms] (mean, across all concurrent requests)
Transfer rate: 18.24 [Kbytes/sec] received


CGI Sucks, really. Down from 2800 requests per second served to a mere 12 per second. Yuk! And its no surprise - 5136K of Python code is loaded over and over again. Tons of processes being forked.

Its easy to understand why a busy forum or content management system or portal running as a CGI app will run like a pig, but also hog the resources of the machine from other users as well.

Now Python running the same demo.cgi application but as a long running process in a manner similar but not identical to mod_perl or mod_php (I am intentionally simplifying the comparison for clarity here). Load about .30 - .50, CPU idle 35%, very approximately.:

Document Path: /cms/
Document Length: 1296 bytes

Concurrency Level: 8
Time taken for tests: 2.394 seconds
Complete requests: 2000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2988000 bytes
HTML transferred: 2592000 bytes
Requests per second: 835.42 [#/sec] (mean)
Time per request: 9.58 [ms] (mean)
Time per request: 1.20 [ms] (mean, across all concurrent requests)
Transfer rate: 1248.12 [Kbytes/sec] received


Ok, this is far less than straight HTML but very good for a fairly complex application server. 835 requests per second - I can live with that, especially since there is ample headroom left on the box.

And the only difference between this and the CGI example is how the application was built, not what language it was written in.

I thought it would be worth sharing this because its often asked on WHT 'what's the best application' / lowest load / etc, but little discussion is around "how is the application written" - which as you can see, makes a huge, huge, difference.

Thread back on track now.

thx

why didn't someone mention adult site hosting... they take hell of the resources (bandwidth/cpu/disk IO) :)

Also, sites that host CGI for other sites, e.g. counter/banner services (and others) that distribute medium bandwidth, but each request has to be passed thru CGI/PHP script (that usually uses MySQL db backend).

Sites with high requirements for MySQL/Postgres/MSQL/MS SQL database resources usually use a lot of CPU/RAM as well.

How about large mailling list servers that distribute a lot of e-mail messages (high IO) daily to thousands of visitors...

I think the answer are fornum and chat.however, a lot of people give me more info. thanks.:stickout

I agree with that - large mailing definitely is a hit to a machine. Choosing the right MTA will help.

And poorly designed software of any sort but especially database oriented. I did a code review on a site that was killing a machine - they were mailing out to thousands of recipients from a database - turns out their query was going against a column that wasn't indexed, causing full table scans and grinding the machine almost to a halt.

Sadly these sorts of problems are very common; there are a lot of 'script users' that have little understanding of what is happening within the software they run.

Originally posted by Alexandra
Perl generally does take up more resources than php. Some hosts have banned cgi scripts like ubb and old versions of ikonboard. Plus cgi scripts are usually slow anyway.

Sites that offer a lot of files like warez, mp3s (which are also illegal anyway) for download also take up resources.

UBB is a not to bad, I have it running on windows fo a clients.

but what is a real hog is any site that does FTP, FTP has consistant read access to the drive, then you got the I/O demands if your running IDE ( scsi saves this part of hassel ), but the real problem is when you have read via the ftp request then then another read from another application ( like the databases ),

Mike

Ikonboard is very bad at hogging resources. UBB isn't to bad, as Mike said above, however there are better alternatives to it.

What about server side includes? They also take up more server resources than plain html pages, yes?