no offense, but this won't work on really high traffic sites.
i'm talking TV spots or newsletters to millions of users.
the fact that you're using php will always be a bottleneck:
Transactions: 222 hits
Availability: 100.00 %
Elapsed time: 29.43 secs
Data transferred: 16.36 MB
Response time: 1.28 secs
Transaction rate: 7.54 trans/sec
Throughput: 0.56 MB/sec
Concurrency: 9.69
Successful transactions: 222
Failed transactions: 0
i didn't want to stress your demo server, so i only tested
10 concurrent requests.
really fast looks like this:
Transactions: 39979 hits
Availability: 99.97 %
Elapsed time: 29.93 secs
Data transferred: 316.76 MB
Response time: 0.30 secs
Transaction rate: 1335.75 trans/sec
Throughput: 10.58 MB/sec
Concurrency: 394.66
Successful transactions: 39979
Failed transactions: 13
don't get me wrong! i like your proof of concept! it's a
nice and simple way to improve performance.
Am 04.11.2011 um 16:49 schrieb Alexander Kludt:
Thanks, but i think this will also work quite well on bigger
shops - depending on how often the products change. But we will
investigate in that.
nice work!
Looks like a simple solution to improve performance on small
shops.
I like it.
Hi guys,
We are proud to showcase our new proof of concept on how to
implement a solid full page caching and compressing
module for oxid e-sales. More on this topic in the forum thread
(sorry, german):
http://www.oxid-esales.com/forum/showthread.php?t=12016
And the demo here:
http://demo.shirtnetwork.de/4-5-3-demo/
Feedback would be appreciated.