[TYPO3-Performance] ab failed requests

[georg kuehnberger]

Dan Osipov wrote:
> Georg,
> I was hoping to look into offloading some of the peak traffic into the 
> cloud, and make it seamless to the end user. Based on your experience - 
> I don't think that's quite what you did here 

Hey Dan,

You're right; what we used "the cloud" for was most realistic 
load-testing towards a "no-clouded" target in order to measure & tune 
this Application unter Test (AUT); (and repeat tuning and testing as 
long as it matched the clients expectations).

> I was hoping to look into offloading some of the peak traffic into the 
> cloud, 
- do you think its possible?

Definitely.

a) go for S3
It boils down to the following:

- Use S3 for storage of infrequently (less than 2min) updated data (like 
CSS, images, and video), that can be delivered to the client without 
ever asking you T3-Instance for them (href points towards s3) = 
translates into HIGH traffic-reduction and http-request reduction;

This apparently has and is been done quite often, especially from within 
the blogger / wordpress community in order to get their servers not 
"slash-dotted" (= offload traffic & load).

btw. I feel you could easily do the same with those other cloud 
frameworks; eg. google et al.


b) add CDN to S3
In case you're fancy, cost-conscious and wanna deliver faster, you'd add 
Amazons distributed CDN to the above; it's built upon s3 and called 
cloudfront.
For details please see:
http://aws.amazon.com/cloudfront/
http://www.labnol.org/internet/setup-content-delivery-network-with-amazon-s3-cloudfront/5446/


c) as for TYPO3
- You could go different routes depending on your business-plan & 
available infrastructure;
- option-1 - move all to ec2 (virtual Server Infrastructure - even inkl. 
loadbalancer, rev.proxies, t3-instance, db-cluster and more)
& s3 (for storage & CDN);
- option-2 - keep t3 & db local, though move high volume & frequent 
volume stuff to s3 & cloudfront (or any other cloud)
- option-3 - mix / match according to you clients preferences.

hth regards georg

PS: we just recently tested a fully transparent fuse-based filesystem 
simply sym-linked from fileadmin into s3; turned out to work flawlessly 
with typo3;

PPS: "Serial innovator" Reuven Cohen catched the cloud-wave a bit 
earlier and offers professional products & services covering some or 
most of the above and is even sepcialized on TYPO3 - see:
http://www.enomaly.com/
No I dont know Reuven (unfortunately), and neigther am related to Amazon 
(except being my personal book-store)


> Dan Osipov
> Calkins Media
> http://danosipov.com/blog/
> 
> georg kuehnberger wrote:
>> Dan, Dmitry, et al,
>>
>> FYI only: We recently had a requirement to load-test an application 
>> with something like 20.000 concurrent users doing personalized logins, 
>> some user-activity-within the application and logout within 5 minutes;
>>
>> Having spent a day or two on developing the testcase, allocating "free 
>> machines" as test-slaves and running our load-tests we soon faced the 
>> following limitations: number of available-testboxes, effort to setup 
>> new testboxes, cpu, filehandles (aka network-connectsions), overall 
>> available bandwidth, and even more.
>>
>> So we turned to on-demand cloud-computing and were able to work around 
>> the above limitations by simply adding (or removing) more 
>> "cloud-boxes" to our "bank of clouds" in a matter of minutes/hours 
>> rather than days.
>> This move allowed for the targeted "cloudburst" towards the AUT 
>> (application under test), and meaningful analysis there.
>>
>> I definitely fell in love with clouds; however only in the 
>> computing-sense.
>>
>> cloudless, sunny greetings
>> regards georg
>>
>>> Dan Osipov wrote:
>>>> I did try jMeter, but I think because I was doing it on my local 
>>>> computer the network became the bottleneck...
>>>
>>> I experienced the same on first time usage; however you can run 
>>> jMeter from remote, too; actually you may run it from multiple 
>>> servers, with the GUI on your localmachine just sending commands to 
>>> the jmeter-servers and receiving reports from them.
>>> This setup allows for really nice on purpose DDOSes ;-)
>>> 'njoy georg
>>>
>>> http://jakarta.apache.org/jmeter/usermanual/remote-test.html
>>> http://jakarta.apache.org/jmeter/usermanual/jmeter_distributed_testing_step_by_step.pdf 
>>
>>