Performance - Navneet Kumar on Diigo

26 Nov 09

adding LIMIT 1 to your query can increase performance. This way the database
engine will stop scanning for records after it finds just 1, instead of going
thru the whole table or index
The more data is read from the tables, the slower the query will become. It
increases the time it takes for the disk operations. Also when the database
server is separate from the web server, you will have longer network delays due
to the data having to be transferred between the servers
10 more annotations...
- ENUM type columns
  are very fast and compact. Internally they are stored like TINYINT, yet they can
  contain and display string values. This makes them a perfect candidate for
  certain fields
- Unless you have a very specific reason to use a NULL value, you should always
  set your columns as NOT NULL.
- NULL columns require additional space and they can add complexity to your
  comparison statements. Just avoid them when you can.
- "NULL columns require additional space in the row to record whether their values
  are NULL. For MyISAM tables, each NULL column takes one bit extra, rounded up to
  the nearest byte."
- When every single column in a table is "fixed-length", the table is also
  considered "static" or
  "fixed-length". Examples of column types that are NOT fixed-length are:
  VARCHAR, TEXT, BLOB.
- Fixed-length tables can improve performance because it is faster for MySQL
  engine to seek through the records. When it wants to read a specific row in a
  table, it can quickly calculate the position of it. If the row size is not
  fixed, every time it needs to do a seek, it has to consult the primary key
  index.
- You have a "last_login" field in your table. It updates every time a user logs
  in to the website. But every update on a table causes the query cache for that
  table to be flushed. You can put that field into another table to keep updates
  to your users table to a minimum
- When a big query like that is performed, it can lock your tables and bring your
  web application to a halt.
- Apache runs many parallel processes/threads. Therefore it works most efficiently
  when scripts finish executing as soon as possible, so the servers do not
  experience too many open connections and processes at once that consume
  resources, especially the memory.
- If you end up locking your tables for any extended period of time (like 30
  seconds or more), on a high traffic web site, you will cause a process and query
  pileup, which might take a long time to clear or even crash your web server

17 Nov 09

High Performance Ajax Applications

www.slideshare.net/...-performance-ajax-applications - Preview

JavaScript Ajax Tips Presentation Performance

Less is more
– Don’t do anything unnecessary.
– Don’t do anything until it becomes absolutely necessary.
Work on improving perceived performance
– Users can deal with some reasonable amount of slowness if:
• They are informed appropriately that an operation is pending.
• The user interface remains reactive at all time.
– Cheat whenever you can by first updating the UI and then do the work.
17 more annotations...
- Consider flushing the apache buffer very early on:
  – The download of external CSS files (should be at the top of the page!) may get a head start.
  –
- Load only essential assets / load assets on a delay or on demand
- Reduce the amount of symbolic
  look-up: The prototype chain
- Never pass a string to the setTimeout and setInterval functions. Instead, pass an
  anonymous function
- Memoization
- Store value in function object Lazy function definition
- avoid using try...catch in performance-critical sections
- Document tree modification
  Using innerHTML
- Document tree modification
  Using cloneNode
- Document tree modification
  Using DocumentFragment
  • A DocumentFragment (DOM Level 1 Core) is a lightweight Document object.
  • It supports only a subset of the regular DOM methods and properties.
  • IE’s implementation of the DocumentFragment interface does not comply with the W3C
  specification and returns a regular Document object
- Use event delegation, a technique that relies on event bubbling
- Limiting reflows
- Modifying an invisible element (display:none) does not trigger reflow
  – Modifying an element “off-DOM” does not trigger reflow
- Improving perceived network
  latency using the optimistic pattern
- Favor JSON over XML as your data exchange format
  – Accessing a JSON data structure is easier and cheaper than accessing XML data.
  – JSON has less overhead than XML.
- Consider using local storage to cache data locally, request a diff from the server:
  – Internet Explorer’s userData
  – Flash local storage
  – DOM:Storage (WhatWG persistent storage API, implemented in Firefox 2)
  – Google Gears
  –
- Therefore, to maintain a decent user experience, make sure that JavaScript
  threads never take more than ~ 300 msec (at most) to complete.

Julien Lecomte's Blog » Running CPU Intensive JavaScript Computations in a Web Browser

www.julienlecomte.net/...28 - Preview

JavaScript Performance CPU User-Interface UsereXperience HCI

The biggest deterrent for running CPU intensive computations in a web browser is
the fact that the entire browser user interface is frozen while a JavaScript
thread is running
under no circumstance should a script ever take more than 300 msec (at most) to
complete. Breaking this rule inevitably leads to bad user experience.

13 Nov 09

jQuery Performance Rules - Best Practices for Speeding Up jQuery

www.artzstudio.com/...jquery-performance-rules - Preview

JavaScript jQuery Performance

09 Nov 09

Java String Concatenation and Performance ~ Joey's Scribble's

www.venishjoe.net/...-string-concatenation-and.html - Preview

Java String Performance Optimization

04 Nov 09

Performance comparison: key/value stores for language model counts - Brendan O'Connor's Blog

anyall.org/...ores-for-language-model-counts - Preview

Key-Value-Store Document-Database Performance Database NoSQL

Database Optimize patterns | Haytham El-Fadeel

www.hfadeel.com/Blog - Preview

Performance Database Optimization Model

CAP, BASE model, instead of ACID model
15 more annotations...
- in any in-memory or
  in-disk caching system you will never need all the Database features. You just
  need CAP like system. Today there are a lot of Documents, and key-value based
  store systems
- The Database is often a performance- and scalability limiting factor in most
  types of applications, the reality is that relational databases have not changed
  much in the last 30 years, and for a lot of purposes using a database is akin to
  running an interstellar spaceship while having an old Volkswagen engine in the
  engine room!
- don’t store non-relational data in relational data model
- think twice before use the Database to store BLOB data
- If you choice the right data type this will make the database use lower disks
  space, and the insert/retrieve will run faster
- don’t use NVarChar data type except if you really need 16 bits Unicode (UTF 16).
- Text, NText, BLOB data type because mostly it will store in another location and
  the row will just hold the a reference to data position, so when you retrieve
  the data the DBMS will do a lot of seeks.
- if the access path is mostly through another column, says Company Name, this may
  make a more appropriate clustered index. Another situation is when the table is
  no longer at the top of the chain, but somewhere in the middle and the most
  likely avenue of selection for the data is going to come through the foreign key
  to a parent table
- indexes are stored by pointing to the clustered index (one of the many reasons
  you need a clustered index on the table) changes to the clustered index can
  result in a cascade through all the other indexes on a table.
- using SP (stored procedure) because most of those steps happen statically at
  compile time (i.e. creation time)
- select the columns and rows you need only
- Avid using Like operation because it’s mostly require full table scan
- Avoid NOT IN, instead use a left outer join - even though it’s often easier to
  visualize the NOT IN
- Consider use set nocount on at the top of each SP (and set nocount off) at the
  bottom
- Avid Long-Running, and the distributed transactions

Hot links for Scalability | Haytham El-Fadeel

www.hfadeel.com/Blog - Preview

Performance Scalability Database

03 Nov 09

Java theory and practice: Garbage collection and performance

www.ibm.com/...j-jtp01274.html - Preview

Java Performance Garbage-Collection Developer-Works

Java theory and practice: Urban performance legends, revisited

www.ibm.com/...j-jtp09275.html - Preview

Java Performance Developer-Works

30 Sep 09

SQL Server 2000 I/O Configuration in a SAN/NAS Environment

www.sql-server-performance.com/...2000io_config_sannas_p2.aspx - Preview

SQL-Server RAID IO Performance Configuration SAN NAS

Choosing the correct RAID level and the number of disk drives is the most
important thing that you can do when designing your system
RAID stripe size, RAID controller CPU utilization, controller caches, data file
placement
5 more annotations...
- A SAN (Storage Area Network) is designed to provide access to storage over a
  private fibre channel network
- A NAS (Network Attached Storage) is used to provide storage over a standard
  network.
- Logical disks are carved out of the physical disk drives and allocated to each
  of the computer systems. Only one system can access a particular disk volume
- So in addition to sizing the I/O subsystem disk drives and RAID levels, you must
  look at the traffic on the SAN itself,
- It is also possible to run into bandwidth limitations on the SAN itself, since
  fibre channel has a limited bandwidth.

SQL Server 2000 I/O Configuration in a SAN/NAS Environment

www.sql-server-performance.com/...2000io_config_sannas_p1.aspx - Preview

SQL-Server IO SAN NAS Performance Configuration RAID

A poorly configured I/O subsystem can easily become a bottleneck and can
severely affect performance
When modifications are done to the database, the lazy writer will write that
data out at a later time, so, although write performance is important, no users
ever wait on writes to occur (except to the transaction log).
5 more annotations...
- The performance is also affected by your choice of RAID level
- IOPS (I/O’s Per Second
- limitation is basically caused by the number of seeks per second that the disk
  drive can do
- The 6 ms seek latency corresponds to 166 IOPS. However, when you get near to
  this limit, disk queuing occurs and latencies can increase exponentially
- In order to keep I/O performance reasonable, you should not exceed 75% of the
  maximum capacity of the disk drive

Examining SQL Server's I/O Statistics — DatabaseJournal.com

IO stats mesurement

www.databasejournal.com/...10888_2244381_1 - Preview

SQL-Server MSSQL IO Performance Statistics

SELECT @@TOTAL_READ [Total Reads]
, @@TOTAL_WRITE as [Total Writes]
, CAST(@@IO_BUSY as FLOAT) * @@TIMETICKS / 1000000.0 as [IO Sec]
GO

29 Sep 09

Web Performance Best Practices

code.google.com/...rules_intro.html - Preview

Web Performance Client Browser google

Facebook | Needle in a haystack: efficient storage of billions of photos

READ WRITE Performance

www.facebook.com/note.php - Preview

FaceBook Infrastructure Architecture Hardware Performance Read-Write

Since each image is stored in its own file, there is an enormous amount of
metadata generated on the storage tier due to the namespace directories and file
inodes. The amount of metadata far exceeds the caching abilities of the NFS
storage tier, resulting in multiple I/O operations per photo upload or read
request. The whole photo serving infrastructure is bottlenecked on the high
metadata overhead of the NFS storage tier, which is one of the reasons why
Facebook relies heavily on CDNs to serve photos
RAID-6 partition managed by the hardware RAID controller. RAID-6 provides
adequate redundancy and excellent read performance while keeping the storage
cost down
1 more annotations...
- The poor write performance is partially mitigated by the RAID controller NVRAM
  write-back cache. Since the reads are mostly random, the NVRAM cache is fully
  reserved for writes. The disk caches are disabled in order to guarantee data
  consistency in the event of a crash or a power loss

25 Sep 09

Database Storage with SQL Server - Part II - ExtremeExperts

www.extremeexperts.com/...StoragePractice2.aspx - Preview

SQL-Server MSSQL Performance Storage Disk RAID

Pre-allocate
an appropriate size for database files. Auto-growth of database files has an
impact on the performance as discussed before. By pre-allocating and monitoring
the free capacity of database files, you can avoid performance issues during
production hours
Place
multiple database files on separate drive arrays. You can improve performance
and minimize disk contention by separating database files onto separate I/O
channels. Ensure that you do not saturate the I/O bus.
4 more annotations...
- Limit
  the number of database files to the number of CPUs. The maximum number of
  threads that SQL Server will utilize to access database files is equal to the
  number of CPUs included in your system, taking into account any affinity
  configuration settings
- there is limited value in having multiple log files
- Transaction
  log files are accessed sequentially by SQL Server, whereas database files are
  accessed randomly
- The
  log is write-intensive in most SQL Server solutions. Therefore, you should not
  use RAID 5. You can use a RAID 1 or RAID 10 array for better performance.

Read and Write Performance

www.storagereview.com/...perfReadWrite.html - Preview

Disk RAID Performance

For reads, striping with parity can actually be faster than striping without parity. The parity
information is not needed on reads,
For sequential writes, there is the dual overhead of parity calculations as well
as having to write to an additional disk to store the parity information. This
makes sequential writes slower than striping without parity
4 more annotations...
- every time you change any block in a stripe, you have to recalculate the parity
  for that stripe, which requires two writes plus reading back all the other pieces of the stripe
- You want to do a small "random write" that changes just the block in this stripe
  on drive #3. Without the parity, the controller could just write to drive #3 and
  it would be done. With parity though, the change to drive #3 affects the parity
  information for the entire stripe. So this single write turns into a read of
  drives #4, #5 and #1, a parity calculation, and then a write to drive #3 (the
  data) and drive #2 (the newly-recalculated parity information). This is why
  striping with parity stinks for random write performance
- The controller has to make sure that when it changes data and its associated
  parity, all the changes happen simultaneously;
- two-phase commit

Linchi Shea : Is RAID 5 Really That Bad?

sqlblog.com/...is-raid-5-really-that-bad.aspx - Preview

RAID Disk Performance

How can RAID 5 outperform RAID 10 on 8K sequential writes
behind each of the two volumes is an I/O path consisting of many
hardware/software components. Some of them are shared between the volumes,
others are not. Many of the components have a significant impact on the I/O
throughput and latency of the volume; they include HBAs and the software that
manages the I/O paths on the host, SAN architecture, model of the SAN frames,
cache on the SAN, RAID configuration, specifications of the physical disks
inside the SAN frames, configuration of hardware hardware replication, number of
spindles used by the volume, and so on.

http://miracleas.com/BAARF/RAID5_versus_RAID10.txt

miracleas.com/...RAID5_versus_RAID10.txt - Preview

RAID Disk Performance

If you
later modify the data block it recalculates the parity by subtracting the
old block and adding in the new version then in two separate operations it
writes the data block followed by the new parity block. To do this it must
first read the parity block from whichever drive contains the parity for
that stripe block and reread the unmodified data for the updated block from
the original drive. This read-read-write-write is known as the RAID5 write
penalty since these two writes are sequential and synchronous the write
system call cannot return until the reread and both writes complete, for
safety, so writing to RAID5 is up to 50% slower than RAID0 for an array of
the same capacity

Read and Write Performance

www.pcguide.com/...perfReadWrite-c.html - Preview

RAID Performance Disk

RAID Performance Issues ]
Without the parity, the controller could just write to drive #3 and it would be
done. With parity though, the change to drive #3 affects the parity information
for the entire stripe. So this single write turns into a read of drives #4, #5
and #1, a parity calculation, and then a write to drive #3 (the data) and drive
#2 (the newly-recalculated parity information).
3 more annotations...
- Since only one drive contains parity information, every write must write to this drive, turning it into a
  performance bottleneck
- The controller has to make sure that when it changes data and its associated
  parity, all the changes happen simultaneously; if the process were interrupted
  in the middle, say, after the data were changed and not the parity, the
  integrity of the array would be compromised.
- two-phase commit

Navneet Kumar's Library tagged Performance → View Popular

Top 20+ MySQL Best Practices - Nettuts+

High Performance Ajax Applications

Julien Lecomte's Blog » Running CPU Intensive JavaScript Computations in a Web Browser

jQuery Performance Rules - Best Practices for Speeding Up jQuery

Java String Concatenation and Performance ~ Joey's Scribble's

Performance comparison: key/value stores for language model counts - Brendan O'Connor's Blog

Database Optimize patterns | Haytham El-Fadeel

Hot links for Scalability | Haytham El-Fadeel

Java theory and practice: Garbage collection and performance

Java theory and practice: Urban performance legends, revisited

SQL Server 2000 I/O Configuration in a SAN/NAS Environment

SQL Server 2000 I/O Configuration in a SAN/NAS Environment

Examining SQL Server's I/O Statistics — DatabaseJournal.com

Web Performance Best Practices

Facebook | Needle in a haystack: efficient storage of billions of photos

Database Storage with SQL Server - Part II - ExtremeExperts

Read and Write Performance

Linchi Shea : Is RAID 5 Really That Bad?

http://miracleas.com/BAARF/RAID5_versus_RAID10.txt

Read and Write Performance

Selected Tags

Related Tags

Sponsored Links

Top Contributors

Groups interested in Performa...

Web Performance

Sport and Exercise

Qualité web et testing