Skippable Details

All this traffic is round robin'd to 2 apache2 servers (each is 2x 2.86 quad xeons w/ 4GB ram) and one backend db server of similar spec.

Over the years familiar problems rear there heads, the mysql "Too Many Connections" error, Apache running like a dog under stress etc.

This weekend I got the chance to rebuild the servers from scratch, and a chance to optimize everything - works very very well now!

Easy Optimization - Apache2

KeepAliveTimeout: Number of seconds to wait for the next request from the same client on the same connection.

Translate this to "Number of seconds to lock up a worker thread just incase another request comes in from the same client on the same connection" - in short a lot of browsers will request the page, keep the connection alive and use it to request images, css etc.

The default is 15 seconds; in my experience about 40-50% of connections will use KeepAlive, so if you have enough ram to support 500 requests before going in to swap memory, and you get 500 requests a second, by the time 3 seconds are past you've got a load of workers with RAM assigned doing nothing and all the hard work is getting done using swap memory instead, from this poitn on basically all the hard work is getting done using swap rather than ram, ya?

Thus, the simple fix is to knock KeepAliveTimeout right down - some people recommend 2 seconds, my personal preference is 4 seconds - works a charm for me :)

To analyse this yourself just check the server-status provided by apache (normally only viewable from localhost, easy way around this is to <?php echo file_get_contents('http://localhost/server-status'); ?>

Easy Optimization - MySQL Server

Other than the normal cnf values you should be optimizing [ key_buffer, sort_buffer_size, max_allowed_packet, thread_stack, thread_cache_size, max_connections, table_cache, query_cache_limit, query_cache_size ] - there is one more that is very important; namely wait_timeout.

wait_timeout - The number of seconds the server waits for activity on a noninteractive connection before closing it.

By default this value is very high, but often you get connections that just aren't closed properly, especially in the PHP apache world - if you ever hit that "Too many connections" error or see a lot of connections open for prolonged periods of time then this could / should be addressed.

Often you will see connections sitting idle for 10-15 seconds, for no good reason. Best to address it I'd say; and thus we lower wait_timeout to 5 seconds.

Connections are cleared faster, more resources free for other connections and all round its good. Remember one of mysql's strongest features is it's ability to open and close connections ultra-fast.

Summary

Honestly just check the your apache server status, see how many connections are open, how many of them are flagged K for keep alive then drop the keep alive time, take a note of processor usage / memory usage, drop the KeepAliveTimeout to 2, 4, 6, 8 and check it all again, you may be very suprised, it sure beats weeks of manual code optimizatios to make those scripts run faster.

Regards

Other than the really obvious bit that its direct access to a block of ram/fast memory which works extremely quickly, there is one other small but vital detail that's haXe specific and makes a vast difference between alchemy and haxe.

The Big Difference

You can think of flash.Memory as a static ByteArray, thus it is accessible from both static class and instance methods.

Now, another feature which offers huge speed increases in haXe is inlining.

Spelling it out - You can only inline static private methods, flash.Memory is all static access. So stick all your data (or big chunks of it) in flash.Memory and then inline  most of your heavy number crunching class.

All inlined, all using fast memory = very very quick swfs!

Ideas and Tricks

First of all, get the thought of only being able to have one chunk or type of data in fast memory at a time, you can partition it up and load everything in there.

A common setup I use is to have the first 1024 bytes as fast storage for float, int, byte, uint variables, the next xxx-thousand bytes as raw bitmap data, then all the other data I may want - like a block of 500k x,y,z floats for 3d data, followed by a few lookup charts.

the first 1024 bytes as fast storage for float, int, byte, uint variables - because you can then access the most commonly used vars using small int offsets (0-255) - and since its a small int your using it avoids all stacks completely, the bytecode will only contain the opcode to get the value from fast memory followed by the offset actually in the bytecode - for anything 256 and over its going to hit the int stack to get the offset first (which is barely noticable, but you know every fraction counts)

the next xxx-thousand bytes as raw bitmap data - because you can then work on your bitmap data ultra fast and write it back to the BitmapData instance using setPixels; very fast indeed, faster than a fixed sized vector even.

then all the other data - this is partially obvious, what may not be is the use of lookup charts, but I'll cover that in a moment.

Accessing..

Remember flash.Memory differs from a byte array in that you have to add in the offset for each value you want to grab

• Byte = 1 Byte
• Int = 4 Bytes
• Float = 4 Bytes
• Double = 8 Bytes

To use flash.Memory with functions which require a ByteArray.. [ like BitmapData.getPixels() -  Sound.extract() ] .. you can access it directly from flash.system.ApplicationDomain.currentDomain.domainMemory for example:

// set position to start of the data we need
flash.system.ApplicationDomain.currentDomain.domainMemory.position = SOME_OFFSET;
// use the fast memory
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );

note: don't be fooled though, you can't simply call the functions on the bytearray in currentDomain, although it is the data that is in fast memory, it does not use the opcodes, which are what speed it up!

Lookup Charts

Often you'll find yourself calling the same code over and over and over; perhaps without realising just how much; consider we make an animation which uses perlin noise to generate 2d or 3d data - like this example - the example reads about 40k uint values from perlin noise, then converts each pixel to individual r,g,b values, then turns it in to a float -1 to 1 using a simple calculation. Thing is.. that means the same calculation runs 3x40000 times per frame at 50 frames a second.. 6 million times a second!

In this scenario, there are only 256 possible inputs to the calculation and 256 results - so rather than working it out 6 million times we can load it all in to a lookup chart, stick the lookup chart in fast memory and then lookup values rather than calculating - often you can really speed things up by doing this. Practical example with comments here.

Hope this is of use to somebody and clears things up a bit; I use the methods often so you'll see them in the source of my experiments.