Some problems with stability – JS Application Server
Many thanks for the link to the performance test tools for Apache. Is using Apache Bench for evaluating performance on ultra-thin Omnis approaches and it is a very good tool. Will look into the additional approaches described in the link. Very useful.
Regarding ngix approach I will look into that when there will be a full scale implementation – the differences in performance seems to be quite drastic. I myself in the case of Apache push up the number of min servers and max servers to levels of 20 – 40 which seems to do some good for the performance measured in Apache Bench. I am myself now in testing mode to develop and evaluate approaches to maximise the use of SQL workers in combination with push in ”multi-modal” and ”multi-component” remote forms so the pure ultra-thin approach is a bit on a back burner. I find thought (since I am not that knowledgeable in web page scripting) that the threshold of getting ultra-thin to work is challenging – keeping tabs on all the tags etc. I think that Omnis could to at least me a favour of more extensively describe and supply functional templates for this. I am also evaluating how an ultra-light approach for the web worker objects could look like – the earlier ultra-thin approach do not support SQL worker approaches which is a big problem if you want to really optimise performance. Having ultra-thin calls blocking more performant JS remote form calls utilising SQL workers and push is not a nice thingie…
Omnis when acting as a app server creates js-files for the different remote forms when first called during operation and sends these to the client. As I have experienced it they are cached in the client together with graphical resources that takes space. What is surprising is the small size of these files – and the requests results in very small data response sizes – often down to a couple of hundred bytes. This might be the result from very thought-out delegation of roles between the server and the clients in this case. Another reason is that the client initially receives large blocks of JS files for the Omnis JS environment up front that handles the client-side logic and presentation. I am also VERY aggressive of compressing all graphics as much as possible taking into account quality of course. I always look from the perspective of thousands of simultaneous users – being aware that Omnis might not be the best tool for very large public deployments.
A wish-list for me? Omnis creates good core templates for ultra-thin deployment and creates examples of using web objects to support ultra-thin.
Take care, all the best…
> 8 feb. 2018 kl. 21:49 skrev Clifford Ilkay <firstname.lastname@example.org>:
> Hi Sten-Erik,
> This article is a quick overview of doing load testing of a web
> application. < Sten-Erik Björling Enviro Data Kyrkogatan 5A 2 tr SE-972 32 Luleå Sweden E-Mail: email@example.com
Mobile: +46-70-655 11 72
Hotmail / Messenger: firstname.lastname@example.org
This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.
Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.