Sure, but how many servers them are using? A simply architectural change from Apache/Squid to nginx would let them to serve a lot more requests
I'd prefer to look to what them use instead the number of request them can manage: an high number of request means only that the architecture scale well nothing more. To see if the architectures works well and can use well resources supplied by the hardware you need to see what they use: - Nginx is known to be alot faster that Apache and/or Squid (as reverse proxy) - Smarty is know to be slow and resource expensive (a lot) when he "compile" pages Consider too that there are a lot of languages used: - java - perl - php However consider that the main problem isin't when you need to serve static content, this is simple! The problem is when you need to serve fastly dynamic content and, using php, there isin't a really good way because it is slow. But, just a question: why so aggressive? It's just a fact that php is slow and if you need speed isin't the best choise ... i've said this, nothing else Take a look here http://shootout.alioth.debian.org/gp4/benchmark.php?test=all I'm not saying that noone should use php, i use it every day for small/medium/big applications because, normally, webapplactions doesn't need to be fast but when one of these must serve configurations files to an application that must manage a lot of requests the story isin't the same anymore. EdPimentl ha scritto: > Understand....and do know that when services/sites are not engineered > correctly this will happen. > Here is how Flickr have architected their service. > > > Platform > ># > > > # PHP > # MySQL <http://highscalability.com/tags/mysql> > # Shards > # Memcached <http://highscalability.com/tags/memcached> for a caching layer. > # Squid <http://highscalability.com/tags/squid> in reverse-proxy for > html and images. > # Linux <http://highscalability.com/tags/linux> (RedHat) > # Smarty for templating > # Perl <http://highscalability.com/tags/perl> > # PEAR for XML and Email parsing > # ImageMagick, for image processing > # Java <http://highscalability.com/tags/java>, for the node service > # Apache <http://highscalability.com/tags/apache> > # SystemImager <http://highscalability.com/glossary/term/76> for > deployment <http://highscalability.com/tags/deployment> > # Ganglia <http://highscalability.com/glossary/term/77> for distributed > system monitoring > # Subcon <http://highscalability.com/glossary/term/78> stores essential > system configuration files in a subversion repository for easy > deployment to machines in a cluster. > # Cvsup for distributing and updating collections of files across a > network. > > > The Stats > > # More than 4 billion queries per day. > # ~35M photos in squid cache (total) > # ~2M photos in squid's RAM > # ~470M photos, 4 or 5 sizes of each > # 38k req/sec to memcached (12M objects) > # 2 PB raw storage (consumed about ~1.5TB on Sunday > # Over 400,000 photos being added every day > -E > > > > On Tue, Jun 3, 2008 at 2:19 PM, Albano Daniele Salvatore - Personale > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > A couple of suggestions: > - take a look to nginx, it's really fast and for a fast switch > there is > need for a fast data backend (it serves data) > - dosen't use php (i love php, but it is slow ... a lot slow even > using > apc, eaccelerator or similar!) > > Memcached (or similar like sharedance) would be really useful to serve > pre generated XML. > > It would be really nice if the WUI (Web UI) would be written using > Mono > or Python > > these are just my two cents :) > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > <mailto:[email protected]> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
