On 02/21/2013 04:41 PM, Terry Ellison wrote: > On 21/02/13 23:38, Rasmus Lerdorf wrote: >> On 02/21/2013 03:15 PM, Brendon Colby wrote: >> >>> NFS is so common for sharing files that saying "Wow, people are still >>> serving web files over NFS?" is like saying "Wow, people are still >>> using the ls command to list directory contents on Linux?" I think NFS >>> is still very widely used, even for sharing web files. >> This is simply not true. I do have a fair bit of experience in this >> field, and I don't know of any major sites that do this and I have >> worked with a good chunk of the largest sites out there. > Eh??? Fortune 500 enterprises and governmental departments are pretty > conservative. NAS and SAN based iSCSI and FCoE based elastic block > storage give great performance for server-specific file-systems, but > Brendon is right: for distributed file systems, NFS and CIFS still > dominate.
By major I meant traffic-wise, not Fortune-500, although there are some of those on the list too. I mostly work with medium-to-large scale Internet companies. Think Yahoo, Facebook, Flickr, Digg, Etsy, WePay, Room77. These types of companies would never consider serving all their Web traffic from NFS. Yes, Yahoo had a ton of Netapp filers as well, but this was for shared data storage, they would never consider putting their application logic on them. This is also something that has been like this for 10+ years and nobody has stepped up to fix it so far. It shouldn't be news to anyone that stats and opens over NFS are slow. I am not sure why it should suddenly be an urgent problem for us at this point. But like I said, we may get to it. If the integrated opcode cache happens it becomes easier to manage the flow between the compiler, the cache and the executor and we can probably optimize some things there. And as I mentioned in another thread, let's see some RFCs proposing how to fix some of these things rather than simply posting "I wish the PHP devs would do this.." type of messages. These go over really badly with most of the longtime contributors here and they even tend to have the opposite of the desired effect. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
