I/O Performance

[johnj]

Some background, our company currently has a cluster which focuses on HA and I/O performance. We offer a service which is heavy with both disk and network I/O. Traditionally, virtualization and aggregate resource computing solutions have suffered performance loss at disk I/O and typically at network I/O.

My question is, how does AppLogic deal with performance at network/disk I/O? Do you guys make heavy use of TOE? ASIC? If there is little to no performance loss, how is the performance of writes over network mitigated?

Are writes queued in RAM or do you make use of AIO? If queued, do you provide a separate pool of resources which are more sensitive to disk syncs (perhaps via BBU's?)? My main concern is with AppLogic handling transactional databases, such as PostgreSQL/Oracle which rely heavily on syncs (blocking) to maintain data integrity.

On resource allocation, what QoS does AppLogic provide as far as guaranteed specifications? From your demo and presentation it seems like I can allocate X resources to a service, however, how do I know that if I allocate 6 CPU's that they will be each be at least 2ghz? Do you support 64-bit environments?

Sorry for all the questions, feel free to grab me off-line to discuss :)

Thanks in advance,
John

[PeterNic]

John,

I'll try to address some of the questions here:

1. The best way to evaluate the storage performance for your particular usage is to get a grid -- even if for a month -- and run your app (or benchmarks you consider representative). We will be publishing some standard benchmark results shortly but nothing can replace trying with your own app. Most customers put their app on AppLogic within a couple of days, so if you think it's worth it for you, I would recommend it.

(And to address the question before it is raised: yes, you can run most of your app's services on the grid and still use an external physical server for your database. Many customers have asked whether they can do it, no one has actually found they needed to.)

2. We use only standard off-the-shelf server hardware, no ASICs. At this time, we rely only on the standard Intel/Broadcom-type NIC TCP acceleration, getting pretty decent results. It is also easy to add more oomph by adding more standard CPUs as well as to separate tasks to different appliances (e.g., our SSL decoder runs on a separate appliance from the load balancer and/or web servers, getting dedicated full CPUs or more, if your traffic requires it)

3. In transactional databases, it is more important to keep the write ordering correctly than to have all writes fully committed on each write. We do not reorder writes. Of course, at transaction commit, it makes sense to ensure full writeback, to make sure that at least the data has been written to the log. We don't use BBU, but keep in mind that all volumes are mirrored across servers, so even if one server dies, at least one more server has the data in memory and is writing it to the disk.

4. Allocating resources:

CPU - you specify the amount of CPU for each appliance (from 1% of a CPU to 4 full CPUs). The appliance is guaranteed to have at least that much CPU at any time it needs it; it may get up to the next whole CPU if no other appliances use it at the moment
memory - you specify the amount for each appliance. The memory is preallocated and dedicated to the appliance (physical memory)

You can see what servers and CPU speeds you have by executing 'srv list' and 'srv info' commands. AFAIK, all current offerings from our hosting partners are with 2.4GHz+ CPUs.

5. We currently are testing 64-bit support in the lab. If you'd like to participate in alpha/beta tests on this, please PM me.

Best regards,
-- Peter

[johnj]

Great, thank you for taking the time time to answer my questions and the information! I'll PM you regarding the 64-bit testing.