I am releasing a site next week that has (in the past) gotten up to 1200 simultaneous users. My worry is that the performance of the site will not be good enough to handle that kind of traffic. I used YSlow, but there are probably better testing plugins somewhere. Here is the case:
Server:
4x 3.0GHz Cores
4GB RAM
Dedicated/Co-Located
Linux (Cent OS)
Apache
MySQL
PHP 5
Drupal 5
YSlow Analysis Score: 72 (C)
A 1. Make fewer HTTP requests
F 2. Use a CDN
A 3. Add an Expires header
F 4. Gzip components
A 5. Put CSS at the top
C 6. Put JS at the bottom
A 7. Avoid CSS expressions
n/a 8. Make JS and CSS external
A 9. Reduce DNS lookups
D 10. Minify JS
A 11. Avoid redirects
A 12. Remove duplicate scripts
F 13. Configure ETags
Any reccommendations would be great! If you need me to test anything else, just post it and I will get you the info. The site is live on beta, but I am trying to restrict access otherwise I would just give you the URL. Thanks in advance!
Comments
Yslow is not the entire picture
Yslow is not the entire picture. It give good advice on the user experience part, but does not tell you how the backend is doing (PHP, MySQL, ...etc.)
Are these 1200 users all logged in at the same time, or are they anonymous users (not logged in)?
Are you enabling any caching (regular page cache, memcache, ...etc.)?
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Great post
I think that we would like to be able to accomodate 1200 users logged in. The 1200 stat included anonymous users as well. I have drupal set to the normal caching and outside of that everything is pretty standard "out of the box" as far as caching goes. I am getting some long loading times on pages with images, but I will be paginating those to help with that. Text pages are loadin in half a second or so with very little activity (as it is in beta).
As for yslow analysis:
As for yslow analysis:
4 Ignore. Gzipping html, js and css does increase loading speed but since it's compressed on fly it does increase server load as well. You might just limit compression to aggregated css and js and cached compressed files to compatible browsers.
6 Read this: http://groups.drupal.org/node/8399 also use http://drupal.org/project/javascript_aggregator (just aggregate, do not compress as it f*** up js every time I have used it)
10 http://developer.yahoo.com/yui/compressor/
13 Use ETags only if you have single webserver (http://httpd.apache.org/docs/1.3/mod/core.html#fileetag), if you use multiple webservers ETags will most likely cause higher server load, while not speeding up load times. That is if you use any other ETag calculation method than file size, which is not perfect.
As for server/script side:
1 if you have to use apache use it with php working via fastcgi. If you don't have to go with nginx or lighttpd (I prefer nginx)
2 cache anything everywhere:
3 Since with 1200 users you're bound to have quite a lot of database writes:
As mentioned above YSlow
As mentioned above YSlow generally reports on 'frontend' or client side performance issues. However out of report I would:
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Faster User's page loading and server performance
Given the large load (1200 concurrent) you expect to have, it will be good to do these:
For Faster Page loading
- CDN maybe worth it - particularly misc folder contents to the CDN
- gzip: Enable/activate the mod_deflate on apache - most browsers support compression
- moving js files to bottom in theme file will give faster page loading experience to users
For Server side tuning
- Use non-sql caching (fastpath_fscache) that does not require loading of drupal core for anonymous visitors. Another option is boost module (http://drupal.org/project/fastpath_fscache , http://drupal.org/project/boost)
- Use eaccelerator in the php
- Turn on the aggregate css in D5 admin->performance
- Having 1200 concurrent logged in users, would mean you would need to size for 100+ concurrent php requests. You will need to size and configure php memory (or in settings.php) for each request.
- Mysql tuning - each request from logged in user creates atleast 50+ mysql queries. You may want to run mysql on another hardware box altogether - that will be the one taking 80%+ of the cpu load
I think supporting 1200 concurrent users may require addressing these issues on priority - more on the server side than the user page loading side. Your server may not be able scale up if not sized properly.
I hope this helps. Thanks.
- Rajeev
-------------------------------------------------
- Drupaler in Cupertino, SF Bay Area
YSlow is a nice tool, but it
YSlow is a nice tool, but it certainly shouldn't be the only piece in your optimization puzzle. From the looks of it, a CDN will definitely help, but you might want to look into doing some database tuning, php module tuning, and possibly memcache.