No specific reads performance difference in LAMP and MEAN stacks - mysql

Question

These are the codes that Iam running on AWS T2.medium 2 core/ 4GB instances. Used same config different instance,same subnet to benchmark.The benchmarking result shows same throughput and response time of both the stacks. I used Jmeter for performance metrics evaluation. Results shows that MEAN is slower than LAMP. Tested upto 600 concurrent requests and throughput was around 35req/sec for MEAN and 37req/sec for LAMP. Why Iam getting such a low throughput and why MEAN is performing worst for just reading.
LAMP stack code:
<?php
$con = mysql_connect("localhost", "root", "root");
if(!$con) die('connection failed');
$db = mysql_select_db("mms-php", $con);
$result = mysql_query("SELECT * FROM comments LIMIT 10", $con);
$rows = array();
while( $row = mysql_fetch_assoc($result) ) {
array_push($rows, $row);
}
header("Content-type:application/json");
echo json_encode($rows);
//print_r($rows);
//$result = mysql_query("INSERT INTO msgs (msg) VALUES ('" . rand() . time() . "')", $con);
mysql_close($con);
?>
mysql has one table comments with 1000 entries. Similarly MongoDB has one collection with 1000 entries.
MEAN stack code:
var MongoClient = require('mongodb').MongoClient
, assert = require('assert');
var http = require('http');
var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
// Fork workers.
for (var i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('death', function(worker) {
console.log('worker ' + worker.pid + ' died');
});
} else {
// Connection URL
var url = 'mongodb://localhost:27017/test';
// Use connect method to connect to the Server
MongoClient.connect(url, function(err, db) {
console.log("Connected correctly to server");
http.globalAgent.maxSockets = 10;
http.createServer(function (req, res) {
//process.nextTick(function(){
res.writeHead(200, {'Content-Type': 'text/plain'});
db.collection('comments').find({},function(err, docs) {
if(err) {
console.log(err);
res.write('an error occurred');
res.end();
} else {
// console.log(docs);
docs.each(function(err, doc){
if(doc)
res.write(JSON.stringify(doc));
else
res.end();
//console.log(JSON.stringify(doc));
});
}
});
// });
}).listen(1337, '0.0.0.0');
});
}

Answer 1

In summary, synthetic benchmarks are mostly for marketing. For read-only work (analytics & search where the write step is typically once per day/overnight) I've used MySQL with all the data sitting in a 60Gb+ squashfs RAM-disk (LAMP) and Elasticsearch (JavaScript & PHP clients on Linux). The latter was a workable option for real/near-time updates (I like Elasticsearch despite a Java prejudice) coupled to a MySQL database for the transactional part (and its normalised model to permit later ETL for analytics).
I would guess that you aren't exactly benchmarking a MEAN vs LAMP implementation of your application. I would guess that you are more likely benchmarking the start-up, printing (JSON encoding) a tousand-ish lines, and tear-down costs (establish a process/thread instance, make a connection to the database and so on) rather than the database transaction cost proper. I suggest this is the case as you have: a very small database (1000 elements) that will be cached; you're not asking the database to do anything other than return a cursor & the entire table/table-equivalent; and then just regurgitating it to the output stream (with no transformation -- unless you client side means to do this). Lastly, as others hint, you're not controlling the platform on which you are performing the comparison. You could run LAMP & MEAN on the most meagre of computers where you can have more certainty of a fair comparison.
Your benchmark would also be easily cheated with, say, the Apache configuration (as is possible with most other stacks) to cache results.
Have you tried a variety of clients to exercise the two implementations? Apache's ab is trivial but otherwise meaningless for applications I've been involved in historically. Great for discovering how the system behaves at saturation but not as informative as, say, httperf that I've successfully used to stretch the application services and database layers (where it won't all fit into RAM and I can make a distribution frequency that fits real scenarios).