Session held at LDC Toronto May 2012.
Presented by Ke Carlton, Zeroloop
Fast websites / Applications lead to:
Happy Users
Happy Client
Happy Developer
Low hanging fruit — use broad strokes to determine where your problems reside:
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:
timer(1000+) => { /* time this */} // Run after definition Slapcode / L-Debug // Time as you code. ab / httpload loads…
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.
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.
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.
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)
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.
Pros: Reduces thread locking issues clients are dispersed to multiple nodes
Cons: Cached object generated multiple times.
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(`now`) => `Cached on [date]` memcached(`mainmenu`,600) => file(`/menu.inc`) memcached(`friends`,600) => {return friends()}
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.
Use cookies if possible — encrypted with a client specific salt.
Cookies are fastest - if minimal data. No writes to db (resource intensive)
Cover the basics. Indexing. Disable name lookups, enable the cache.
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.
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
Please note that periodically LassoSoft will go through the notes and may incorporate information from them into the documentation. Any submission here gives LassoSoft a non-exclusive license and will be made available in various formats to the Lasso community.
©LassoSoft Inc 2015 | Web Development by Treefrog Inc | Privacy | Legal terms and Shipping | Contact LassoSoft