High Performance Lasso Sites

 

One server does not cut it. No really.

If you're serious about your online business or your have client in mind, redundancy is a must and you should do your best to pitch it to them. Instability in the formative stage can kill a new startup or severely damage the reputation of an existing one.

As well as redundancy, multiple servers also provide performance opportunities:

• Ability to spread load
• Ability to shard data across servers
• Mysql Data (even the minimum master - master setup)
• Memcached

Tools:

timer(1000+) => { /* time this */} // Run after definition
Slapcode / L-Debug // Time as you code.
ab / httpload loads…

Techniques:

a / b tests — competitive evolution.
testable methods / chunks OOP is best.

Don't assume. Test.

Test concepts early.
Re-used successful techniques.

Compilation is slow.

Allow JIT cache to be "primed" before benchmarking.

Matter of scaling:

Thread: milliseconds (not seconds!)
Datasource: milliseconds
Your code: microseconds!

When developing:

Micros is the new metric. Goodbye msec.

End target/s:

Scales — If you're at a second or so — push for half that.
End goal with primed cache: 50ms (generous)
If application / sub 50ms per thread.
Keep in mind as you go.
Often modifying a single element of code can yield great improvements and can come after getting something working — but don't get caught out by poor architecture.

Cache Cache Cache

Caching is probably the most important tools we have we it comes to delivery of high performance websites. Caching can help greatly, but it won't help if your server's overloaded when trying to generate the items to be cached.

Working with thread vars.

We often use variables() to retaining settings etcs. And this is effective a form of caching. But we can extract that by using stubs for thread level object. ie current_user

define current_user => var(_current_user) || $_current_user := user($user_session_var)

Working with threads objects

Threads are single threaded (whether accessing or modifying data). This can cause thread locking issues under load as only one client can access the type. Threads are also very useful and convenient.

Ways to circumvent the issues:

Have thread objects return the answer — not the data. Copying data is slow and expensive.

Use:

local(info) = threadobj->getinfo('/the/url')

Not:

local(info) = threadobj->menu>find('/the/url')

This reduces the likely hood of thread locking - due to being faster.

More Lasso instances

Pros: Reduces thread locking issues clients are dispersed to multiple nodes
Cons: Cached object generated multiple times.

Generating Lasso code

The fastest way to create a map is to define a map.
So use Lasso to generate Lasso.

process('[define mainmenu => '+#mainmenu->aslasso+']')

This avoids thread locking issues, as we're simply creating the map every time we need it (without touching db or similar). 512 limit?

Memcached

• High concurrency
• Simple syntax and mechanics
• Solid and proven: Facebook, Twitter, Youtube...
• Supports Lasso types:
  bytes, strings, pairs, arrays, maps, decimals...

memcached(`now`) => `Cached on [date]`
memcached(`mainmenu`,600) => file(`/menu.inc`)
memcached(`friends`,600) => {return friends()}

Some basic tips

Pre-compile your types — don't do on the fly.
Do you need sessions? Cookies are much faster.
Use nested inlines.
Date(integer) is 10 - 20x faster than date(string)
Avoid % in date->format — 4-5x faster.

Do you really need sessions?

Use cookies if possible — encrypted with a client specific salt.
Cookies are fastest - if minimal data. No writes to db (resource intensive)

MySQL

Cover the basics. Indexing. Disable name lookups, enable the cache.

Normalise your data

Solid database design principals dictate that your data should be normalised and not repeated. What this typically means in OOP is that each class will have a corresponding table. User = User, Address = Address etc. This is logical, works well and makes a lot of sense.

De-normalise your data!

Don't break the structure — mine it. For example when listing products, use a table that only contains the needed column - that may span multiple tables. Selecting from a single table is MUCH faster than joins — especially when contain indexes tailored for your searches. Any such table should automatically be updated.

Author: Ke Carlton
Created: 25 May 2012
Last Modified: 4 Jun 2012