Tag: disk IO

About

What we blithely call a "Disk I/O" is actually made up of several components, each of which may have an impact on overall performance. These layers may be broken down as follows for a typical I/O operation:

  • POSIX: Application calls a POSIX library interface. (These frequently map directly to system calls, except for the asynchronous interfaces. These latter work via pread and pwrite.)

  • System Call: The relevant node and vfs system calls are:
    • close()
    • creat()
    • fsync()
    • ioctl()
    • link()
    • mkdir()
    • open()
    • read()
    • rename()
    • rmdir()
    • seek()
    • unlink()
    • write()
    • vfs system calls:
    • mount()
    • statfs()
    • sync()
    • umount()
  • VOP: The vnode operations interface is the architectural layer between the system calls and the filesystems. DTrace provides the best way to examine this layer. Starting in version 0.96, the DTrace Toolkit's vopstat command allows direct monitoring at this level.
  • Filesystems: There is some discussion of filesystem tuning and filesystem caching at the bottom of this page. Further information on troubleshooting a particular filesystem is contained in each filesystem's web page. (This site contains pages for NFS, UFS and ZFS filesystems.)
  • Physical Disk I/O: This is the portion of the I/O that involves the transfer of data to or from the physical hardware. Traditionally, I/O troubleshooting focuses on this portion of the I/O process.

From www.princeton.edu/~unix/Solaris/troubleshoot/diskio.html

 

In PHP, sessions can keep track of authenticated in users. They are an essential building block in today's websites with big communities and a lot of user activity. Without sessions, everyone would be an anonymous visitor. In system terms, PHP sessions are little files, stored on the server's disk. But on high traffic sites, the disk I/O involved, and not being able to share sessions between multiple webservers make this default system far from ideal. This is how to enhance PHP session management in terms of performance and shareability.

I used to use Dean Edwards Javascript Packer a lot to compress my Javascript sources. Libraries of 100kB could easily shrink to 30kB and that saves load times & bandwidth. A good writeup by Julien Lecompte made me realize that there were better ways.

Recently I had to migrate all MySQL databases from one server to another. This was a one time only operation, so setting up replication wasn't an option. And restoring a backup on the new server involved more downtime than strictly necessary. I figured the most ideal way would be to dump the active MySQL directly into the new MySQL instance. And that's what I did.

Recently two of my articles reached the Digg frontpage at the same day. My web server isn't state of the art and it had to handle gigantic amounts of traffic. But still it served pages to visitors swiftly thanks to a lot of optimizations. This is how you can prevent heavy traffic from killing your server.

Everyone knows that RAM is so much faster than a hard disk. To illustrate, while a modern SATA disk has peak transfer rates of 375 MB/s, modern RAM can do a mind blowing 12.500 MB/s! Normally only the system itself makes use of this ultra fast storage, but we can also access this space directly. And that opens a great window of opportunity.

Let's say your site is becoming a big success and as a result it's becoming slower and slower. There are several things you do without buying additional hardware.